两个 Claude Code 终端各自跑着不同模块的开发任务。左边的会话在重构 user-profiles 的数据模型，把 users.name 改为 users.display_name；右边的会话在写 weekly-digest 的聚合逻辑。改完之后，左边的会话直接告诉右边"我把用户档案字段改了"，右边收到消息后在当前任务中接手处理。不需要你在两个终端之间复制粘贴任何内容。
这是 ClaudeDevs 发布的官方演示视频（本文使用本地降级 GIF，原始发布为视频）。本文基于官方发布素材，不是作者实测。
官方原帖为视频；此 GIF 仅用于本地跨平台降级。）
基本条件
跨会话消息要求 Claude Code v2.1.224 或更高版本，支持 macOS 与 Linux（含 WSL 2），原生 Windows 暂不支持。Amazon Bedrock、Claude Platform on AWS、Google Cloud Agent Platform 和 Microsoft Foundry 当前不在支持范围内。跨机器主动联系 Remote Control 会话是 v2.1.225 新增能力。
一个容易混淆的点：跨会话消息只传递纯文本，不传递完整对话历史或文件。想在另一个终端继续同一段完整对话，应该用 Resume。消息通道带有重复消息抑制、速率限制与队列上限（每会话 50 条），防止会话循环无限放大。长时间运行的 claude -p 会话可以绑定 inbox 接收消息，但 bare mode 不绑定。
消息怎样送达
会话之间怎么找到彼此、怎么发消息？
Claude Code 内置了两个工具：ListAgents 用来发现当前可达的会话，SendMessage 按会话名称投递消息。用户不需要直接调用这些工具，只需要用自然语言告诉 Claude"把这个结论告诉另一个会话"，Claude 会自动完成发现和发送。
每个会话都有一个可寻址名称，用 /rename 命令或 --name 参数指定，未命名时自动生成，不影响可达性但不利于识别。输入 /list-agents（别名 /peers）可查看可达会话，包括本机交互会话、子 Agent、Remote Control 和 Web 会话。
接收端的处理方式取决于它当前的状态：如果接收会话正在运行，消息会在两次工具调用之间被读取，不会中断正在执行的操作；如果接收会话处于空闲状态，Claude Code 会以这条消息为起点开始新一轮。
哪些会话可以通信
不是所有会话都能互相发现。这里有一个清晰的边界：
同机：两个会话在同一台机器上，通过本地 inbox socket 通信，不经过 Anthropic 服务器。同机会话支持主动发送新消息和回复。
其他机器 ：v2.1.224 首发时只能回复远端来信。v2.1.225 起，SendMessage 可以按名称主动联系其他机器上的 Remote Control 会话，ListAgents 会显示 name [ref]。
Web：官方文档仍标记为"Replies only"；v2.1.225 changelog 没有宣告 Web 同步放开，因此应和其他机器分开理解。
容器：容器有自己的文件系统，容器内的会话和宿主机上的会话看不到彼此的注册文件，因此不能互相发现。同一容器内的两个会话仍然可以通信。
简单来说，同机完整双向，v2.1.225 起跨机器 Remote Control 可主动联系，Web 仍按文档仅回复，容器继续以文件系统为隔离边界。
什么时候该用
四种适合使用跨会话消息的场景：
- 并行 worktree 协调：一个会话发现 breaking change，直接通知其他会话，避免重复劳动。
- 长程任务状态汇报：后台任务在完成或阻塞时主动发送状态，不需要切回终端手动检查。
- 发现交接：一个会话确认结论后，把摘要交给受影响的其他会话。
- 双向提问：当前会话遇到不确定的问题，直接询问另一个相关会话，获得回复后继续工作。
Cross-session messaging 的定位是"独立会话之间的轻量信息通道"。继续完整对话用 Resume，创建协作会话用 Agent teams，观察多个会话用 Agent view，CI/告警推入用 Channels。
权限与安全边界
消息到达接收端后，会根据 crossSessionInbound 的设置决定命运。官方文档将接收结果分为三类：delivered （消息被正常投递）、held （消息被暂存但不投递）、refused（消息被直接丢弃）。具体行为由接收端配置决定：
- accept：消息被正常投递，接收 Claude 在合适时机读取；
- hold：消息保留但不投递，直到用户批准或后续的 mode/settings 变更允许投递；
- refuse：消息被直接丢弃。
还有一道额外的安全门：isolatePeerMachines 设为 true 后，跨机器消息在离开本机前需要你明确批准。同机会话不受这个设置约束。
最重要的一点：来自其他会话的消息不代表用户授权。它不能批准权限、不能修改配置文件，消息中的斜杠命令只作为普通文本处理。接收会话自己的权限规则仍然生效。
你可以通过拒绝 ListAgents、SendMessage 或设置 crossSessionInbound: refuse 来关闭发现、发送或接收能力。三个入口，三种控制粒度，按需组合。
Harness 工程判断
阿源判断，跨会话消息的意义不只是省掉复制粘贴。它意味着隔离上下文之间开始具备受控的显式通信能力，这对 Coding Agent 的工程架构有几层影响。
隔离上下文 + 显式通信。过去在两个会话之间协作，要么复制整段历史，要么手动总结再粘贴。现在会话之间可以只传递必要事实和决策，减少上下文污染与 Token 浪费。阿源判断，这是从"共享一切"到"按需传递"的协作范式转变。
长任务从轮询变成事件回报。阿源判断，未来长程任务在决策、完成或阻塞时主动发送小型状态事件，后台与前台的协作模式从拉取变成推送。对于运行几十分钟的迁移脚本或测试套件，这个变化的体感会很明显。
多 Agent 不等于共享一个大 Prompt。各会话保留独立任务上下文，只传递必要事实。每个会话有自己的权限边界、工具链和上下文窗口，消息只在需要时才跨越边界。这比共享一个巨大 Prompt 更可控，也更容易审计和调试。
Harness 需要通信基础设施。阿源判断，harness 层需要补齐六项基础设施：地址与发现、邮箱与投递、身份与权限、背压与速率限制、生命周期与恢复、可观测性。前三项已形成基本闭环；背压已有速率限制、重复抑制和每会话 50 条上限，生命周期与可观测性仍有待工程化补齐。
纯文本既是优点也是限制。纯文本简单、可审阅、低耦合，但尚不是带 schema、幂等键、确认机制和追踪上下文的结构化协议。阿源判断，从工程结果看，当前接口保持克制，避免过早引入复杂协议，但也意味着跨会话消息暂时不适合承担关键路径上的精确协调。
跨会话消息是控制面，不是共享记忆。工程推演，会话之间传递的是协调信号------"接口已变更""任务完成""需要你关注"------而不是同步状态。每个会话仍然维护自己的上下文，消息只是触发新一轮推理的输入。开发者在设计多会话工作流时，应当把消息视为控制指令而非数据复制通道。
长任务传递检查点，不传完整结果。阿源判断，长任务应发送"已处理 50%""发现 3 个异常"等摘要并附产物路径；完整结果仍落在仓库、文件系统或外部存储。delivered / held / refused 只表示投递处理，不等于业务完成。
纯文本下可采用约定式字段，但不是内建 schema 。工程推演，在纯文本消息中约定固定字段（如 [CHECKPOINT] 50% [BLOCKED] reason [DONE] summary）是一种务实的做法。但这种约定是应用层的，不是协议层的。阿源判断，"约定优于配置"在早期阶段足够用，但随着工作流复杂度上升，缺乏 schema 会成为调试和维护的痛点。
Harness 待关注项：相关 ID、确认、重试与可观测性。阿源判断，如果要在生产环境中基于跨会话消息构建工作流，以下四项值得 harness 层关注：相关 ID（让多条消息可以串联成一条因果链）、业务完成确认（区分消息投递与任务完成）、重试策略（接收端离线时的暂存与重发）、可观测性（消息流量、延迟、异常的监控与告警）。官方已提供权限门、速率限制、重复抑制、50 条上限和投递结果，但官方资料未描述结构化 correlation ID、业务完成确认和跨会话追踪 schema。对于原型验证这已经够用，对于生产级工作流还需要额外工程投入。
限制与来源
跨会话消息是 Claude Code 从"单会话工具"向"会话网络"迈出的第一步。它克制、明确、有边界------只传文本、不传授权、不传历史、不传文件。当前实现还很早期，每会话 50 条上限是为了防止会话循环无限放大。
官方演示素材来自 ClaudeDevs（2026-08-08），原始发布为视频，本文使用本地降级 GIF。展示两路 Claude Code 会话的跨会话消息协调。本文基于官方发布素材，并非作者实测。
母文链接：《Claude Code 会话终于能互相发消息了：从复制粘贴到会话网络》。
本文首发于公众号阿源聊AI，基于官方发布素材改写。