Real 84EM email is only @84em.com

Claude and Codex, Coordinating Through One Shared File

A few weeks ago I wrote about coordinating two Claude Code sessions through a shared markdown file. One agent writes to the file, the other appends answers, and I watch both halves in one window. No server, no API, just a file both agents can already read and write.

That version was built for two Claude sessions on one Linux box. Since then I rewrote the command so it does not care what is on either end, or what operating system it runs on. Then I used it to build a real feature with Claude on one side and Codex on the other.

A tuxedo cat nestled against a bearded man on a couch under a starfield pillow, both looking at the camera, captioned TWO AGENTS above and ONE FILE below

Two different agents, one file

The project was a headless build: a WordPress plugin exposing a REST API on the backend, and a Hugo site consuming it on the frontend. The two ends had to agree on the exact contract, so the agents building them could not work blind.

I ran Claude Code on the frontend and Codex on the backend. Same trick as before: one shared file in the temp directory, append-only, with a numbered log both sides write to.

Claude opened the session, created the file, and posted the first entry: confirm the backend baseline is green, confirm the endpoint contract, and flag a CORS gap that would block end-to-end testing. Then it proposed a split, one task each, plus a joint one.

A Claude Code terminal that has created a shared collab file in the temp directory, printed the relay message describing the append-only numbered-log protocol, and posted its opening entry to the other agent with three questions and a task split

Codex, on the backend, read the whole file and then did something I did not tell it to: it verified the current plugin state before replying, so its answer would be concrete instead of a guess. A different model, driving itself, following the same protocol.

A Codex terminal reading the shared collab file, noting there is one pending question from the other agent, and running commands to verify the backend state before appending its reply

What changed in the command

Three things, and they are the whole point of the rewrite.

It is agent-agnostic. The roles are fixed: whoever runs the command is Agent A, the collaborator is Agent B, and those labels hold for the whole session no matter who writes next. Nothing in the protocol assumes Claude. Agent B can be a different AI, or a person driving one. The file does not know or care.

It is OS-agnostic. The old version hardcoded /tmp. The new one resolves the temp directory the way the current platform does: $TMPDIR or /tmp on Linux and macOS, %TEMP% on Windows. The watch step uses whatever the OS offers to check for a file change, never a command that only exists on one platform.

It is turn-based, not a busy loop. The old watch loop polled every five seconds forever. The new one takes one turn: check the file, surface anything new, append a reply, and hand control back to me. It waits for one bounded interval instead of spinning. Each entry is numbered, timestamped in UTC, tagged [question], [answer], or [note], and appended to the end. Nothing above the log is ever edited, so the file stays a clean audit trail of the exchange.

The limits are still real

It is still local-only. Both agents share one filesystem, and the handoff is manual: I paste the file path into the second agent myself. The temp file does not survive a reboot, and there is no locking beyond append-only discipline. For two agents in one sitting on one machine, coordinating a build where the two halves have to line up, none of that has gotten in the way.

It is still one command file. Here’s the whole thing: collab.md. No code, just a template, a join message, and the turn-based watch instructions.

Need some help?

Reach out and describe your project.

Folks We've Helped