v2.1.224 引入的跨会话消息能力，让运行在不同机器上的 Claude Code 会话第一次具备了互相通信的能力。这项功能目前还比较新，官方文档细节有限，但结合 Changelog 描述和相关配置项，本文尝试梳理一份实战导向的使用思路，帮你理解这项能力能解决什么问题、该如何谨慎使用。
这项能力解决什么问题
在跨会话消息出现之前，如果你在笔记本上开了一个 Claude Code 会话在处理任务 A，同时台式机上另一个会话在处理任务 B，这两个会话之间是完全隔离、互不知情的——即便两个任务其实有关联（比如任务 A 依赖任务 B 的产出），你也只能自己在两个会话间手动传递信息。
跨会话消息改变了这一点：
场景示例：
笔记本会话（任务A：重构后端接口）
完成后主动 SendMessage 给
台式机会话（任务B：正在写前端联调代码）
通知「接口已改完，字段名从 userId 改成了 user_id」
核心命令：ListAgents 与 SendMessage
发现当前可通信的会话
ListAgents
向指定会话发送消息
SendMessage
官方 Changelog 目前只给出了这两个能力的命名，尚未看到详细的命令行用法文档，实际使用时建议以 claude --help 或官方文档更新为准。这里从概念层面梳理典型工作流：
1. 在设备A上启动一个长期任务的会话（比如跑一个大型重构）
2. 在设备B上启动另一个相关任务的会话
3. 用 ListAgents 确认设备A的会话在线且可被发现
4. 当设备A的任务出现关键节点变化（完成/出错/需要协作输入）时，
通过 SendMessage 主动通知设备B的会话
5. 设备B的会话根据收到的消息，调整自己的下一步行为
必须理解的安全边界：crossSessionInbound
crossSessionInbound 设置项：
发往「以 bypassPermissions 模式运行」的会话的跨会话消息，
会被暂存，等待你手动批准；
发往「正常权限模式」会话的消息，则会自动送达
这个设计逻辑值得认真理解——权限越高的会话，对外部消息的戒备也越高。如果你有一个会话开启了 bypassPermissions（意味着它可以不经确认执行操作），那么任何发给它的跨会话消息都不会立即生效，而是会像一个「待批准的操作请求」一样先摆在你面前——这是为了防止「某个会话被恶意或误操作诱导发送指令，进而操纵一个权限已经放开的高风险会话」这类攻击链条。
配套的 dialogExpiry 设置项控制这类待批准消息多久后过期——建议按照你的实际工作节奏设置一个合理值，太短可能来不及处理，太长则可能让一堆过期但仍待处理的消息堆积起来。
一个容易被忽视的可靠性细节
v2.1.224 修复：SendMessage 此前在写入失败时依然显示 "Message sent"
v2.1.222 修复：SendMessage 因摘要过长直接失败，现改为自动截断
这两个修复提醒我们，跨会话消息目前还是一项较新的能力，使用时建议：
1. 不要把跨会话消息当作 100% 可靠的通信通道来设计关键工作流
2. 对于真正重要的协作节点，配合日志或其他确认机制做二次核实
3. 升级到 v2.1.224 及以上版本，确保发送失败时能得到准确反馈
与自托管运行环境的组合潜力
跨会话消息和同版本发布的自托管运行环境（claude self-hosted-runner）结合起来看，能拼出一个更完整的画面——企业可以把不同职责的 Agent 会话分布在不同的自托管节点上（比如一个节点专门跑数据处理任务、另一个节点专门跑面向生产环境的部署任务），再通过跨会话消息让它们按需协调，初步具备了「多 Agent 分布式协作」的雏形。当然，目前这项能力刚刚发布，仅支持 macOS 和 Linux，具体的稳定性和最佳实践还需要更多实际使用反馈来验证。
总结
跨会话消息是 Claude Code 从「单机命令行工具」向「跨设备协作网络」演进的一个重要信号，但作为一项刚发布的新能力，建议先在非关键任务上尝试熟悉其行为边界（尤其是crossSessionInbound 的批准机制），再逐步纳入日常的多设备工作流。
来源：Claude Code Changelog v2.1.222/v2.1.224 — Claude Code 官方文档，Anthropic