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

DEV Community: Sabr Systems

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

The problems we kept hitting

What we built

Design choices we care about

Try it in 30 seconds