Anthropic 推出 Claude Code 的 Cross-session messaging 實驗功能，允許不同 Session 直接互相發送訊息。該功能不傳遞完整 Context，僅傳遞任務結果和依賴資訊，透過 ListAgents 和 SendMessage 兩個內部工具實現。每個本地 Session 註冊到磁碟並綁定 Inbox Socket，本機訊息直接透過 Socket 傳遞，跨機器訊息則經由 Anthropic Server 傳輸。訊息在 Session Idle 時觸發新 Turn，在 Active Turn 中則等待 Tool Call 之間被讀取。接收端會將跨 Session 訊息與 User Message 區分開來，不能替代使用者授權，並設置了 accept/hold/refuse 三種 Inbound Control 模式。該功能與 Resume Session、Agent Teams、Worktree 等現有能力配合，為 Claude Code 提供了 Session 間的協調層。

文章作者、來源：雷峰網

這幾天，Anthropic 為 Claude Code 新增了一項實驗性功能：Cross-session messaging，即跨 Session 消息通信。

簡單來說，它讓你能夠同時運行的多個 Claude Code Session 直接互相發送訊息。

例如，你開啟了 3 個 Claude Code Session：一個負責資料庫，一個負責後端 API，一個負責測試。以前這 3 個 Session 雖然可以並行工作，但彼此不知道對方做到哪裡了。資料庫 Session 改完 Schema，通常還是要開發者自己切到另一個終端，把變動重新告訴後端 Session。

在加入跨會話訊息功能後，這一步可直接由 Claude 完成。資料庫 Session 可通知後端 Session 哪些欄位發生了變化，測試 Session 發現介面回歸問題時，也可將結果發送給正在修改相關代碼的 Session。Claude 可自行判斷何時需要通知其他 Session，也可根據開發者的要求聯繫指定 Session。

要理解它具體做了什麼，可以順著一條訊息的完整路徑往下看：它傳什麼、怎麼找到目標、訊息什麼時候進入 Claude，以及接收方為什麼不能直接照做。

01

Cross-session messaging 沒有改變 Claude Code 原本的 Session 隔離。

當 Session A 向 Session B 發送訊息時，不會一併傳送自己的對話歷史、已閱讀的文件或整個上下文窗口。官方規定，跨 Session 傳遞的僅為文本。如需將完整對話與上下文遷移至另一終端，應恢復原來的 Session，而非使用跨 Session 訊息功能。

這決定了多個 Claude 之間的協作方式。

假設資料庫 Session 為了完成 Migration，讀取了數十個檔案，並嘗試了幾套方案，最終確定某個欄位需要修改。後端 Session 無需知曉前面的全部分析過程，只需取得最終的變更，以及這些變更將如何影響其 API。

因此，Cross-session messaging 傳遞的是任務結果和依賴資訊，而不是完整工作記憶。

這樣做的好處是，不同任務產生的局部資訊不會不斷湧入其他 Session。資料庫相關的細節可以留在資料庫 Session，測試過程可以留在測試 Session，只有當某個變化開始影響其他任務時，相關資訊才跨過 Session 邊界。

它與「所有 Agent 共享一個大 Context」屬於兩種不同思路。Cross-session messaging 選擇讓 Session 保持獨立，再在任務產生依賴時顯式同步必要狀態。

既然傳遞的是一條明確的消息，接下來的問題就是：Session A 怎麼找到 Session B？

02 要先找到另一個 Session

Claude Code 為支援跨會話訊息的會話增加了自己的通信入口。

每個本地 Session 會把相關資訊註冊到磁碟，同時綁定一個 Inbox Socket。Claude 可以通過 ListAgents 查找當前能夠聯繫的 Session，再通過 SendMessage 把訊息發給指定目標。

用戶無需自行操作這些內部工具，只需告訴 Claude 想聯繫哪個 Session，或讓它在任務產生依賴時主動通知對方。

因此，Session 的名字也開始參與尋址。Claude 可根據名字尋找目標；如果名字重複，系統會增加短標識進行區分，同時顯示 Working Directory，幫助判斷每個 Session 正在處理哪個項目或目錄。

找到目標後，本機訊息會直接透過對應 Session 的 Socket 傳遞，無需經過 Anthropic Server。另一台機器或 Claude Code Web 上的 Session，才會透過 Anthropic Server 與 Remote Control 相關連接通信。

This discovery mechanism also defines the boundaries of local communication.

Claude Code 需要讀取其他 Session 寫入磁碟的註冊資訊，因此即使兩個 Claude 在物理上運行於同一台電腦，只要檔案系統彼此隔離，也可能無法互相發現。典型情況為主機與獨立容器；若兩個 Session 均運行於同一個容器中，則可正常通訊。

Inbox Socket 同時受到作業系統使用者權限限制，共享伺服器上的其他 OS User 無法直接存取你的 Session。

因此，這裡所謂的「本地通信」，實際依賴於註冊資訊是否可見、Socket 是否可達，以及作業系統是否允許存取。

訊息現在已經能夠找到目標並送入 Inbox，接下來就輪到 Claude Code 的 Runtime 決定：什麼時候把這條訊息交給模型。

03 資訊送達後

假設後端 Session 正在修改檔案，此時測試 Session 發來訊息，告知其剛剛發現了一個介面回歸問題。

Claude Code 不會立刻中斷正在運行的 Tool。

如果目標 Session 處於 Idle 狀態，訊息可以觸發一個新的 Turn；如果 Claude 已經處於 Active Turn 中，訊息會先等待，在兩個 Tool Call 之間被讀取。

這樣處理的原因與 Coding Agent 的執行方式有關。Claude 可能正在寫檔案、執行測試、執行 Migration 或處理其他耗時任務。如果外部訊息可以在任意時間強行改變當前動作，很容易出現工具只執行了一部分，Agent 卻已開始按照新資訊重新規劃的情況。

因此，這條訊息僅影響 Claude 後續的決策，而不會直接搶佔正在進行的操作。

這也意味著 Cross-session messaging 已經接入 Claude Code 的 Agentic Loop，成為一種異步輸入來源。而且這個入口不僅供其他 Claude Session 使用。

Claude Code 會將當前 Session 的 Messaging Socket 暴露給 Hook 和 Bash 啟動的子進程。一個長時間運行的後台任務結束後，可以主動將結果發回當前 Session，而無需 Claude 一直輪詢其是否完成。

這套通道本身並不是可靠消息隊列。重複消息會受到限流，短時間內相同內容可能被丟棄；已經接受但 Claude 還沒讀取的消息，每個 Session 最多保留 50 條，進入 Hold 狀態的消息則使用另一套緩衝區，最多保留 100 條。

因此它更適合用於發送狀態變化、任務結果和協作通知。必須長期保存的事實，仍應記錄在 Git、文件、資料庫或其他持久化系統中。

訊息進入 Runtime 以後，還不能直接變成執行動作，因為接收方還要先判斷：另一個 Claude 發來的內容，到底具有多大權限。

04 權限如何繼承

Claude Code 明確區分 User Message 和 Peer Session Message。

來自另一個 Session 的內容不會被視為用戶授權，因此無法為用戶批准 Permission Prompt，也不能透過訊息要求接收方修改 Permission Settings、CLAUDE.md 或其他設定。即使訊息中包含 Claude Code Command，也會被視為普通文字處理。

如果 Session A 請求 Session B 刪除一個文件，而此操作在 Session B 中需要用戶授權，則原始的 Permission Prompt 仍會出現。

Claude Code 也限制了另一種權限繞過方式：如果某個操作已在當前 Session 中被 Permission System 拒絕，Claude 不應轉而請求另一個 Session 為其執行。

否則，只要幾個 Session 的權限不同，低權限 Session 就可以不斷把自己不能完成的操作轉交給高權限 Session，原本的權限邊界也就失效了。

在執行權限之外，訊息本身還有一層 Inbound Control。接收端可以把跨 Session 訊息設定為 accept、hold 或 refuse：直接交給 Claude、暫時保留等待進一步確認，或者直接丟棄。

如果用戶沒有顯式配置規則，Claude Code 仍會參考發送方和接收方當前的 Permission Mode。一個能夠繞過普通 Permission Prompt 的 Session，不會被視為與普通 Session 完全相同的消息來源；當接收端自身的權限較高時，外部訊息同樣可能先進入 Hold。

這裡實際上有兩道判斷：先決定訊息能不能進入 Claude，再決定 Claude 根據這條訊息準備執行的動作有沒有權限。

到這一步，一條 Cross-session message 的完整路徑就已經走完了：從生成資訊、發現目標、完成投遞，到 Runtime 讀取消息，再經過接收端自己的權限控制。

05 會話之間的協調層

將這條鏈路放回 Claude Code 的現有能力中，跨會話訊息的位置就比較清楚了。

Resume Session 用於繼續原來的 Conversation 和 Context，Agent Teams 用於建立和管理一組協作 Agent，Worktree 負責隔離不同 Session 的程式碼修改，Remote Control 則解決從其他裝置繼續控制 Session 的問題。

Cross-session messaging 處理的是另一種情況：幾個本來就獨立運行的 Session，在任務過程中產生依賴以後，怎麼把必要資訊傳給對方。

以前多開幾個 Claude Code Session，主要解決的是並行問題，但開發者仍需觀察各個終端的進度，並在人與 Session 之間反覆轉述任務狀態。現在，介面變更、測試結果、Migration 完成這類資訊，可直接送至受影響的 Session。

Cross-session messaging 沒有將多個 Claude 合成為一個 Agent，而是在原有的 Context、工作目錄和權限邊界之外，補上了一層通信能力。

從更大的工程場景來看，這種設計提供了一種不同的多 Agent 思路：不同 Agent 不需要共享越來越大的 Context，也可以透過明確的通信接口完成協同。任務、狀態和權限被拆分後，系統反而更容易擴展。

隨著 Agent 數量持續增加，問題也會從「單個 Agent 能做多少事」，逐漸變成「這些 Agent 之間能不能穩定地交換狀態、處理依賴和完成交接」。

Cross-session messaging 雖然解決的只是其中一環，但它已經讓 Claude Code 的多 Session 工作方式開始具備更完整的工程結構。或許在將來，這種局域網內的跨 Session 機制，演變為跨機器、跨生態的 Agent-to-Agent 通信協議時，今天這兩段 Claude 之間的簡短對話，正是高度自動化軟體工廠成型的關鍵一步。