Why we built Pilothouse

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 one more 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 both, you have two inboxes, two apps and two sets of rules, and neither of them knows about the other.

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 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.

• It watches every Claude Code and Codex session through their official hooks. No screen scraping, no terminal emulation, so it works in any terminal and inside tmux or herdr.
• It checks your rules before every tool call. Rules are YAML with globs, plus optional CEL expressions when you need logic. Any deny wins. A repo can ship its own rules, but until you trust it, it can only make things stricter.
• It’s presence-aware. 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. Come back, and it’s handed back to the terminal.
• Your phone talks to a web app served by your own machine, over Tailscale Serve. Pairing is a QR code; each device gets its own signing key and every decision it sends is signed.
• There is no account, no cloud and no telemetry. The one thing that calls home is an anonymous update check, and you can turn it off.

There’s more — a terminal inbox, wrap mode that keeps agents alive after you close the terminal, tasks that give each prompt its own worktree — but those three ideas are the core: rules first, the right device second, nothing hosted.

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. We wrote a whole post about why that split matters.

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, there’s a switch for that.

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, a built-in rule that asks before an agent touches Pilothouse — but it is defense in depth, not a sandbox. We say that on the security page, not in a footnote.

What it isn’t (yet)

v0.1 supports Claude Code and Codex on macOS and Linux. It reaches your phone through Tailscale. There’s no relay for people without Tailscale, no Windows build, no team features and no OpenCode, Copilot or Gemini adapters yet. Those are on the roadmap, in roughly that order of how often people ask.

We’d rather ship a small thing that does what it says than a large thing that mostly does.

Try it

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

Then read the quickstart. It takes about five minutes to get your first approval on your phone. If something’s wrong or missing, open an issue — the project is Apache-2.0 and pull requests are welcome.