小編精選 - 技術文章翻譯 · 08月24日

Claude Code 的會話間通訊，Windows 也能運作了（自 v2.1.234 起）

Claude Code 具有一項名為 cross-session messaging 的功能，可以向自己的其他 session 傳送訊息。當你開兩個終端機並行工作時，這個功能可以把一邊的變更傳給另一邊。

這件事，大概很多人都以為「Windows 不能用」。我自己也是這麼以為。稍早之前的官方文件還是這樣寫的：

Claude Code doesn't offer cross-session messaging on native Windows.
（原生 Windows 不提供 session 間訊息傳遞）

出自 8 月 15 日時點的快照（Wayback Machine）。

這已經是過去式了。 v2.1.234 已加入 Windows 支援，我這邊也實際跑通了。下面整理實測結果，以及目前仍有出入的資訊。

一次資訊
官方文件: https://code.claude.com/docs/en/cross-session-messaging
CHANGELOG: https://code.claude.com/docs/en/changelog

驗證環境：Windows 10 Home（原生，不是 WSL）+ Claude Code v2.1.241

有什麼變動

8/15 的文件寫著「原生 Windows 不提供」
8/17 的 CHANGELOG（v2.1.234）
加入了 Windows 支援（原文如下）
目前的文件則寫著「原生 Windows 需要 v2.1.234 以上」

Windows: cross-session messaging is now available, so Claude Code sessions across your machines can message each other with SendMessage and find each other with ListAgents, as on macOS and Linux

實測 1：看得到其他 session

在開了多個 session 的狀態下，讓其中一個列出其他 session，回傳如下：

Peer sessions (4):
  work-7a [12505d]  ·  interactive  ·  started 49m ago
  work-37 [72b59d]  ·  interactive  ·  started 34m ago
  work-a0 [7390f5]  ·  interactive  ·  started 49m ago
  work-f0 [f8a592]  ·  interactive  ·  started 7m ago

實測 2：送出、再收到回覆

我送了一段文字給 work-f0。當我請它「把這段話傳給 work-f0」時，Claude 會透過 SendMessage 傳送。

{"success": true,
 "message": "“動作確認測試” → work-f0 (another Claude session on this machine)"}

我先請接收端「只回傳一行受信成功」，結果真的收到了。

<cross-session-message from="uds:\\.\pipe\cc-msg-dc2c…" from-name="work-f0">
受信OK
</cross-session-message>

送出端位址以 uds: 開頭，後面接的是 \\.\pipe\。這就是 Windows 的 named pipe（具名管道），也直接反映出實作方式的差異。

實測 3：「等我閒下來再通知我」也會收到

我也測了 v2.1.236 新增的 notify_when_idle。這是一種在另一個 session 下次變成 idle 時，只通知一次的機制。訂閱後，work-f0 一忙完就收到了通知。

[Cross-session idle notice] "work-f0" is idle now —
it finished a turn at 08:55.

只有這裡資訊不一致

這個 notify_when_idle，CHANGELOG 的描述至今仍然寫著「(macOS and Linux)」。

Added notify_when_idle to cross-session SendMessage ... opt-in, one-shot, no polling (macOS and Linux)

但目前官方文件的對應章節沒有 OS 限制，條件只有「兩邊的 session 都必須是 v2.1.236 以上」。而且如上所述，在 Windows 上確實有收到通知。

如果只看 CHANGELOG 就放棄，會錯過一個其實能用的功能。這次的教訓是：版本說明和正式文件都要一起看。

Windows 實作不是 Unix socket，而是 named pipe

同一台機器內的傳遞不會經過 Anthropic 的伺服器。路徑會依作業系統而不同。

OS 傳遞路徑
macOS / Linux（包含 WSL 2）Unix domain socket
原生 Windowsnamed pipe
安全機制也不同。macOS / Linux 是以 OS 使用者層級做存取限制；Windows 則是每次連線都必須先送出認證 token，沒有 token 的連線會在第一行就被切斷。

容易出包的點：WSL 2 和原生環境不能混用

這裡很容易踩雷。

A session inside WSL 2 and a native Windows session on the same computer can't reach each other, because they register under different home directories and listen on different socket types.
（同一台電腦上，WSL 2 內的 session 和原生 Windows 的 session 無法互相連線，因為它們註冊在不同的 home 目錄下，且監聽的是不同類型的 socket。）

因為 Windows 尚未支援時的替代方案是「改用 WSL 2」，所以現在常會出現把逃到 WSL 2 的 session 和原生 Windows 的新 session 放在同一台機器上的情況。它們彼此看不到，所以必須統一到同一邊。

其他條件如下：

兩邊的 session 都必須是 v2.1.234 以上（notify_when_idle 則是 v2.1.236 以上）
經由 Amazon Bedrock 或 Microsoft Foundry 等部分提供者時無法使用
如果把 DISABLE_TELEMETRY 或 DO_NOT_TRACK 設成停用 feature flag 評估，功能也會失效
只能傳一則文字，不會傳遞對話紀錄或檔案

總結

cross-session messaging 在原生 Windows 可用（v2.1.234 以上）。列舉、傳送、回覆、idle 通知都已在 v2.1.241 驗證
notify_when_idle 的 CHANGELOG 目前仍寫著「(macOS and Linux)」，但文件沒有 OS 限制，且在 Windows 上可用
Windows 不是用 Unix socket，而是用 named pipe + token 驗證的另一套實作
WSL 2 的 session 與原生 Windows 的 session，即使在同一台電腦上也看不到彼此