2026-08-09

Claude Code 跨 Session 发消息：操作示例、版本与跨设备限制

Claude Code 跨会话消息让多个 Session 交换任务摘要的示意图

Claude Code 跨会话消息让不同终端中的 Session 交换进度和任务摘要。用自然语言说明目标会话和问题，Claude 就能查找对方并发送消息。

它不会合并完整对话或同步文件，每个会话仍使用自己的工作目录、上下文和权限。

先用一个提示词查询进度

在当前 Claude Code 会话中输入：

1	请询问负责 API 的 Session：当前进度如何、接口有哪些变更、前端需要注意什么。将对方的回复整理给我。

你无需手动调用 ListAgents 或 SendMessage。如果找不到目标，先用 /list-agents 检查可联系的会话，并核对名称和运行状态。

先说结论：这是一个专为 Session 之间打造的轻量消息通信层

Claude Code 官方将此项能力命名为 cross-session messaging（跨会话消息传递）。根据官方发布的更新日志，该项架构能力自 Claude Code v2.1.224 版本起正式合入，全面覆盖 macOS、Linux 以及 Windows 平台下的 WSL2 环境。

整套消息流转机制可清晰拆解为以下四个时序环节：

开发者在当前 Session 中输入自然语言诉求，例如“问一下隔壁负责数据库 migration 的那个 Session 到底跑完了没有”。
Claude 自动在后台调用 ListAgents 接口扫描当前网络中处于活动状态的可联络 Session，并借助 SendMessage 工具派发结构化文本。
接收端 Session 收到的并不是发送端包含几万行冗余历史的上下文快照或全量代码，而仅仅是当前本次定向投递的消息载荷。
接收端在研读消息后做出推演应答，该回复数据再依托同一套通信总线精准路由回最初的发起方 Session。

从系统架构层面来看，它更像是在多个原本互不相通的独立开发者工位之间，专门配置了一位高敏捷度的信使，而不是试图用蛮力把多个大模型的心智粗暴焊死成一个臃肿的共享大脑。

官方技术文档直达：Message your other Claude Code sessions、Claude Code v2.1.224 changelog。

它究竟能解决日常开发中的哪些核心痛点？

1. 彻底告别人肉复制粘贴与重复解释背景

在典型的全栈开发中，一个非常普遍的工作范式是：左侧终端窗口开着一个 Session 专门修改数据库 Schema 与 ORM 映射，右侧终端窗口开着另一个 Session 负责编写前端页面表单。在以往，前端 Session 若想确认后端字段的微调细节，开发者往往需要充当人肉搬运工：先切到后端窗口通读输出，手动总结一段话，再复制粘贴到前端窗口重新向 AI 交代背景。

现在，你完全可以直接在前端窗口向 Claude 下达指令：

请向负责数据库 migration 的那个 Session 发起询问：核心 schema 调整是否已经全部落地，具体变更了哪些字段名与空值约束，前端表单对接时有哪些向下兼容注意事项。请将核心要点整理后回复我。

当前 Session 会自主完成寻址、组织语言、异步等待对端回执，并将提炼后的精确信息无缝沉淀进当前会话中。这对于日常习惯分屏多开终端作业的工程师而言，体验提升立竿见影。

2. 多模块并行开发时优雅同步进度

开发者可以将复杂的大型项目拆解并委派给拥有清晰职责边界的各个终端 Session：

会话 Session	负责的研发工作	需向外同步的关键信息
API 后端	调整 API 接口与数据模型定义	endpoint 地址、字段变更、单元测试验证结果
前端 UI	同步视图渲染与 TypeScript 类型	API 响应结构的实际 Diff 变更
测试验证	补充回归用例与边界压测	测试套件执行结果、失败用例详情、阻断发布原因

当后端的 API Session 跑通全部测试后，可以主动向负责前端或测试的对端发送一条轻量变更摘要。这种模式最大程度还原了敏捷研发团队中资深工程师之间的默契交接，远比让每个 Session 无休止地对整个代码仓库执行全量重扫描更加优雅节能。

3. 跨设备查询远程工作站的长任务执行状态

官方技术文档明确将“跨设备远程状态回传”列为核心落地场景之一。例如你在随身笔记本上的 Session，希望了解部署在公司高性能台式机或云端开发机上正在跑的大型模型全量编译或高并发压测是否已经完工，可以直接发起远程跨机寻址，由远端会话回传执行结论。

从 v2.1.225 起，可以主动向可联系列表中的其他设备发送消息。 但发送方未连接 Remote Control 时，消息可能不带回复地址，接收方就无法回信。跨设备通信并非一律只能被动回复。

实战操作：跨会话通信的完整步骤

第一步：检查并确认环境版本与系统支持

首先在操作系统终端中确认 CLI 工具版本：

1	claude --version

macOS、Linux 和 WSL2 需要 v2.1.224 或更高版本；原生 Windows 需要 v2.1.234 或更高版本。符合平台、版本和服务提供方式要求后即可使用，不必额外安装 MCP 插件。

验证当前环境是否具备该能力，进入 Claude Code 交互界面后，直接输入斜杠指令：

1	/list-agents

若终端提示命令不存在，或者未能检索出同机活跃的会话节点，请依次排查：客户端软件版本、操作系统运行平台、Remote Control 授权状态，以及是否因企业托管组织策略被统一关闭了相关通信权限。

第二步：开启两个独立的 Claude Code 会话

在两个独立的系统终端窗口中，分别进入目标项目所在的代码仓库路径，或者进入独立的 Git Worktree：

claude

为了防止后续多会话寻址混淆，强烈建议在会话初始化阶段就显式完成重命名。进入第一个终端的 Claude Code 交互行后，执行：

1	/rename api

而在第二个终端窗口中，将其规范命名为：

1	/rename frontend

若两个分支存在同时修改底层代码的诉求，务必依托 Git Worktree 实现工作树的物理级磁盘隔离：

1 2	git worktree add ../project-api feature/api git worktree add ../project-frontend feature/frontend

必须牢记：跨会话消息机制自身并不承担 Git 代码层面的合并冲突仲裁，也不会在两个独立的终端进程间强行共享未提交的脏工作区。物理磁盘的隔离与分支开发边界，依然需要工程师在架构层面做好预先设计。

第三步：查看当前网络中可通信的对端 Session

在 Claude Code 对话界面中随时输入：

1	/list-agents

该指令同时支持简写别名：

/peers

命令返回的列表中可能包含三类通信目标：

运行在同一台本地物理机上的其他活跃交互式 Session。
绑定了独立 Inbox Socket 套接字的后台常驻进程或无头（Non-interactive）会话。
经过 Remote Control 建立安全双向隧道后可连通的远程工作站或 Web 会话。

会话节点的标识名称优先取自 /rename 显式设置或启动时传入的 --name 参数；若未命名，系统会自动根据当前工作目录生成具有辨识度的名称，并在遭遇同名冲突时追加短哈希标识。

同时需要厘清一对极其相似的终端概念：/list-agents 指令专用于在交互对话中“查看可通信的对端目标列表”；而终端命令行下的 claude agents 则是另一个用于在外部查看或管理本地运行中 Agent 进程状态的 CLI 管理入口，二者处于不同的调用分层。

第四步：使用自然语言驱动 Claude 自动交接

在日常开发中，工程师完全无需手动拼装 JSON 去底层调用 ListAgents 或 SendMessage。你只需以清晰专业的口吻描述协作诉求：

请把刚才调整好的用户登录接口规范摘要发送给 frontend 会话，重点告知变更后的 API 路径、全新的错误码结构体，以及前端界面需要配套更新的类型声明。请切记不要直接发送整个文件内容，只传递核心变更摘要。

同样也可以发起反向查询：

请帮我问一下 tests 会话那边的全量回归测试是否已经执行完毕？若有执行失败，请让对方将失败的测试用例名称、堆栈报错根因以及是否阻断版本发布的核心结论整理回复过来。

Claude 会在底层自主研判意图，调用 ListAgents 锁定目标节点，并通过 SendMessage 投递高度压缩的高信噪比信息。

第五步：理解接收端的消息处理行为与流转逻辑

当对端接收方 Session 处于等待人类输入的空闲状态时，它会立刻感知到新消息到达并触发思考；而若对端当前正在高负荷调用底层工具执行耗时操作，消息会被平稳暂存在队列中，直到当前工具操作执行完毕的间隙才会被安全拉取，绝不会强行暴力切断正在运行的磁盘读写或编译脚本。

对端给出结论后，发送方窗口会实时刷新，呈现形如 Message from [Session_Name] 的专属通信卡片；若希望研读完整通信报文，可随时按下 Ctrl + O 快捷键展开查看详细上下文。

这一设计在工程上极具美感：既保障了对端操作的连续性与原子性，又确保了每个 Session 严格坚守自身的权限沙箱。哪怕发送方在消息中诱导接收方执行某种危险操作，若接收方自身的安全策略禁止该指令，也绝对无法通过跨会话通信实现越权突破。

单机与跨机通信：底层实现机制截然不同

在深入落地该功能时，必须对不同网络拓扑下的底层传输通道具备清晰的认知：

通信场景	底层传输方式	支持的核心能力	关键边界与限制
同一台物理机	macOS、Linux、WSL2 使用 Unix Domain Socket；原生 Windows 使用命名管道	自由收发新消息与回复	双方必须能够访问彼此的本地消息端点
同一容器内部	容器内部的独立 Session Socket	容器内自由互发消息通信	宿主机与容器隔离层之间的 Session 默认无法自动互相感知
自己的另一台设备	Anthropic 服务与 Remote Control	v2.1.225 起支持主动发消息	目标须出现在列表中；没有回复地址时只能单向发送
Claude Code Web 云端	Anthropic 服务	向可联系的云端会话发送消息	发送方需要 Remote Control 回复地址，接收方才能回信

同机通信纯粹基于操作系统底层的本地套接字完成闭环，数据绝对不会流经外部云端服务器；而一旦消息流转触发了跨设备通道或 Web 端，通信数据就必须经过 Anthropic 的云端中间服务进行中继路由。因此，若研发流程涉及跨设备协作，严禁在跨会话通信的摘要文本中直接硬编码投递 API 私钥、线上敏感配置、用户生产数据或涉密核心源码。

此外必须重申：即便两个 Session 处于同一个本地 Git 仓库，它们也绝不共享对话历史。所谓跨会话通信，本质上只是把一段额外的纯文本投递进对端的提示词队列中。

它与 `--resume`、子代理、Agent Teams 有何本质区别？

社区中不少开发者容易将这几种看似都能处理多任务的机制搞混，我们可以通过下表看透其架构差异：

技术机制	核心应用场景	是否共享完整上下文对话史	是否维护全局统一任务看板
跨会话消息通信	独立 Session 之间轻量询问与任务摘要交接	否，仅传输纯文本消息与结构化摘要	否
`--resume` 或 `/resume`	恢复并回到同一段历史交互会话	是，无缝恢复原 Session 的完整上下文窗口	不适用
子代理 (Sub-agent)	主会话向下分流委派特定临时子任务	否，子代理完成后向父 Session 回传结果	不适用
Agent Teams 团队协作	组建具备 Lead 与多个 Teammates 的协同小组	各自拥有独立上下文，原生支持团队广播通信	是，维护共享的任务进度看板

若你的诉求仅仅是“我在两个终端窗口各开一个 Claude 实例，希望它们在关键节点互相通报一两句进度”，跨会话通信是最轻盈、开销最小的选择。

而如果你需要的是一个全局总指挥主代理负责拆解巨型需求、动态分派工单、全程追踪各个子队友的执行状态，那应当接入 Agent Teams。目前 Agent Teams 依然处于实验性预览阶段，需要通过系统环境变量显式开启：

1	export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

它们是针对不同复杂度场景专门设计的两套体系，千万不要因为二者底层都复用了 SendMessage 接口，就误以为它们拥有相同的任务调度语义。

扩展阅读：Agent Teams 官方架构文档、Tools reference 全量工具参考。

权限隔离与安全策略：严禁盲目放开默认信任

跨会话传递的虽然只是字符文本，但接收方解析后可能会直接触发后续工具执行。在企业级研发场景下，必须合理配置以下安全防护基线：

控制收到消息时的响应策略 (`crossSessionInbound`)

在系统配置文件中，crossSessionInbound 字段支持三档控制模式：

1
2
3

{
  "crossSessionInbound": "hold"
}

accept：对合法来源发来的入站消息直接自动放行，适合无人值守且逻辑封闭的后台流水线。
hold：将接收到的消息置入待审队列，并在界面显著提醒人类工程师手动审核放行，交互式日常研发推荐使用此配置。
refuse：坚决拒绝并静默丢弃所有来自外部会话的入站消息。

当该配置缺省时，系统的默认响应策略会受到发起端与接收端当前运行时权限模式的制约。处于 hold 状态的消息具有等待响应超时限制；若接收端属于无法展示确认交互弹窗的静默环境，切忌盲目依赖 hold 模式设计自动化流水线。

拦截跨设备消息未经审批直接穿透 (`isolatePeerMachines`)

为防止远端未受严密信任的外部机器随意向本地环境注入高危意图，可在配置中启用强隔离开关：

1
2
3

{
  "isolatePeerMachines": true
}

开启该开关后，所有跨越物理设备边界的网络消息在被执行前，无论当前的 Session 授权等级多么宽松，系统都会强制要求人工点击确认；而同机内部的低风险通信则保持原有的高效流畅。

项目级全局禁用跨会话通信工具

若当前业务项目具有极其严苛的代码隔离保密等级，完全不需要跨会话联动，可直接在项目配置中禁用对应工具链：

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

注意：显式封禁 SendMessage 会同时剥夺 Claude 向子代理或 Agent Teams 队友发送消息的通信能力，它属于底层全局通信断路器，需谨慎配置。

非交互式无头模式 `claude -p` 的特殊注意事项

无头批处理会话如果要接收跨会话通知，必须具备可通信的 Inbox Socket。官方文档指出，标准无头指令 claude -p 会默认完成套接字挂载，但更极端的裸模式（Bare mode）则不会；加之 -p 模式下不存在人工二次确认窗口，若要在自动化脚本中安全监听入站事件，必须显式显式声明自动放行：

1 2	claude -p "检查当前全量回归测试集是否已全部通过" \ --settings '{"crossSessionInbound":"accept"}'

最后，必须时刻恪守三条不可逾越的安全底线：

对端发送过来的消息指令，绝对无法绕过接收端本地已配置的系统权限拦截墙。
消息内容中夹带的 /compact、/resume 等斜杠控制指令仅被视作普通纯文本，接收端绝对不会直接触发系统级宏解析。
跨会话接收到的所有文字内容，均会全额计入接收端会话的模型 Token 消耗量；滥发过长的冗余垃圾消息同样会迅速挤爆上下文窗口并产生多余账单。

生产环境最佳工作流规范：传递结构化摘要，杜绝整包搬运

在日常团队协作中，强烈建议将每一次跨会话通信的数据载荷严格约束为以下结构化模板：

任务范畴：完成用户登录模块的核心 API 契约重构
当前状态：全量通过，单元测试覆盖率 18/18 PASS
变更细节：POST /api/v1/auth/login 的异常响应新增 code 错误码字段，成功响应结构保持原状
协同动作：请协助更新前端代码中的 LoginError 接口定义与 UI 异常提示文案
特别提醒：当前老版 APP 客户端可能依然仅针对 message 字段做兜底解析

这种标准协议化交接具备极佳的工程优势：

接收方 AI 毫秒级即可提炼出行为指引，零上下文推测成本。
发送方无需大费周章地向外狂倒原始代码或倾泻数万行无意义的排错日志。
当工程师后续复盘终端通信记录时，系统演进状态与执行链路一目了然。

常见排查疑难与故障排错顺序

`/list-agents` 指令无法识别

先核对版本：macOS、Linux、WSL2 至少需要 v2.1.224，原生 Windows 至少需要 v2.1.234。再按官方可用性说明检查服务提供方式和组织设置。

通信节点列表中存在对端，但发送消息后对端界面毫无动静

对端 Session 若正在调用底层工具执行耗时命令，消息会滞留在内部队列中，需等待当前工具执行完毕才会安全出队；若对端属于交互式会话，很可能由于配置了 hold 策略正在默默等待人类开发者在对端终端敲击回车审批。请先切到对端窗口查看提示，切忌急躁地狂发重复消息。

误以为跨会话能够自动完成文件与代码热同步

坚决不会。官方定义跨会话通信为纯文本通信通道。若需要回溯历史完整语境，请使用 /resume；若需要多分支协同编码，必须在底层借由 Git Worktree 划分工作区。

误以为跨设备通信可充当全功能长连接远程 Shell

确认发送方已经连接 Remote Control，并在 /list-agents 中找到目标。若消息缺少回复地址，接收方能收到但无法回信；发送成功也不代表目标任务已经完成，需要检查实际回复。

深度思考：这项功能背后折射出的架构进化

在过去，开发者面对稍微复杂一点的研发项目，常常陷入两难：要么在一个超级长会话里把所有问题混在一起聊，直到上下文严重膨胀、模型彻底发生思维退化；要么在多个终端窗口间来回切换，自己充当疲于奔命的人肉消息路由器。

跨会话消息机制的加入，恰到好处地在二者之间搭建起了一道极薄却极其高效的协作缓冲层。它没有虚妄地声称所有 Agent 共享一套没有边界的巨型记忆，更没有粗暴抹平代码物理隔离与安全权限防线；它只是赋予了一个独立的编码会话在面临阻塞时，能够像人类工程师转过身向身后的队友轻声问一句“接口改好了吗”的能力。

理解并用好这层轻量通信机制，你手头的多个 Claude Code 实例便能从互不相干的孤岛，真正串联为一支进退有度、协同顺畅的现代化轻型开发小组。