DEV Community: Sabr Systems

Guardrails for vibe coders: PreToolUse rules that stop rm -rf and secret leaks

Sabr Systems — Tue, 03 Nov 2026 21:43:23 +0000

Originally published at pilothouse.dev/blog/guardrails-for-vibe-coders.

Vibe coding works until the agent runs rm -rf on the wrong folder, prints your .env into the transcript, or force-pushes over a teammate's branch. Most of us respond in one of two ways: approve every prompt by hand, or turn on "skip permissions" and hope.

There's a middle option. Every major coding agent now has a PreToolUse hook: a point right before a tool call runs where something can say allow, ask or deny. Pilothouse (which I build) puts a rules engine at that hook, for Claude Code, Codex, OpenCode and Grok Build at once. This post is the rule file I'd hand a friend, with each rule tested.

Setup (2 minutes)

brew install sabr-software/tap/pilothouse   # or: curl -fsSL https://pilothouse.dev/install.sh | sh
pilothouse setup                            # installs the hooks (shows the diff first)
pilothouse policy init                      # writes a commented starter ~/.pilothouse/policy.yaml

The fast path: presets

If you only do one thing, do this:

pilothouse policy preset guarded-autopilot on
pilothouse policy preset no-secrets on

guarded-autopilot is meant as a safer alternative to --dangerously-skip-permissions. It lets routine repo work run without prompts (reading, editing inside the repo, tests, builds, linters, read-only git). It blocks destructive commands like rm -rf ~, git reset --hard, force-pushes and DROP TABLE. And it asks before pushes, deploys, secrets and sudo. no-secrets blocks .env files, private keys, cloud credentials and credential dumps such as printenv and gh auth token, while leaving .env.example alone.

The rule file I actually use

Here's a hand-written ~/.pilothouse/policy.yaml that covers the same ground, so you can see how the rules work and adjust them:

version: 1
rules:
  # 1. Never let an agent wipe a broad path.
  - name: no-broad-rm-rf
    description: Recursive force-deletes of /, ~, $HOME, . or *
    match: { kind: shell }
    when: 'command.matches(r"\brm\s+(-[a-zA-Z]*[rR][a-zA-Z]*f[a-zA-Z]*|-[a-zA-Z]*f[a-zA-Z]*[rR][a-zA-Z]*|-r\s+-f|-f\s+-r)\s+(/|~/?|\$HOME/?|\./?|\*)(\s|;|&|\||$)")'
    action: deny
    message: Recursive delete of a broad path is blocked. Delete the specific files instead.

  # 2. No force-push, in any spelling (but --force-with-lease is fine).
  - name: no-force-push
    match: { kind: shell, command: "*git*push*" }
    when: 'has_word(command, "--force") || has_word(command, "-f")'
    action: deny
    message: Force-push is blocked. Open a PR instead.

  # 3. Pushing to main needs a person.
  - name: ask-before-pushing-main
    match: { kind: shell, command: "*git*push*" }
    when: 'has_word(command, "main") || has_word(command, "master") || branch == "main"'
    action: ask
    message: This pushes to main.

  # 4. Keep agents out of secrets (templates are fine).
  - name: no-secret-files
    match: { path: [".env", ".env.*", "*.pem", "*.key", "~/.ssh/**", "~/.aws/**"] }
    when: '!paths.all(p, p.endsWith(".example") || p.endsWith(".sample"))'
    action: deny
    message: Secrets are off limits. Use .env.example or ask me for the value.

  # 5. No dumping the environment or tokens into the transcript.
  - name: no-credential-dumps
    match: { kind: shell }
    when: 'has_word(command, "printenv") || command.matches(r"\benv\s*($|\|)") || command.contains("gh auth token")'
    action: deny
    message: Don't print credentials into the session.

  # 6. Piping a download into a shell needs a person.
  - name: ask-curl-pipe-sh
    match: { kind: shell }
    when: 'command.matches(r"\b(curl|wget)\b[^|]*\|\s*(sudo\s+)?(sh|bash|zsh)\b")'
    action: ask
    message: This runs a script straight from the internet.

  # 7. Production databases are off limits.
  - name: no-prod-db
    match: { kind: shell, command: ["*psql*prod*", "*mysql*prod*"] }
    action: deny
    message: Use the staging database.

A few things worth knowing about the format:

match: fields are globs, and they're AND-ed together: kind, command, path, tool, cwd, repo, branch, agent.
when: is a CEL expression with command, paths, branch, repo, hour, weekday and more available. has_word() matches whole words, so --force-with-lease doesn't trip --force.
A relative path pattern like .env matches at any depth. Start it with / or ~/ to anchor it.
If several rules match, any deny wins, then ask, then allow.
A file with an error isn't used, and the last version that compiled stays in force, so a typo never silently drops your deny rules.

Test before you trust it

Run any rule against a command without an agent involved:

$ pilothouse policy check
âœ“ ~/.pilothouse/policy.yaml  7 rules

$ pilothouse policy test "rm -rf ~"
Decision: DENY by no-broad-rm-rf
Message:  Recursive delete of a broad path is blocked. Delete the specific files instead.

$ pilothouse policy test "rm -rf node_modules"
Decision: none â€” no rule matched; the agent's own permission settings apply.

$ pilothouse policy test "git push --force-with-lease origin feat"
Decision: none â€” no rule matched; the agent's own permission settings apply.

$ pilothouse policy test "git push origin main"
Decision: ASK by ask-before-pushing-main

$ pilothouse policy test --tool Read --path ~/app/.env.example
Decision: none â€” no rule matched; the agent's own permission settings apply.

Those are real results from the file above. Then see what your new rules would have done to last week's actual tool calls:

pilothouse policy replay --since 7d

Rules without YAML

Most of my rules started as one tap on an approval card. When a request reaches your phone, the card offers rules built from the call: Always allow npm test in api-server, Always ask before git push, Never allow force-pushes. From the terminal:

pilothouse policy add ask-push --action ask --command "git push" --command "git push *"
pilothouse policy add no-prod-db --action deny --command "psql *prod*" --message "Use the staging database."
pilothouse policy rules      # everything, in the order it is checked

These "managed" rules are matched one command at a time, so allowing npm test never allows npm test && curl â€¦ | sh.

Repo rules for your team

A repo can ship its own .pilothouse/policy.yaml. Its deny and ask rules apply to anyone who works in that repo. Its allow rules only count once you run pilothouse policy trust, because anyone can publish a repo with a permissive policy in it.

Lean on deny

deny rules are enforced on Claude Code, Codex, OpenCode and Grok Build alike, which is why the rule file above leans on deny for the things you never want. Keep ask for things a person should see.

Pilothouse also has a built-in rule you can't turn off: an agent can't run pilothouse approve, edit your policy, or change its own hook settings without a person confirming. Agents can't approve themselves.

Full reference: pilothouse.dev/docs and POLICY.md on GitHub.

Running Codex, Claude Code and Grok side by side without babysitting them

Sabr Systems — Tue, 03 Nov 2026 21:42:55 +0000

Originally published at pilothouse.dev/blog/codex-claude-code-grok-side-by-side.

The pattern everyone running more than one agent knows: you start three sessions, go make lunch, and come back to find two of them stuck on a permission prompt since minute four. Or you switch everything to "approve all" to avoid that, and one of them does something you'd never have allowed.

Here's how I run Claude Code, Codex CLI and Grok Build in parallel without either problem. (I build Pilothouse, the tool doing most of the work below.)

Step 1: one inbox for all of them

brew install sabr-software/tap/pilothouse
pilothouse setup

setup installs hooks into each agent it finds and shows you the exact diff before writing anything:

Agent	What Pilothouse installs
Claude Code	hooks in `~/.claude/settings.json`
Codex CLI	`~/.codex/hooks.json`, plus the trust entries Codex needs in `~/.codex/config.toml`
OpenCode	a plugin at `~/.config/opencode/plugins/pilothouse.js`
Grok Build	`~/.grok/hooks/pilothouse.json` (trust each project once with `/hooks-trust`)

It merges with hooks you already have and writes a backup first. After that, every session on the machine shows up in one place, in any terminal, sorted by what needs you:

pilothouse            # the inbox: y allow Â· a allow for session Â· n deny Â· r reply
pilothouse ls         # sessions and waiting requests
pilothouse explain s_3fq9   # why is this session "blocked"? shows the evidence

Step 2: start them so you can leave

You can keep starting agents the way you do now, and the hooks still apply. Starting them through Pilothouse adds two things: replies from your phone get typed straight into the agent's terminal, and the agent keeps running if you close that terminal.

pilothouse run claude
pilothouse run -n review -d -- codex "review the diff on this branch"
pilothouse run grok
pilothouse attach s_3fq9      # reattach from any terminal; ctrl+\ detaches

Or give each agent its own git worktree, so they never touch each other's files:

pilothouse task new "add a --json flag to the export command"
pilothouse task new --agent codex --base main "fix the flaky login test"
pilothouse task diff t_8d1x
pilothouse task done t_8d1x --pr     # push and open a PR with gh

If you use herdr, tap Open in herdr on a task in the Pilothouse app and that agent appears in a herdr tab on the computer.

Step 3: let the rules handle the routine stuff

The reason you babysit agents is that their prompts don't tell safe from dangerous. A rule check before every tool call does:

pilothouse policy preset guarded-autopilot on   # routine repo work runs; destructive stuff is blocked; pushes, deploys, secrets and sudo ask
pilothouse policy preset protect-main on        # pushes to main need you; force-pushes are blocked

When you approve the same thing over and over, the approval card offers to turn it into a rule ("Always allow npm test in api-server") with one tap.

Step 4: answer from your phone

pilothouse remote tailscale   # your phone reaches your machine over your tailnet; nothing public
pilothouse pair

At the desk, each agent's own prompt appears as usual. When you're away (keyboard idle, or pilothouse away), approval requests from Claude Code and Codex are held and pushed to your phone. Each one shows the command, a diff for edits, risk labels like Force-pushes to main or Reads .env, and the agent's last words before it asked. You hold to allow or tap Deny. Answer it anywhere and the other places close.

Step 5: more than one machine

My desktop runs the long jobs and my laptop runs whatever I'm doing on the couch. Since Pilothouse 0.4 they share one inbox:

pilothouse remote tailscale          # on every machine
pilothouse link add                  # on the hub (the machine your phone is paired with)
pilothouse link join https://studio.tailnet.ts.net XXXX-XXXX-XXXX   # on each other machine, with the printed code

The join command shows the hub's paired devices with a fingerprint for each key; you confirm the ones you recognise. After that, Today shows every machine's sessions, labelled by machine. Approvals, replies and the live terminal go to the machine running the agent, and that machine checks your phone's signature itself, so the hub can't approve anything on your behalf. Revoke a device on the hub and it's revoked everywhere.

Rules, tasks and budgets live on each machine, so add rules on the machine that needs them.

What this changed for me

I stopped checking terminals. Agents that are doing routine work keep going, the dangerous stuff gets blocked before it runs, and when Claude Code or Codex needs me, it shows up on my phone with enough context to decide in a few seconds. Grok Build sits behind the same deny rules and shows up in the same inbox.

Setup guide: pilothouse.dev/docs. Multi-machine: pilothouse.dev/docs/machines. Source: github.com/sabr-software/pilothouse.

My vibe-coding stack in 2026: where Pilothouse fits

Sabr Systems — Tue, 03 Nov 2026 21:42:46 +0000

Originally published at pilothouse.dev/blog/vibe-coding-stack-2026.

I don't write most of my code by hand anymore. On a normal day I have three to six agents going: Claude Code on the main feature, Codex reviewing a diff, OpenCode or Grok Build poking at something on the side. That stopped feeling like magic months ago. Now it feels like running a small team, and the hard part isn't the prompting. It's everything around it: where the agents live, how I know which one is stuck, and what they're allowed to do when I'm not looking.

This is the stack I've settled on and what each piece is for. Full disclosure: I build one of these tools (Pilothouse).

The short version

Layer	What I use	Job
Agents	Claude Code, Codex CLI, OpenCode, Grok Build	Do the work
Where they live	herdr	Terminals that keep running when I close the window, one sidebar for every agent
Editor	Whatever I'm reviewing in	Read diffs, fix the last 10%
Network	Tailscale	My laptop, desktop and phone on one private network
Rules and approvals	Pilothouse	A rule check before every tool call, and approvals that reach my phone when I'm away

 Desk machine (in herdr)                                  Laptop (linked)
 â”Œâ”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”        â”Œâ”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”
 â”‚ Claude Code â”€hooksâ”€â”                         â”‚        â”‚ Claude Code â”€hooksâ”€â” â”‚
 â”‚ Codex CLI  â”€hooksâ”€â”€â”¤                         â”‚        â”‚                    â–¼ â”‚
 â”‚ OpenCode   â”€pluginâ”€â”¼â”€â–¶ Pilothouse daemon â”€â”€â–¶ policy.yaml (allow/ask/deny)   â”‚
 â”‚ Grok Build â”€hooksâ”€â”€â”˜          â–²              â”‚        â”‚   Pilothouse daemon  â”‚
 â””â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”¼â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”˜        â””â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”¬â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”˜
                                 â””â”€â”€â”€â”€ pilothouse link (Tailscale) â”€â”˜
          away? the request is pushed to your phone â”€â–¶ hold to Allow / Deny

Agents: use more than one

Each agent is good at different things, and using two of them on the same problem catches mistakes. My split right now:

Claude Code for the main line of work and anything with a plan step.
Codex CLI for reviews and second opinions on a diff.
OpenCode when I want to try a different model without changing my habits.
Grok Build for quick, contained tasks.

The downside of using several agents is that each one has its own permission prompts, its own settings file and its own idea of what's safe.

herdr: where the agents live

herdr is a terminal workspace built for coding agents. Your agents run in real terminal panes inside a background server, so closing the client (or losing SSH) doesn't kill them. It sorts panes into workspaces and tabs, and it marks every agent as working, blocked, done or idle so you can see which one needs you. It also recognizes Claude Code, Codex, OpenCode, Grok and a long list of other CLIs, and it can add remote machines over SSH to the same sidebar.

curl -fsSL https://herdr.dev/install.sh | sh   # or: brew install herdr
herdr                                          # start or attach in your project folder

herdr answers the question "which of my agents needs me?" It doesn't try to decide what an agent is allowed to do, and it isn't built around answering a permission prompt from your phone with your own rules behind it. That's the gap Pilothouse fills, so the two fit together well.

Pilothouse: rules before every tool call, approvals that follow you

Pilothouse is a single open-source Go binary. It installs the agents' official hooks (a small plugin for OpenCode) and runs a local daemon. Every tool call an agent is about to make goes past your rules first, and every session shows up in one inbox.

brew install sabr-software/tap/pilothouse   # or: curl -fsSL https://pilothouse.dev/install.sh | sh
pilothouse demo        # optional: try the phone app with pretend agents
pilothouse setup       # shows the hook diff first, starts the daemon, pairs your phone

Three things it adds to the stack:

Rules before every tool call. A YAML file, with optional CEL expressions:

   # ~/.pilothouse/policy.yaml
   version: 1
   rules:
     - name: no-force-push
       match: { kind: shell, command: "git push*" }
       when: 'command.matches("(--force|-f)\\b")'
       action: deny
       message: Force-push is blocked. Open a PR instead.

     - name: ask-before-pushing-main
       match: { kind: shell, command: "git push*{main,master}*" }
       action: ask

     - name: no-secrets
       match: { path: "**/.env*" }
       action: deny

Any deny wins. If you don't want to write YAML, the presets cover the common cases: pilothouse policy preset guarded-autopilot on lets routine work in a repo run without prompts, blocks destructive commands and asks before pushes, deploys, secrets and sudo.

Approvals that follow you. At the desk, the agent's own prompt shows up as usual. When the keyboard goes idle, approval requests from Claude Code, Codex and OpenCode are held and pushed to your paired phone with the command, a diff for edits and risk labels. Allowing takes a one-second press and hold, so a stray tap can't approve anything.
One inbox for every machine. Since 0.4, pilothouse link lets one machine (the hub) show every machine's sessions in the same app, labelled by machine.

How herdr and Pilothouse fit together

herdr runs the terminals and shows who's blocked. Pilothouse decides what's allowed and lets you answer from anywhere. Run your agents in herdr panes the way you already do. Pilothouse's hooks still see every tool call.
Pilothouse tasks open in herdr. pilothouse task new "fix the flaky checkout test" starts an agent in its own git worktree. Tap Open in herdr in the Pilothouse app and that agent shows up in a new herdr tab on the computer, in the repo's workspace. To do that for every task you start from your phone:

  # ~/.pilothouse/config.yaml
  desktop:
    open: auto          # a herdr tab when herdr is running, else a Terminal window on macOS
    open_tasks: true

Two kinds of multi-machine. herdr adds machines over SSH so you can drive them from one sidebar. Pilothouse links machines over Tailscale so you can approve for them from one phone, and each machine checks your phone's signature itself.

Tailscale: the boring part that makes it work

Pilothouse has no account and no cloud relay. Your phone reaches the web app your own machine serves, over your tailnet:

pilothouse remote tailscale   # HTTPS on your tailnet via Tailscale Serve, nothing public
pilothouse pair               # scan the code; on iOS add it to the Home Screen first

No Tailscale? pilothouse notify telegram lets you answer from a Telegram bot you create, and pilothouse notify ntfy works too.

My setup, start to finish

# 1. Agents: Claude Code, Codex, OpenCode, Grok Build (install from each vendor)
# 2. herdr
curl -fsSL https://herdr.dev/install.sh | sh
# 3. Pilothouse
brew install sabr-software/tap/pilothouse
pilothouse setup
pilothouse policy preset guarded-autopilot on
pilothouse policy preset no-secrets on
# 4. Phone
pilothouse remote tailscale && pilothouse pair
# 5. Work
herdr          # then, in a pane:
claude         # hooks apply either way
# or, for replies and a live terminal from your phone:
pilothouse run claude

If you want to see how I run Codex, Claude Code and Grok side by side, that's the next post. The rules I actually use are in Guardrails for vibe coders.

Pilothouse is Apache-2.0 on GitHub. Issues and "this broke my setup" reports are very welcome.

Why we built Pilothouse: One inbox and PreToolUse rules for Claude Code, Codex, OpenCode, and Grok Build

Sabr Systems — Mon, 02 Nov 2026 16:41:43 +0000

Originally published at pilothouse.dev/blog/why-we-built-pilothouse.

Update, 2 November 2026: Pilothouse 0.4 can link several computers into one inbox. Run pilothouse link add on the machine your phone is paired with and pilothouse link join on the others. The app then shows every machine's sessions together, labelled by machine, and approvals, replies and the live terminal go to the machine running the agent. Each machine checks your device's signature itself, so the hub can't approve anything for you. Rules and tasks stay per machine. Setup: Several machines.

Update (October 26, 2026): Pilothouse 0.2 adds OpenCode and Grok Build support, questions and plan approval from your phone, replies, activity and usage tracking, and two-way Telegram.

If you run coding agents seriously, your day probably looks like this: three or four Claude Code sessions in different repos, a Codex session reviewing a PR, maybe an OpenCode or Grok Build session running in another tab or on a server over SSH. Each of them will, at some unpredictable moment, stop and wait for you.

Sometimes you’re right there. Often you’re in another tab, in a meeting, making coffee, or asleep — and the agent sits idle for an hour because it wanted to run npm install.

Pilothouse exists to fix that, without making the rest of your setup worse.

The problems we kept hitting

Blocked prompts you don’t see. Agents tell you they need you in the terminal they run in. If that terminal is behind three other windows, you find out when you go looking.

Every vendor solves it for itself. Claude Code has Remote Control and push notifications. Codex has the ChatGPT apps. They’re good — for their own agent. If you use more than one agent, you have multiple inboxes, multiple apps, and separate sets of rules, and none of them know about the others.

Permission prompts are the wrong place for rules. We wanted “never force-push” and “ask me before anything touches main” to hold for every agent. But a tool that only sees permission prompts can’t enforce that: if the agent’s settings already allow git push, it never asks, so there is nothing to intercept.

Most tools want you to move in. A lot of the tooling around agents is a new terminal, a new multiplexer, or a new desktop app you have to run your agents inside. Some of them are excellent. But we already have terminals we like, and tmux or herdr sessions on servers that aren’t going anywhere.

What we built

Why the name? A pilothouse is the enclosed room on a ship’s bridge where the ship is steered from. Your agents are the crew; you steer every one of them from one place — at the desk or from your phone.

Pilothouse is a single Go binary that runs a small daemon per machine:

Hooks, not screen scraping. It watches Claude Code, Codex, and Grok Build sessions through their official hooks (and OpenCode via a lightweight plugin). No terminal emulation, so it works in Ghostty, iTerm2, VS Code, SSH, tmux, or herdr.
PreToolUse policy engine. It checks your rules before every tool call. Rules are YAML with globs, plus optional CEL expressions when you need logic (command.matches("(--force|-f)\\b")). Any deny wins, then ask, then allow. A repo can ship its own .pilothouse/policy.yaml, but until you trust it, it can only make things stricter.
Presence-aware routing. At your desk, Pilothouse stays out of the way and the agent shows its own dialog, exactly as before. Step away, and the request is held and pushed to your phone (or two-way Telegram). Come back, and it’s handed back to the terminal.
Cryptographically signed phone approvals. Your phone talks to a web app served by your own machine over Tailscale Serve (or two-way Telegram without Tailscale), and you can link several machines into one inbox. Pairing is a QR code; each device generates a non-exportable P-256 signing key and every decision it sends is signed.
No account, no cloud, no telemetry. Everything stays on your own machines and your tailnet. The only network call is an anonymous update check, which you can disable.

Design choices we care about

Hooks over pixels. Reading the bottom of a terminal and guessing what an agent is doing works surprisingly often and fails in surprising ways. Hooks give us the exact tool call, the exact command, and a synchronous way to say yes or no. When a session’s state looks wrong, pilothouse explain shows the evidence behind it instead of shrugging.

Two checkpoints. Policy runs on every PreToolUse and never waits for a person, so it’s fast. People are only asked when the agent would ask anyway — or when a rule says ask.

Don’t freeze the terminal. The naive version of “approve from your phone” holds every prompt for the phone, which makes the terminal worse for the person sitting at it. Presence routing is the fix: only hold when you’re actually away.

Fail open, by default. If Pilothouse crashes, your agents carry on as if it weren’t installed. If you’d rather they stop, set approvals.fail_closed: true.

Be honest about limits. An agent runs as you. Pilothouse makes it hard for an agent to approve its own request — socket-only local decisions, a process-ancestry check, signed remote decisions, and a built-in rule that asks before an agent touches Pilothouse — but it is defense in depth, not a sandbox.

Try it in 30 seconds

Want to see the real web app with pretend agents asking for approvals in a temporary folder before touching your setup?

curl -fsSL https://pilothouse.dev/install.sh | sh
pilothouse demo

Or install via Homebrew / shell and wire up your agents in under five minutes:

brew install sabr-software/tap/pilothouse
pilothouse setup

Pilothouse is free and open source under Apache-2.0: https://pilothouse.dev