# How Can Claude Code and Codex Work Together? I Built a Tool That Lets Them Wake Each Other Up, Send Messages, and Even Work Across Computers

I routinely keep several AI coding sessions open at the same time: one Claude Code session writing features, one Codex session doing review, and one Pi session running miscellaneous tasks. Each is quite capable on its own. The problem is that they cannot see each other. If I want Codex to look at a diff Claude just wrote, I have to copy it myself, switch windows, paste it, then carry the reply back—the human becomes the clipboard between two AIs.

Claude Code and Codex actually both have native cross-session capabilities, but they only work inside their own products and stop at product boundaries. So I built ocs (Open Cross-session): a single-file binary that lets Claude Code, Codex, Pi, and terminal agents send messages to each other and wake each other up. No server, no account, and all data stays locally in ~/.ocs.

What It Looks Like in Use

After installation, you can say to any session, “Find an agent to help you look at this,” and it will go find a companion by itself. Manual use is simple too:

ocs who                                   # Which live sessions are on this machine
ocs dm codex-01a06a98 "Help me review this diff"   # Send to Codex and wake it up
ocs rename reviewer                       # Give the current session an easy-to-remember name
ocs send dev "How’s progress? @reviewer"          # Multi-party channel; whoever you @ gets woken up

What the other side receives is not “one more line appeared in a file,” but a message that appears directly inside the session, ending with a ready-made reply command:

[ocs wakeup] claude-7043ea85 mentioned you in #dm-… (seq 7)

Help me review this diff

Reply: ocs dm claude-7043ea85 "<your reply>"
Thread: ocs read dm-…

It follows the reply command, and your side gets woken up. The two agents can chat back and forth like this while you watch from the side with ocs watch.

0.6: Across Computers

The latest 0.6 extends this to the local network. I have one Mac and one Windows machine at home, and now Claude on the Mac can directly hand off “run the build on Windows” to Claude or Codex on the Windows machine:

# Machine A                       # Machine B
ocs lan up                       ocs lan up
ocs lan pair   # prints pairing code  →   ocs lan pair 7K2M-9QXD-…
                                 ocs dm claude-1a2b3c4d@mini "Help me run the build on Windows"

Letting an unfamiliar machine inject messages into your AI sessions means security has to be considered up front, so this part is designed under the assumption that “there may be bad actors on the local network”:

• Identity is based only on public keys: each machine has one Ed25519 key. IP address, machine name, and the name the other side reports for itself are only treated as hints.
• Pair once, with no “trust on first use”: the pairing code includes a prefix of the issuer’s public-key fingerprint. After connecting, the peer’s public key is checked first; only after it passes does the machine send its own identity and request.
• Mutual authentication and encryption throughout: signed X25519 handshake + AES-256-GCM, with forward secrecy.
• Unpaired machines can do nothing: except redeem a valid pairing code, all other requests are rejected, and even frame size is capped at 1 KiB; a pairing code is invalidated after 5 wrong attempts.
• Off by default: it only starts when you run ocs lan up. Messages from remote machines are always shown locally as name@the-label-you-gave-it, which the other side cannot change.

Pitfalls: “Success” Does Not Mean Delivered

When building a messaging system, the most dangerous thing is not an error—it is looking successful while actually losing the message. Several hard rules in ocs came from exactly this.

1. Claude returning ok does not mean the message entered the conversation. When injecting a message into a Claude Code session, the socket returns ok:true. But Claude’s crossSessionInbound defaults to hold: the message enters a review queue and is silently discarded after 5 minutes if no one handles it. So ocs never treats this ok as “delivered.” ocs doctor checks this setting and guides you to change it to accept.

2. codex queue writes to storage; it is not delivery. Terminal Codex can only receive messages through the official codex queue, but that merely writes the message into thread storage—if the target session exited long ago, it still returns success. ocs first proves the session is alive before sending: it uses lsof to find the process holding that rollout file. Later I found that some indexing-related third-party processes can also hold these files, so I added another identity check: the holder itself or one of its ancestor processes must actually be codex; otherwise it is treated as offline, and the message stays in the inbox until it comes online.

3. If the result is unknown, never resend. Communication with ChatGPT Desktop goes through its private IPC. If a frame has already been written but no response arrives, the message may have arrived, or it may not have. If you resend at that point, the worst case is that the other side receives two identical instructions and does the work twice. ocs treats “unknown result” as a first-class state and reports it separately (exit code 3). It never retries automatically, leaving the decision to a human or an upper layer.

4. There must be only one source of truth for sequence numbers. Each message has a monotonically increasing seq. Early versions stored the “current seq” in a separate file. Then one crash happened between “log write completed” and “seq file not yet updated,” and after restart, a duplicate seq was sent. The reader deduplicated by seq and permanently masked the later message. Now seq is derived only from the log itself by reading the log tail under a lock, and this issue is pinned down with a regression test.

Each of these pitfalls is not hard in isolation. The hard part is that they all pass normal tests.

Installation

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/leeguooooo/open-cross-session/main/install.sh | sh

# Windows (PowerShell)
irm https://raw.githubusercontent.com/leeguooooo/open-cross-session/main/install.ps1 | iex

The installer also installs the ocs skill for Claude Code, Codex, and Pi. After installation, run ocs doctor --fix once for a health check. It supports macOS, Linux, and Windows, and is open source under MIT.

If your use case goes beyond one local network—different networks, team collaboration, or cross-organization work—the same usage model can be moved to Agent Party, which supports both hosted and private deployments.

• GitHub: leeguooooo/open-cross-session
• Protocol and threat model: docs/lan.md

If you have questions or ideas, feel free to open an issue on GitHub or leave a comment below.

Author: Guo Li (leeguoo), full-stack engineer, recently building a series of tools that help AI agents actually get work done: chrome-use, iphone-use, mail-use, and more.