How it works

You install PlanBridge once. After that, you keep using your coding agent the way you always have. The only difference: when your agent has a plan ready, your browser opens with it and you mark it up before any code is written.

Your workflow

You install it once

Run the install script and PlanBridge picks up any supported coding agent already on your machine. No configuration. No API keys. Re-run it later if you add a new agent.

You review every plan

Use your coding agent the way you always have. When it produces a plan, PlanBridge intercepts that step before any code is written. Your default browser opens to a review page on localhost.

You shape the work

Highlight any line of the plan, leave a comment. When you’re happy, click Approve Plan. If something needs to change, click Request Changes and your agent picks the work back up with your feedback in hand.

What runs where

Your plan never leaves your machine. There’s no remote backend, no account, no API keys. The only network traffic is your browser talking to a CLI process on localhost.

The CLI launches the local server only when your agent needs review, then shuts it down as soon as you submit. Nothing persists.

Under the hood

If you’re writing a hook adapter or just curious about the data flow:

stdin / [path]  ─▶  contextbridge plan
                       │
                       ├─ start a local Bun HTTP server (ephemeral port)
                       ├─ open your browser to http://localhost:<port>
                       └─ block until the browser submits
                                 │
                    ◀─ structured result on stdout:
                       { status, threads: [...] }

• stdin → CLI: the plan content (markdown).
• CLI → browser: the plan, rendered in a local web app.
• browser → CLI: your annotations and approval status, over localhost.
• CLI → stdout: a structured submission for the caller to parse.
• CLI → stderr: pino logs (JSON, or pretty when stderr is a TTY).

The stdout/stderr split exists so piped consumers see only the submission while humans get readable diagnostics. That stdout contract is what harness hooks (Claude Code’s ExitPlanMode, Codex’s planned Stop hook, etc.) consume.

Telemetry

We collect some anonymous telemetry data, which you can opt-out of, if you prefer. See Privacy & Telemetry for details.