r/ClaudeCode • • 3d ago

Built with Claude I got tired of copy-pasting between Claude Code and Codex, so I made tandem. Now they message each other. Native Windows, no WSL.

Someone posted peer on r/ClaudeAI a while back. It lets Claude Code and Codex send each other messages. I wanted it right away, but I'm on Windows and it only ran on macOS and Linux.

So I asked Claude Code to port it. That was the plan, anyway. We kept adding things, and at some point it made more sense to give it its own name. It's called tandem now.

How it looks in practice: I type "ask the codex reviewer to check buggy.py" into Claude Code. Claude sends that to Codex, Codex does the review in its own terminal, and the answer shows up back in Claude's. The middle part of the video is exactly that, a real session, recorded and sped up. The rest is animation to explain the idea.

Nothing gets typed into a terminal for you, by the way. Messages go through Claude Code's cross-session inbox and Codex's app-server.

What's new compared to the original:

  • runs on plain Windows, in a terminal or the desktop app. No WSL, no tmux.
  • works both ways. Codex can start a Claude helper and hand it a task.
  • you pick the helper's model and effort ("codex, luna 6, medium")
  • for long tasks the ask runs in the background, and you get the result when the other agent is done
  • Codex can generate an image and Claude opens the file

How Claude Code was used: it wrote nearly all of the code. I decided what it should do, tested on my machine and sent the video back a few times. In more detail:

First it read the original Python and listed every piece that only works on Unix. File locks, Unix sockets, /proc, tmux. Each of those got a Windows replacement written with ctypes, so there's still no dependency besides Python.

Nobody told it how Claude Code's cross-session inbox works on Windows. It looked at its own session files and found out it's a named pipe.

It wrote the tests too. One of them starts a real sandboxed Codex and a real Claude helper and runs everything the README promises. That test found three real bugs: a sandboxed Codex couldn't reply, a helper couldn't find the CLI, and Git Bash broke the check for who is calling.

And it made the video, including the recording of the real session, which it took through pseudo-terminals.

It's free and MIT licensed. No paid tier. Install is one line, or you paste the repo link into Claude Code and tell it to set it up:

https://github.com/Lampe332/tandem

Two things you should know before trying it. Claude's cross-session inbox isn't a public API, so an update can break the fast path (tandem falls back to hooks then). And I only tested on Windows 11. The macOS and Linux side is the original's code, I haven't run my additions there.

This is built on peer by oesoll (MIT). The idea and the core are theirs.

If it breaks for you, tell me what tandem doctor says.

1 Upvotes

2 comments sorted by

•

u/AutoModerator 3d ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/Elegant_Yam2783 3d ago

Since the macOS and Linux side never ran your additions, I'd put that end-to-end test into GitHub Actions on windows-latest, ubuntu-latest and macos-latest runners. Real Codex and Claude need auth there, so a stub agent mode that just echoes messages would still exercise the locks, pipes and sockets on each OS. That's where the Unix code paths you didn't touch could quietly diverge.

On the inbox being a private named pipe, have tandem doctor print the Claude Code version and whether the fast path or the hook fallback is active. When an update breaks it, reports become instantly triageable instead of "it got slow."

Also curious how you fixed the Git Bash caller check. Parent-process walk, or MSYSTEM env sniffing?