同一台机器上开着的几个 Claude Code，从此不再是互不知情的孤岛。
常年开三四个终端跑 Claude Code 的人，大概都熟悉这种场景：A 窗口在重构公共模块，B 窗口正基于旧接口写业务代码，等你发现的时候 B 已经错着写了二十分钟。过去解决它只能靠人肉——你自己记住、自己切窗口、自己复述一遍。这次更新是把这段人肉搬运做进了产品里。
机制并不复杂。Claude 手上多了两个工具：ListAgents 用来列出当前能够联系到的会话，SendMessage 按名字把一段文字投递过去。官方文档写得很直白：在 macOS 和 Linux 上这两个工具自动可用，不需要任何配置，版本要求 v2.1.224 或更高。
值得留意的是它传的是什么。消息是一个 Claude 写给另一个 Claude 的一段文本，不是对话历史，也不是文件——纯文本，没有结构化载荷。这个限制看着像功能没做完，其实是刻意的：如果允许直接甩上下文和文件过去，接收方就等于凭空拿到了一份自己没有权限来源的材料，权限模型立刻会失去边界。限定成一句话，最坏情况也只是一句不准确的话。
TG 频道消息里提到的几种用法——发现传递、并行任务协调、长任务状态回报、跨设备回复——本质上都是同一件事的变体：让另一个会话提前知道一件它自己查不到的事。
这条边界是整个功能里最该看清楚的部分。按官方说明，同一台机器上的会话之间，消息通过本地套接字传递，不会到达 Anthropic 的服务器；只有跨机器的中继才会经由 Anthropic 的服务器转发，而且是只允许回复（reply-only）的形态——你可以隔着设备回一句，但不能拿它当一条任意的对外通道。
再加上一层节流：同一个发送方重复发消息会被限速，短时间内到达的完全相同的重复消息会被直接丢弃，单个会话的未读队列上限是 50 条。这些数字不起眼，但它们决定了这个功能不会退化成会话之间的消息风暴——两个 Claude 互相"提醒"到死循环，是这类设计里最容易踩的坑。
默认情况下，消息放行还是拦截由双方的权限模式自动决定；想手动管，配置项是 crossSessionInbound，可以设成 accept（收）、hold（挂起等你处理）或 refuse（拒收）。
更关键的一句在官方描述里：收到的消息不会绕过权限提示，也无法修改配置或执行命令。换句话说，别的会话发来的话对接收方来说只是"有人跟我说了句话"，它想据此动手，该弹的确认照弹。这一点必须成立，否则跨会话消息就是一条现成的提示注入管道——让一个会话读到不可信内容，再由它去驱动另一个手上有更高权限的会话干活。
原生 Windows 暂时不支持，Amazon Bedrock、Google Cloud Agent Platform 这类平台上也用不了。前者的原因大概率就在实现方式本身：同机通信依赖 Unix 域套接字这类本地 IPC，Windows 上要换一套东西重做。后者则更像是边界问题——托管平台上的会话属于谁、算不算"同一台机器"，本来就没有干净答案。Windows 用户想尝，现实路径还是 WSL。
把它放回 Claude Code 这一年的变化里看，方向是清楚的：从"一个终端里的一个助手"，走向"一台机器上的一群代理"。好处很直接，代价是权限模型又厚了一层——你现在要关心的不只是某个会话能做什么，还有它能从谁那里听到什么。真要多开着用，Claude Code 的基础配置先理顺，比急着让几个会话互相喊话更值。另外，跨设备那条中继是要过 Anthropic 服务器的，网络不稳的环境下它会是第一个失灵的部分——真遇到只有跨机回复不通，先用 Claude 可用性检测确认一下出口本身有没有问题，再去怀疑功能。