Claude Code and Codex can have real-time conversation via Git (opens in new tab)

Claude can directly drive Codex or Codex can drive Claude. Both already produce logs. It's unclear what value this intermediary brings.

I have started sandboxing all AI's in their own VM, and interfacing with them primarily through Jira and Git.

It really is the only thing that makes sense. Completely sandbox'ed, and treated like the junior programmer who will do, literally, any dumb thing you tell them to do, as long as there is an Issue for it.

Claude and Codex can have real time conversation via a git repo, or via a file, via a Unix socket, via the terminal, via a human, via two humans shouting back and forth over a comically high office partition, or entirely by setting up chess board states only reachable after both sides have castled.

This is actually so great. I mainly use Claude Code but sometimes I am sending over a message to Codex asking what he thinks of the idea of Claude Code. This can save so much time :D

I'll be impressed if a Claude and a Codex instance improvise a channel like this spontaneously on their own.

Doing this intentionally via prompt doesn't seem very interesting.

Related is Beads [0] which is an external memory and task based issue tracker. Also designed to allow agents to collaborate. I have not actually used Beads but since we are share basics in this space it's a cool one to know if you are looking at ways for agents to collaborate on more complex problems.

0 - https://github.com/gastownhall/beads

I really like this direction, I'm interested in more protocols and innovation aligned with human supervision and provenance. What else is out there on this topic?

I let them talk via tmux, two panes, each has an agent and agents know how to send text via tmux to panes.

Won't appending to .jsonl keep creating conflicts?

The better way to do this is give them each an inbox and outbox folder and a user account on a Unix machine.

They can write to their outbox, have it be sent to the other's inbox. A watcher can watch for new messages in the inbox and trigger the other agent to read it. You can have the thread Id of the messages correspond to the session id.

We don't need to reinvent things that Unix provides.

I have agents chat via an append only file, across related projects and within the same project. They share findings that are useful and get high level reviews.

I'm missing the advantage of using git for this. (Not criticism, genuinely want to know).

I like this and think it's a great idea. Leveraging git makes a lot of sense (content addressed filesystem, efficient storage and sync protocol with pack files etc ..., widely deployed).

From a cursory look my impression is that it deviates from git too much and therefore I can't use my git knowledge to predict how it will behave. I'm quite rusty on git internals but afair .git/refs/ is great because you can do what you like in there but the downside is that it doesn't hook into the rest of the git structure.

So how does this work with branches, worktrees, etc...? Having a jsonl message log in .git/refs/h5i/msg seems very linear. Presumably you store commit refs in the json obj or context dag, but what if I rebase the branch and the original commits are dropped because they're not referenced anymore? Or say I follow the conversation and want to rewind a few messages and branch from there in a separate worktree, how does that work?

Your repo README does say:

- "It uses dedicated refs, so it doesn’t pollute your working tree or your normal branch graph."

- "Because these are Git objects, they are content-addressed, deduplicated, pushable, fetchable, and survive `git gc`."

- "Because the log lives in refs/h5i/msg, a conversation survives clones, machines, and branches — it travels with h5i share push / pull, and divergent sends from two machines union-merge with no message lost."

Therefore these look like design decisions and it would be nice to understand them better.

My first instinct would be to put most of what you have under .git/refs/h5i/ in a .h5i folder in the repo itself and manage some shadow branches under .git/heads/.h5i/ with multi-parent commits pointing at the context commit as well as the previous h5i message commit along with some hooks to handle rebases etc ... . That way battle hardened git machinery gets used and more importantly to me, I can leverage my existing git knowledge to understand dependencies. That would go against your "it doesn’t pollute your working tree or your normal branch graph" goal but I'm of the "explicit is better than implicit" Python school so I like to have the details exposed as long as I can filter them out easily (or by default).

For some reason when 2 different products communicate it's more impressive and antropomorphic and AGI and chic than the same model communicating with an instance with different context

In my recent quest to build agent-as-primary-user tools I've built grpvn (https://github.com/frane/grpvn), a small Go/SQLite application that lets skill- and mcp-capable agents talk to each other. Biggest issue is the lack of a hook system so the agents can autonomously read and respond. Waiting for this to be supported, as IMO multi-agent teams talking to each other are an interesting next step.

This is really cool!

Essentially version controlled A2A.

I'm exploring a bunch of agent protocols right now and experimenting with a similar concept for context syncing over git here: https://github.com/cjroth/csp

People are really intent on making "real-time" not mean a single damn thing.

You can also do this cross computer. It’s how I debug problems.

I actually built a memory system off git. https://github.com/ryanthedev/grug-brain.mcp

I do this via a simple local MCP tool provided to every harness, that creates a single sqlite .db file in all my repo roots. Anyone can drop in and see what the team is working on, join in, and ask for something to do.

Counting the days 'till we rediscover the blackboard architecture.

This might be more suitable as a basis for this sort of thing... https://git-meta.com/

the bottleneck with multi-agent setups isn't getting them to talk. it's getting a human to review what they agreed on before it ships.

Migrating my group chats to github as we speak. This will teach Apple a lesson about keeping iMessage closed.

I have always wanted to make the human E2EE version of this.

In my project I let the agents communicate in GitHub issues and pull requests like humans do. I kinda stopped trying making orchestration frameworks.

You can see the slop here

https://github.com/mohsen1/tsz

what could possibly go wrong?

I kind of have a feeling that this is dumb. Sounds like an expensive patch for lack of robust task specification.

This is interesting, it would be good to show an session.

> Claude Code and Codex to collaborate as if they were having a real-time conversation

How is this new? I vibe coded something in a similar vein months ago. In my case they send markdown files to each other and have a watcher that watches the folders of all the other agents.

If this type of stuff is frontpage news, let me share what I cobbled together.

  ls ~/.agent/projects/<my_project>/callgraph

  callgraph.current.md         callgraph.last.read.agent.md
  callgraph.diff.md

The current callgraph is a callgraph only of my own defined functions that agents can read. It shows certain software design issues fairly quickly. callgraph.diff.md is to send the diff through. I have a vibecoded script that agents can use to create the callgraph. It works for my projects.

  ls ~/.agent/projects/<my_project>/memo
  architect   coder  retro     tester

retro is not a role, it's just a handover folder. The other 3 are roles that agents can use and then they need to make a folder with their name. For example:

  ls ~/.agent/projects/<my_project>/memo/architect
  1_Daedalus     3_Brunelleschi 5_Wren         7_Sinan
  2_Vitruvius    4_Imhotep      6_Hadid        8_Palladio

  ls ~/.agent/projects/<my_project>/memo/architect/7_Sinan
  20260507___1802_to_Hadid.md    20260507___2035_to_Quench.md
  20260507___1959_to_Crucible.md 20260511___1401_to_Quench.md
  20260507___2008_to_Quench.md   20260511___1403_to_Quench.md
  20260507___2030_to_Quench.md   read.md

read.md is the index that an agent keeps track of so it knows what it doesn't need to read. The .md files are memo's that it sends to other agents. The other agents are being told to see if an agent writes anything in its own folder (so they check all the folders except their own) and are able to detect to see if they need to read something.

  ls ~/.agent/projects/<my_project>/memo/coder
  10_Mallet   12_Crucible 14_Swage    2_Forge     4_Anvil     6_Tongs     8_Chisel
  11_Auger    13_Quench   1_Atlas     3_Rivet     5_Bellows   7_Hammer    9_Vise

As you can see, Sinan sent most of its message to Quench, a coder.

This is because architects read a very comprehensive guide on software design/architecture and get to use the callgraph utility but cannot see the code. Coders read the codebase in full but only read a small markdown file on how to write readable code. And of course, every agent that is set up this way have to read a markdown file on how to use the memo system.

If I'd need a memo system like this for like 25 agents, I'd need something different but up until 5 agent with me looking at 5 terminal windows worked well enough.