Claude Code 和 Codex 怎么一起用？我写了个工具让它们互相叫醒、互发消息，还能跨电脑

我日常同时开好几个 AI 编码会话：一个 Claude Code 写功能，一个 Codex 做 review，一个 Pi 跑杂活。它们各自都挺能干，问题是互相看不见。想让 Codex 看一眼 Claude 刚写的 diff，只能我自己复制、切窗口、粘贴，再把回复搬回去——人成了两个 AI 之间的剪贴板。

Claude Code 和 Codex 其实都有原生的跨会话能力，但只在各自产品内部有效，到产品边界就停了。所以我写了 ocs（Open Cross-session）：一个单文件二进制，让 Claude Code、Codex、Pi 和终端里的 agent 互相发消息、互相叫醒。不要服务器，不要账号，数据全在本机 ~/.ocs。

用起来是什么样

装好之后，对任何一个会话说一句「找个 agent 帮你看看这段」，它会自己去找同伴。手动也很简单：

ocs who                                   # 本机有哪些活着的会话
ocs dm codex-01a06a98 "帮我审下这个 diff"   # 发给 Codex，并把它叫醒
ocs rename reviewer                       # 给当前会话起个好记的名字
ocs send dev "进展如何？@reviewer"          # 多方频道，@ 谁就叫醒谁

对方收到的不是「文件里多了一行」，而是会话里直接冒出一条消息，末尾带着一行现成的回复命令：

[ocs 唤醒] claude-7043ea85 在 #dm-… 提到了你（seq 7）

帮我审下这个 diff

回复：ocs dm claude-7043ea85 "<your reply>"
线程：ocs read dm-…

它照着回复，你这边就被叫醒。两个 agent 就这样来回聊，你在旁边 ocs watch 看着就行。

0.6：跨电脑

最新的 0.6 把这件事扩到了局域网。我家里一台 Mac、一台 Windows，现在 Mac 上的 Claude 可以直接把「在 Windows 上跑一下构建」交给 Windows 上的 Claude 或 Codex：

# 机器 A                          # 机器 B
ocs lan up                       ocs lan up
ocs lan pair   # 打印配对码  →   ocs lan pair 7K2M-9QXD-…
                                 ocs dm claude-1a2b3c4d@mini "帮我在 Windows 上跑一下构建"

让陌生机器能往你的 AI 会话里塞话，安全必须先想清楚，所以这部分是按「局域网里有坏人」来设计的：

• 身份只认公钥：每台机器一把 Ed25519 密钥，IP、机器名、对方自报的名字都只当提示。
• 配对一次，没有「首次连接即信任」：配对码里带着发码方公钥指纹的前缀，连上后先核对对方公钥，核对通过才发自己的身份和请求。
• 双向认证、全程加密：带签名的 X25519 握手 + AES-256-GCM，有前向保密。
• 未配对的机器什么都干不了：除了兑现一个有效配对码，其他请求一律拒绝，连帧大小都限制在 1 KiB；配对码输错 5 次作废。
• 默认关闭：ocs lan up 才开。远端发来的消息在本机一律显示成 名字@你给它起的标签，对方改不了。

踩过的坑：「成功」不等于送到了

做消息系统，最危险的不是报错，而是看起来成功、其实丢了。ocs 里好几条铁律都是这么来的。

1. Claude 返回 ok，不代表消息进了对话。 往 Claude Code 会话注入消息，socket 那头会回 ok:true。但 Claude 的 crossSessionInbound 默认是 hold：消息进待审队列，5 分钟没人处理就静默丢弃。所以 ocs 从不拿这个 ok 当「已送达」，ocs doctor 会检查这一项，引导你改成 accept。

2. codex queue 是写存储，不是投递。 终端里的 Codex 只能用官方的 codex queue 塞消息，但它只是把消息写进 thread 存储——目标会话早就退出了，它照样返回成功。ocs 的做法是发之前先证明会话还活着：用 lsof 找持有那个 rollout 文件的进程。后来又发现，一些索引类的第三方进程也会持有这些文件，于是再加一道身份校验：持有者本身或它的祖先进程必须真的是 codex，否则当作不在线，消息留在收件箱里等它上线。

3. 结果未知，绝不重发。 和 ChatGPT Desktop 通信走的是它的私有 IPC。帧已经写出去、却没等到回应时，消息可能到了，也可能没到。这时候重发，最坏情况是对方收到两条同样的指令、干两遍活。ocs 把「结果未知」当成一等状态单独报告（退出码 3），永远不自动重试，让人或上层来判断。

4. 序号只有一个真值源。 每条消息有一个单调递增的 seq。早期版本把「当前 seq」另存了一份文件，结果一次崩溃发生在「日志写完、seq 文件还没更新」之间，重启后发出了重复 seq，读取端按 seq 去重，把后来的消息永久遮蔽了。现在 seq 只从日志本身推导（加锁读日志尾），这个问题有回归测试钉着。

这些坑单拎出来都不难，难的是它们在正常测试里全是绿的。

安装

# 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

安装器会顺带给 Claude Code、Codex、Pi 装上 ocs 的 skill，装完跑一次 ocs doctor --fix 体检。支持 macOS、Linux、Windows，MIT 开源。

如果你的场景超出了一个局域网——不同网络、团队协作、跨组织——同样的用法可以平移到 Agent Party，支持托管，也能私有部署。

• GitHub：leeguooooo/open-cross-session
• 协议与威胁模型：docs/lan.md

有问题或想法，欢迎在 GitHub 提 issue，或者在下面留言。

作者：郭立（leeguoo），全栈工程师，最近在做一系列让 AI agent 真正能干活的工具：chrome-use、iphone-use、mail-use 等。