I wanted my Claude Code and Codex cli sessions to be able to ask each other questions and exchange review feedback without me copying messages between terminals. I used Claude and Codex to build a small local bridge, and the first live conversation just worked in both directions. The setup is one user on one Linux machine, using interactive CLI sessions. Each session gets a handle when I launch it using bridge [model] [handle] : bridge codex builder bridge claude reviewer Both agents have a shared skill explaining three commands: bridge whoami , bridge list , and bridge send . Once the sessions are ready, an agent can send something like: bridge send reviewer “The change is ready. Please review it.” The message appears in the recipient’s conversation with the sender’s handle. Each session keeps its own context, instructions, and permissions. The main workflows I’m aiming for are: 1) one agent implementing a change, another reviewing it, and questions going directly between them, and 2) two agents working in separate worktrees in the same repo, needing to coordinate eg. merges and rebases. These are the situations that have been keeping me busy as the messenger between agents. Claude sessions can message each other natively which has been truly great and I wanted the same with Codex. The bridge is Node 22 with only the standard library. Messages to Codex go through codex queue; messages to Claude arrive through a small MCP channel server connected to a local Unix socket. The bridge stores temporary session registration metadata and leaves message history to the receiving harness. Keeping the scope under control was the major challenge until now. I initially let Sol 5.6 Ultra orchestrate the design, planning, and implementation fairly autonomously as this was a hobby/tool project and I was ready to scrap it if needed. I also had tokens to burn when Tibo announced that a reset was coming and suggested to go all in until then. So I did. When I came back to inspect the first MVP version, I noticed that rounds of adversarial reviews had kept turning hypothetical problems into new, very rigid requirements. Sol had ended up writing and implementing a plan of 17 tasks and roughly 28,000 words, building a custom trusted build runner, and elaborate Git provenance checks before the bridge could even send a message. I put a stop to the work and turned to Fable 5 to plan a reset around the original goal: a small contract and four tasks using the CLIs’ native mechanisms. This and similar learnings from other hobby projects (eg. a Sonos TUI I’d been vibing and also had to scrap as it had been hardened to NASA grade security requirements) has given me a clear need to define a set of skills to keep Codex in check. One takeaway has been that reviewers need the same explicit scope and threat model as implementers, and proposed scope expansions need to be deferred by default and verified by the orchestrator against the original “scope anchor”, ie. my initial prompt defining the goal. A separate technical snag in the actual working implementation was session identity. With Codex 0.153.4, the terminal client connected to a shared app-server. The client had the handle I’d put in its environment, but the server owned the conversation files and executed shell commands. Our original process-based discovery kept reporting Codex as starting, while Codex itself reported no bridge handle. Giving it another prompt or closing the Desktop app connecting to the remote app-server didn’t solve that mismatch. The fix was to pass the handle through Codex’s per-session configuration and use native hooks to register the thread identity supplied by Codex. Hook approval in /hooks matters: a skipped startup hook can register on a later prompt once trusted. We stopped using open conversation files to decide which thread belonged to a handle. Fable 5.1 helped diagnose the process mismatch; by this time Astra 6 had shipped and it implemented the registration change and regression tests. Today I finally ran the real check: Claude sent a message, Codex replied, and Claude acknowledged receiving it. I watched them send and receive the messages in real time. This is still a prototype for my setup and it requires enabling –dangerously-load-development-channels when launching Claude. The live result so far covers one Claude and one Codex session; checks involving multiple Codex sessions, subagents, and session cleanup are still pending. The native integrations also need checking as the CLIs change. I’m keeping the repo private because this has been 100% vibe coded and is not fit for sharing publicly. If there’s interest I’m certainly happy to share implementation details and lessons learned. Or gotchas if you prefer the Claudism. submitted by /u/tulensrma
Originally posted by u/tulensrma on r/ClaudeCode
You must log in or # to comment.