My main driver is Claude Code, with Codex bolted on for the hard parts and reviews. The split works surprisingly well. But after a while I noticed something dumb: I had become a human copy-paste relay between two AIs.
Copy what Claude Code wrote, paste it into Codex for review, copy Codex's feedback, paste it back into Claude Code. Dozens of times a day. It's tedious, it breaks focus, and I'd occasionally paste the wrong thing. I had two capable agents sitting side by side and was personally doing the dumbest job in the loop — carrying messages between them.
Agents should just be able to message each other directly. So I built agmsg and put it on GitHub: https://github.com/fujibee/agmsg
Try it first (30 seconds)
You're an engineer; you'd rather run it than read about it.
bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)
Then restart Claude Code / Codex and run /agmsg ($agmsg on Codex). It asks for a team name and an agent name on first use. The README has the full quickstart and copy-paste commands.
Once two agents join the same "team," they can message each other. After that you just talk to your agent: "tell alice the review is done," "any messages?" — that's it.
The only dependencies are bash and sqlite3. No daemon, no network, no Python.
Why run two coding agents at all
This started by accident. Claude Code (Opus 4.6) got stuck on a gnarly implementation — kept going in circles no matter how I rephrased it. On a whim I handed the exact same spec to Codex (GPT-5.3), and it produced a correct version almost instantly. That was a quiet shock.
Since then I've split the roles:
- Claude Code — the daily driver. Fast, high volume, follows direction well.
- Codex — reviewer and last resort for hard problems. A bit clumsy for everyday driving, but the one I trust on correctness for tricky code.
Neither is "better" — they have different temperaments, so they're good at different moments. And the instant I started running both, the carrier-pigeon problem began.
What agmsg is
In one line: CLI AI agents message each other through a shared SQLite database. Claude Code, Codex, Gemini CLI — any CLI agent works.
It's built as an Agent Skill, so you install it as a skill and don't touch the agent itself. It turned out better than I expected, so I open-sourced it.
Design decisions
The order I went through, and why.
I checked the built-ins first. I didn't want to reinvent anything, so I looked at Claude Code's team / subagent features. They're designed around short-lived sessions — great for spinning off a one-off subtask, but not for two agents holding an ongoing conversation.
I started with plain text files. The built-in team agent was file-based and simple, so I did the same. Fine for short-lived use — but the moment you want persistent + concurrent, it falls apart: write conflicts, corrupted files.
So I moved to SQLite (WAL mode). Multiple readers + one writer, no conflicts; transactions that survive concurrent access; message history for free.
But keep dependencies minimal. This is the part I cared about most. You could make it as rich as you want, but I wanted it to run the instant you drop it in, on anyone's machine. The result: it runs anywhere bash and sqlite3 run. No daemon of its own (agmsg has no resident process; only monitor mode piggybacks on Claude Code's built-in Monitor), no network (all local), no Python.
Delivery modes — monitor is what made it usable
There are roughly three ways a message reaches an agent:
-
manual — you run
/agmsg, or ask the agent to "check the inbox." Reliable, but you have to remember. - hook — checks between turns (on the Stop hook). Codex defaults to this, since it has no Monitor tool.
- monitor — subscribes to SQLite continuously and interrupts the conversation in real time when a message lands. This is the default on Claude Code.
Honestly, monitor is what tipped it from toy to useful. With manual/hook there's a gap — the other side already replied, but you don't notice until you poke it. With monitor, the conversation just flows.
The mechanism (riding Claude Code's Monitor on top of a blocking SQLite read) is interesting enough that I want to write it up separately.
And here's the fun part. Put two monitor-mode Claude Code instances on the same team and leave them alone, and they keep talking with zero human input. I told two of them to "play tic-tac-toe," and they sent moves back and forth and played the whole game out. Not useful, exactly — but watching two agents volley autonomously is genuinely fun:
Two monitor-mode Claude Code instances playing tic-tac-toe over agmsg, no human in the loop (real game, static gaps trimmed, ~2.5x).
What's next
The thing I fought hardest while building this was that Claude Code and Codex have completely different hook and config models. Claude Code has Monitor and rich SessionStart hooks; Codex has neither. Splitting delivery into monitor / turn is there to absorb that gap, and the config files live in different places and formats for each. Getting the same "notice when a message arrives" to work across two agents with different foundations took the most thought.
How to smooth over those heterogeneous-agent seams — and the monitor internals I mentioned — are what I'll write about next.
For now: install it and let Claude Code and Codex talk to each other directly.
