# Claude Code 和 Codex 如何协同工作？我做了一个工具，让它们能互相唤醒、发送消息，甚至跨电脑协作

我经常同时开着几个 AI 编程会话：一个 Claude Code 会话负责写功能，一个 Codex 会话负责做评审，还有一个 Pi 会话运行各种杂项任务。每个会话单独来看都相当能干。问题在于它们彼此看不见。如果我想让 Codex 看看 Claude 刚写出的 diff，我必须自己复制、切换窗口、粘贴，然后再把回复带回去——人类变成了两个 AI 之间的剪贴板。

Claude Code 和 Codex 实际上都有原生的跨会话能力，但它们只在各自的产品内部有效，一到产品边界就停住了。所以我做了 ocs（Open Cross-session）：一个单文件二进制工具，让 Claude Code、Codex、Pi 和终端代理可以互相发送消息，并且互相唤醒。不需要服务器，不需要账号，所有数据都本地保存在 ~/.ocs。

使用起来是什么样

安装之后，你可以对任意会话说：“找个代理来帮你看看这个”，它就会自己去找一个搭档。手动使用也很简单：

ocs who                                   # 这台机器上有哪些活跃会话
ocs dm codex-01a06a98 "Help me review this diff"   # 发送给 Codex 并唤醒它
ocs rename reviewer                       # 给当前会话起一个好记的名字
ocs send dev "进展如何？@reviewer"          # 多方频道；被你 @ 的人会被唤醒

另一边收到的不是“文件里又多了一行”，而是一条直接出现在会话里的消息，末尾还带着现成的回复命令：

[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-…

它照着回复命令执行，你这边也会被唤醒。两个代理就可以这样来回聊天，而你在旁边用 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 时才会启动。来自远程机器的消息在本地始终显示为 name@the-label-you-gave-it，而这个标签对方无法更改。

坑点：“成功”并不等于已送达

在构建消息系统时，最危险的事情不是报错，而是看起来成功了，实际上却丢了消息。ocs 里的几条硬规则，正是由这些问题催生出来的。

1. Claude 返回 ok，并不代表消息进入了对话。 向 Claude Code 会话注入消息时，socket 会返回 ok:true。但 Claude 的 crossSessionInbound 默认是 hold：消息会进入一个审核队列；如果无人处理，5 分钟后会被静默丢弃。所以 ocs 从不把这个 ok 当成“已送达”。ocs doctor 会检查这个设置，并引导你把它改成 accept。

2. codex queue 写入的是存储，并不是送达。 Terminal Codex 只能通过官方的 codex queue 接收消息，但它只是把消息写进线程存储——如果目标会话很早以前就已经退出，它依然会返回成功。ocs 会先证明该会话仍然存活，再发送消息：它使用 lsof 找出持有对应 rollout 文件的进程。后来我发现，一些与索引相关的第三方进程也可能持有这些文件，于是又加了一层身份检查：持有者本身，或它的某个祖先进程，必须确实是 codex；否则就被视为离线，消息会留在 inbox 中，直到它上线。

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，或在下方留言。

作者：Guo Li (leeguoo)，全栈工程师，最近在构建一系列帮助 AI agent 真正把事情做完的工具：chrome-use、iphone-use、mail-use 等。