兩個 Claude Code 開著，你不該一直切過去看它好了沒

寫於 2026 年 8 月 20 至 21 日（補 8 月 19 日的排程），9 月才上線（部落格的發佈額度在 8 月中用完了，稿子積壓了三週）。文中的版本號與「目前」都指 8 月 20 日的狀態，Claude Code 更新很快，你讀到時可能又改過了。

左邊的 terminal 在跑一個十五分鐘的建置，右邊的我在改另一個 repo 的測試。改到一半我又切過去左邊看它跑完沒有。沒有。回來右邊，剛才在想什麼？忘了。

那天我大概切了二十次。每次切過去看的成本不是那三秒，是回來之後重新裝載腦袋裡的東西。

我先想到的解法是叫左邊那個 session 跑完之後寫一個檔案，右邊寫個 while 迴圈盯著那個檔案。這確實會動，但輪詢的人只是從我換成 bash——每兩秒問一次「好了嗎」，這件事本身沒有消失。

第二個想法是用背景任務的通知。這條路更短：背景任務跑完會回來通知，但通知的對象是開啟那個任務的 session。左邊 session 完成的事，右邊不會知道。它們是兩個 session，不是同一個 session 的兩條 thread。

8 月 19 日這版加的東西正好是這個

Claude Code v2.1.236 的 changelog 原文：

Added notify_when_idle to cross-session SendMessage: ask another Claude Code session on this machine to send one notice when it next goes idle — opt-in, one-shot, no polling (macOS and Linux)

四個限定詞是重點。opt-in：你要明確要求，不會自動發生。one-shot：只通知一次，不是訂閱它之後每一次 idle。no polling：沒有人在後台每隔幾秒問一次。macOS 和 Linux：Windows 目前沒有。

方向翻過來了。原本是等的人一直問，現在是被等的人在忙完的時候說一聲。

等外送就是這個差別。你可以每三分鐘開門看一次，也可以請店家到了按一次電鈴。同一件事，但第二種做法讓你在等的時候能專心做別的事，而這就是全部的價值，不是省了那幾次開門。

idle 這個詞要看清楚。它不是「任務成功了」，是「那個 session 沒事做了」。跑完、失敗、被中斷、卡在等你回答權限問題然後放棄，這些都可能算 idle。通知只告訴你「它停了」，不告訴你「它成了」。你還是得切過去看結果。

即使如此還是值得用。二十次減到一次，減掉的是那十九次無效的上下文切換。

你需要先有名字

跨 session 訊息是靠名字找收件人的。我在本機（Claude Code 2.1.237）查了 CLI 的旗標，有這一個：

1	-n, --name <name> Set a display name for this session

沒有名字的 session 就得靠 id。8 月 17 日那版還修過一個相關的坑：從 ListAgents 複製過來的收件人，如果 session 名稱剛好卡在 200 字元上限、或塞滿 emoji，SendMessage 會拒收。名字取正常一點，別拿 emoji 當名字。

另一個前置條件是收件方要願意收。8 月 10 日那版加了 crossSessionInbound 與 dialogExpiry 兩個設定，讓權限全開的 session 收到外來訊息時先攔下來問你。這件事我當時寫過一篇（權限全開的 session 收到外來訊息，Claude Code 現在會先攔下來問你）。我查了自己的 ~/.claude/settings.json，裡面沒有這個 key，也就是走預設值。要真正上線用，這個設定你得自己確認過。

還有一個範圍限制得講清楚，不然你照做會撞牆。我在本機一個 session 裡看 SendMessage 這個工具的實際參數，拿到的是 teammate 版本：to、message、summary 三個，收件人寫的是 teammate 名字或 main，**沒有 notify_when_idle**。

這證明的事情很有限：它只說明「這個 session 拿到的 SendMessage 沒有暴露那個參數」，不代表功能不存在。同一個工具名在不同情境下的參數是不一樣的：teammate 之間傳訊跟跨 session 傳訊走的是不同路徑，notify_when_idle 掛在後者。你如果打開手邊的 Claude Code 沒看到這個參數，先確認你的 session 是不是真的在跨 session 那條路上，而不是急著判定官方寫錯。

這條路徑 8 月被修了很多次

真正讓我對這功能有信心的不是它本身，是它周圍那一串修補。整理一下 8 月的 changelog（原文照抄關鍵句）：

版本	修了什麼
2.1.234	`Fixed Claude Desktop inter-session messages being silently dropped by the recipient session when cross-session messaging read as disabled, which left the sender's query "thinking" for many minutes`
2.1.234	`SendMessage and ListAgents now say when your account's session list was too long to check completely, instead of treating unseen sessions as absent`
2.1.235	`SendMessage now refuses messages too large for cross-session delivery up front instead of silently dropping them`
2.1.236	`SendMessage now refuses further messages to a session up front once a rapid burst would exceed what that session's inbox accepts, instead of reporting them sent while they were dropped`

四筆有三筆是同一個病：訊息看起來送出去了，實際上被丟掉了。 送的人以為送到，等的人什麼都沒收到，然後那個 query 在畫面上「thinking」好幾分鐘。

這就是為什麼我對「靜默失敗」這個詞特別敏感。錯誤會叫，你會去修；靜默失敗不會叫，你會以為自己搞錯了，然後花二十分鐘查一個根本不在你這邊的問題。

回到電鈴的類比。這一串修補等於：你請店家按電鈴，店家按了，但鈴不會響，而店家那邊顯示「已送達」。這比店家忘記按更糟——因為你會待在門後面等一個永遠不會來的聲音。

現在這幾條都改成「當下就拒收並告訴你」。收不了就明說收不了，這比假裝收下好一百倍。

我還沒驗證的

我沒有實際跑過兩個 session 互相 notify_when_idle 的完整流程。上面關於這個參數的行為，全部來自官方 CHANGELOG 的原文；我自己實測到的只有三件事：本機版本是 2.1.237、CLI 有 --name 旗標、我這個 session 的 SendMessage 沒有那個參數。

要自己驗證的話，最小重現大概是這樣：開兩個 terminal，各自用 claude --name a 與 claude --name b 啟動，在 a 裡面丟一個會跑很久的任務，然後在 b 裡面要求它請 a 在 idle 時通知一次。看通知會不會回到 b。