Claude Code 会话现在能互相发消息了：v2.1.224 跨会话协作完整上手

本文整理改写自 Joe Njenga 的实践分享 "Claude Code Sessions Can Now Talk to Each Other"。保留技术操作骨架，删去了与功能本身无关的素材。

并行跑多个 Claude Code 会话，是当下最快的交付方式之一——一个写 API，一个写调用它的前端。但在此之前，每个会话都是完全隔离的：要么靠人肉复制粘贴上下文，要么依赖终端里各种 hack 凑合，从来没有官方方案。

Claude Code v2.1.224 把这个问题正式解决了：会话之间现在可以直接发消息。下面把整套功能拆给你看，最后在 WSL 里跑一个真实的双会话协作演示。

什么是跨会话消息？

跨会话消息功能只依赖两个新工具，Claude 可以自主调用：

• ListAgents：列出当前所有可达的运行中会话
• SendMessage：按名称向某个会话发送消息

消息内容只能是纯文本，由 Claude 自己写好后发出去。接收方的 Claude 在当前工作过程中或下一轮开始时会读到这条消息。注意：接收方只会拿到这段文本，不会包含发送方的对话历史或项目文件。

你可以手动触发这两个工具，Claude 也会根据自己的判断决定什么时候用。

有四件事这个工具做不到：

• 不能替你批准接收方会话里待审批的权限请求
• 不能修改接收方会话的配置或 CLAUDE.md
• 不能执行 /compact 这类斜杠命令
• 不能跨会话传递对话历史或项目文件

平台要求

跨会话消息需要 Claude Code v2.1.224 或更高版本，目前只支持 macOS、Linux 以及 WSL 2 里的 Linux。原生 Windows（没装 WSL）暂不支持。

先查一下当前版本：

claude --version

低于 v2.1.224 的话先升级：

claude update

升到正确版本之后，跨会话消息功能默认就开启了——Claude Code 会在每个会话启动时自动绑定消息收件箱的 socket，什么都不需要手动启用。

在 WSL 里开两个会话

这次演示在 Windows Terminal 里用分屏功能同时跑两个会话，每个会话对应不同的项目目录，这正是跨会话消息发挥价值的典型场景。

把 Windows Terminal 的 WSL 界面分成两个垂直窗格：

Alt + Shift + Plus

现在你有两个独立的终端窗格，都运行在同一个 WSL 环境里。

左侧窗格：进入第一个项目目录，启动第一个会话并起一个可读的名称：

cd ~/projects/my-api
claude --name api-session

右侧窗格：进入第二个项目目录，启动第二个会话：

cd ~/projects/my-frontend
claude --name frontend-session

--name 参数很关键——它给会话一个可读的标签，而不是自动生成的 myapp-3f 这种随机串。Claude 发消息时是按会话名称寻址的，名字清晰才能一眼看出哪条消息是谁发来的。

如果会话已经启动了，也可以在会话内用 /rename 重命名：

/rename api-session

确认两个会话可以互相发现

在任意一个会话里运行 /list-agents，确认两个会话互相可见：

/list-agents

你应该能看到另一个正在运行的会话，包括它的名称和工作目录：

如果某个会话没出现在列表里，最常见的原因有三个：

• 会话是用 -p 参数以非交互模式启动的——这种情况下不会绑定收件箱 socket
• 你的 shell 里设置了 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY 或 DO_NOT_TRACK 环境变量，这会禁用该功能依赖的特性开关
• 版本还低于 v2.1.224

也可以在任意会话里运行 /status 看自己的对端地址：

/status

关注输出里的 Peer address 行，旁边有 uds: 路径就说明会话已注册，可以正常接收消息。两个会话都出现在列表里之后，配置就完成了。

实战演示：API + 前端协调一次破坏性变更

两个会话都跑起来了，互相也能看到对方。现在让它们真正干活，触发第一条跨会话消息。

演示场景：

• api-session：在开发一个 Node.js Express API，正在做数据库 schema 迁移——把整个代码库里的 user_email 列名改成 email_address
• frontend-session：在构建一个 React 仪表盘，调用同一个 API 并读取每条用户响应里的 user_email 字段

这两个会话完全不知道对方在做什么——而这正是我们要解决的问题。

第一步：给每个会话下达任务

在左侧窗格（api-session）里输入：

We are migrating the user schema. Rename the user_email column to email_address
in the User model, update all database queries that reference it, and update
the API response serializer. This is a breaking change for any consumers
of this API.

在右侧窗格（frontend-session）里输入：

Build a UserDashboard component that fetches all users from GET /api/users
and displays their user_email field in a data table with sorting and pagination.

让两个会话各自开始工作。

第二步：消息发出去了

api-session 在做迁移的过程中识别到这是一个破坏性变更，Claude 会主动向 frontend-session 发出警告。

如果没有自动发送，在 api-session 里用下面这个提示词手动触发：

观察左侧窗格里发生了什么：Claude 先调用 ListAgents 找到 frontend-session，然后写一条总结列名变更的消息，用 SendMessage 发出去。两个会话就这样一直互相协作，直到任务完成。

四个值得记住的使用场景

演示展示的是最基础的用法，但跨会话消息能解锁的场景远不止于此。

1. 传递重要发现

当某个会话发现了对另一个会话很重要的信息（比如依赖冲突），你可以让 Claude 把它传过去。

Tell the api-session what you just found about the rate limiting behavior
and how it affects any session that calls the payment endpoint

Claude 会写一段精准的总结并发出去。

2. 协调并行 Worktree

用 git worktree 在同一个仓库里跑多个 Claude Code 会话时，每个会话在自己的工作目录里操作独立的分支——它们同时推进，但对彼此在做什么完全不知情。

git worktree add ~/projects/my-app-feature feature/payments
git worktree add ~/projects/my-app-refactor refactor/user-model
 
# 左侧窗格
cd ~/projects/my-app-feature
claude --name payments-session
# 右侧窗格
cd ~/projects/my-app-refactor
claude --name refactor-session

refactor-session 改完 User model 后，这样告诉它：

Message the payments-session and tell it what changed in the User model
so it can update its payment flow accordingly before running

payments 会话会收到 refactor 分支上变更的精准摘要，然后更新自己这边的代码。

3. 查询长任务的执行状态

在某个会话里启动了一个重任务（比如完整的数据库迁移），可以切回另一个会话继续干别的活。

启动时告诉长任务做完汇报一声：

Run the full database migration and when it finishes, message the
api-session with the result. Include whether it succeeded, how many
records were affected, and any warnings that came up

迁移完成后，那个会话会向 api-session 发一条简洁的状态消息。

4. 跨机器回复

当你在两台不同的机器上都运行了 Claude Code 并连接了 Remote Control，机器 B 上的会话可以发消息到机器 A。

关键限制：跨机器消息从接收方来看只能回复，不能主动发起——机器 A 可以回复收到的消息，但不能主动向机器 B 发起一段新的对话。

实际使用场景：用工作笔记本查一下家里电脑上跑着的任务进展：

Reply to the migration session on my other machine and ask it for
a current status update on where the job stands

还有一个值得记住的细节：同一台机器上的消息走的是本地 Unix socket，不会经过 Anthropic 的服务器。

控制选项、限制与可用范围

基于这个功能构建正式工作流之前，有几个开关和硬限制需要提前了解清楚。

入站设置：accept / hold / refuse

每个会话可以通过 crossSessionInbound 设置来控制如何处理收到的消息，有三个选项：

在项目或用户配置文件里加上这一行来设置：

{
  "crossSessionInbound": "hold"
}

没有配置的情况下，默认行为取决于你的权限模式——跳过权限提示的会话会把消息暂存等待你批准，正常弹出权限提示的会话会直接投递。

要求批准跨机器消息

如果想把所有会话协调限制在本机，要求任何跨机器的消息在发出前都必须得到你的明确批准，把 isolatePeerMachines 设为 true：

{
  "isolatePeerMachines": true
}

开启后，即使在跳过其他所有权限提示的会话里，发往其他机器的消息也需要你明确批准才会发出。

完全关闭这个功能

要阻止某个会话接收消息，把 crossSessionInbound 设为 refuse。要阻止某个会话发送消息或发现其他代理，给两个工具都加上拒绝规则：

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

限制条件

可用范围

并非所有服务商都支持跨会话消息。通过以下任意渠道使用 Claude Code 时，该功能不可用：

• Amazon Bedrock
• AWS 上的 Claude Platform
• Google Cloud 的 Agent Platform
• Microsoft Foundry

原生 Windows（没有 WSL）同样不支持。

小结

跨会话消息把 Claude Code 从"一个隔离的终端工具"推进了一步。结合子代理、worktree 这些已有的能力，它正在变成一个有协调能力的智能体系统。

几个值得记住的要点：

• 用 --name 或 /rename 给会话起个有意义的名字，Claude 发消息时才能准确寻址
• 发消息之前先跑 /list-agents 确认双方互相可见
• Claude 自主使用两个工具处理协调：ListAgents 发现其他会话，SendMessage 投递消息
• 消息只能是纯文本，不能传文件、对话历史，也不能批准待审批的权限
• 同机器消息走本地 socket，不经过 Anthropic 服务器；跨机器消息会经过 Anthropic 服务器
• 如果 /list-agents 没有返回任何内容，检查 shell 里是否设置了 DO_NOT_TRACK、DISABLE_TELEMETRY 或 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

参考资料

• Claude Code 子代理文档
• Claude Code Remote Control 文档
• git worktree 官方文档