Originally published at pilothouse.dev/blog/why-we-built-pilothouse.
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.
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.
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:
tmux, or herdr. PreToolUse policy engine.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.
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.
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 pilothouse-dev/tap/pilothouse
pilothouse setup
Pilothouse is free and open source under Apache-2.0: https://pilothouse.dev