Show HN: Agent-relay for multi-vendor coding sessions

Let AI coding sessions from different vendors work together, while you stay in charge.

Claude can hand work to Claude on its own. But when you work with sessions from different vendors, such as Codex for planning and review and Claude Code for the code, they can't talk to each other. Without a relay, you're the one transferring context: copying plans, results and reviews between terminals.

agent-relay carries the turns for you. One session leads, the other follows, and the relay passes each turn across, records it on your disk, and stops whenever something needs your decision. It's tested with Claude Code and Codex, and you can extend it to whatever agents you work with by writing an adapter.

| _{Watch: what the managed session is doing, in plain language.} | _{Decide: questions stop the loop until you answer.} |

These demos use pretend sessions, so they're safe to run anywhere and use no model quota. You need macOS and Python 3.11 or newer.

git clone https://github.com/saranyan/agent-relay.git && cd agent-relay

scripts/console-demo.sh      # the web console, with a few pretend sessions
scripts/walkthrough.sh       # the full two-terminal flow in a temporary folder

With the Claude Code and Codex CLIs installed, run it on real sessions:

export AGENT_RELAY_ROOT=~/relay-root
bin/relay init --participants codex claude
bin/relay console      # [n] launch Codex and Claude Code, [p] pair them, [s] start

The web console tour walks through every screen. The walkthrough shows a recorded run with real message and turn IDs.

The relay coordinates two sessions per team, one turn at a time. It sees each turn from the outside: the turn goes in, the client acknowledges it, and later the client reports it finished. What a session does inside a turn is invisible to the relay. That includes tool loops, subagents and long-running commands.

• The turn budget counts hand-offs, not work. One turn can hide a lot of activity. The per-turn timeout is the only hard limit inside a turn.
• The routes the relay starts are locked down where it can. A Claude Code follower starts with no tools at all, or, under the coding policy, with only Read, Edit, Write, Glob and Grep inside a macOS sandbox. It can't start subagents or run commands. Codex's multi-agent mode is recorded but not yet enforced.
• Sessions you open in a terminal keep whatever you allowed them until you hand them over.

The full list of guarantees and limits is in the reference.

Today, with the prototype:

• Plan, build, review. Codex writes the plan and reviews the result. Claude implements. The loop runs until the reviewer accepts or asks you something.
• A second opinion on every change. Use one model to critique the other's work before you ever see it, so you review a reviewed change.
• Bounded jobs you don't have to babysit. "Fix the failing tests in this folder, at most 8 turns, 15 minutes per turn." Walk away. A decision notification (webhook or SMS, off until you set it up) tells you when it needs you.
• Check in at a glance. The web console works down to phone width. It listens on loopback only, so reaching it from another device takes your own tunnel. The relay deliberately doesn't provide one.
• An audit trail of agent work. Every message and decision is a durable, hash-chained record that you can replay withrelay thread or rebuild from disk.

Ideas the design leaves room for (see the roadmap):

• One manager, many workers. A leader hands pieces of a migration to several followers, one per module, with review between them.
• Other agents. The adapter contract indocs/PROTOCOL.md isn't specific to Claude or Codex. Any coding agent that confirms receipt of a turn and reports completion could plug in.
• Saved playbooks. Reusable goal, scope, check and budget templates, such as "review this branch", "write the docs and fact-check them" or "upgrade this dependency".
• Custom manager styles. Write your own personality next to Reviewer, Planner and Pair programmer, as a plain text file.
• A testbed for agent-to-agent protocols. The bus is a small, durable, inspectable message layer. You can use it to study how agents hand work to each other, where loops stall, and when humans need to step in.
• Evaluation runs. Pit model pairings against the same task with the same budget, and compare the recorded threads.
• Cost and budget insights. Track tokens and time per team, not just turns.

   you ──start /  / answer──┐
                                 ▼
 ┌──────────────┐  handoff  ┌────────────┐  handoff  ┌──────────────┐
 │ leader       │ ◀──────── │ controller │ ────────▶ │ follower     │
 │ (Codex)      │ ────────▶ │ (fg only)  │ ◀──────── │ (Claude)     │
 └──────────────┘  result   └─────┬──────┘  result   └──────────────┘
                                  │
                          durable bus on disk

• Bus: an on-disk store of messages and events.
• Adapters: they talk to each client. Every capability is explicit, and adapters never invent acknowledgments.
• Controller: it runs only in the foreground and keeps exactly one turn in flight. It enforces the budget and the timeout, and stops at every human boundary.

Each turn ends with a small relay block that tells the controller what to do next. Commands, settings and exit codes are in the reference. The specification is in docs/PROTOCOL.md.

What's needed to get from prototype to dependable is in the roadmap. The details on each client are in integration feasibility.

This is a prototype, and ideas, experiments and pull requests are welcome. See CONTRIBUTING.md for setup and for the stricter rules for changes to the real-client adapters. Report security issues privately through SECURITY.md. This project follows the Contributor Covenant.