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

最早的用法是這樣的：開一個終端機，跑起來，你坐在前面看著它跑。

它要動檔案會問你、要跑指令會問你，你一個一個按。慢，但那個慢有個好處。每一件事都經過你的眼睛，整條鏈路上只有兩個角色，你跟它。

然後這條線開始長出分支。

先是你開了第二個視窗

一個 session 在改後端，你懶得等，另開一個視窗讓它去寫測試。兩個互不相干，各跑各的。

這時候還沒事。它們之間沒有任何通道，最多就是同時動到同一個檔案時打架，而那是 git 的問題不是安全問題。

再來你開始嫌一個一個按太累。專案裡有些操作明明每次都會允許，卻每次都要點一下。於是你開始用權限比較寬鬆的模式跑那些「反正都會答應」的工作，讓它一路做完不要一直停下來問。

這一步是關鍵。你在某一個 session 上，親手把那道確認的門拆掉了。你當時的判斷完全合理：這個 session 我知道它在幹嘛，我看著它。

接著你人離開了電腦前面

Remote Control 出現之後，事情又變了一次。你人在捷運上、在開會、在睡覺，用手機把工作丟給一個正在跑的 session。

現在「你看著它」這個前提已經不成立了。門是你拆的，但拆門時的那個前提——我在旁邊——悄悄失效了。

再往後，session 之間也能互相傳話了。一個 agent 做完事情通知另一個、一組 agent 分工協作、排程在半夜叫醒某個 session。這些能力每一項單獨看都很合理，也確實好用。

但把它們疊在一起會得到一個很尷尬的組合：一個沒有確認關卡的 session，接得到來自外面的訊息，而你不在。

於是 8 月 7 日多了一道門

Claude Code v2.1.224（2026-08-07）的更新裡有這麼一條，原文是這樣寫的：

Added crossSessionInbound and dialogExpiry settings: cross-session messages sent to a session running with bypassed permissions are held for your approval, and messages to other sessions auto-deliver

翻成白話：跨 session 的訊息送進一個「權限被繞過」的 session 時，會先被扣住等你核准；送到其他一般 session 的則照常自動投遞。

它防的東西很具體。假設有個 session 你開著寬鬆權限在跑批次工作，這時另一個來源送了一則訊息進來，可能是另一個 agent、一個排程，或一個你半年前設好早就忘記的自動化。在這道門出現之前，那則訊息會直接變成指令，在一個不會停下來問你的環境裡執行。

門加在哪裡，這件事本身就說明了設計者怎麼想。它沒有去限制「誰可以送訊息」，而是限制「訊息送進什麼樣的環境」。送給正常 session 的照舊自動投遞，一點都沒擋。它擋的不是訊息，是訊息與空白支票的組合。

這兩個設定分別管什麼，官方沒說

我得在這裡誠實一點。

changelog 那一條把兩個設定名綁在同一句話裡，然後描述了一個行為，但沒有分別說明 crossSessionInbound 管什麼、dialogExpiry 管什麼，也沒給預設值。

從名字猜，crossSessionInbound 應該是管進來的跨 session 訊息怎麼處理，dialogExpiry 大概是那個等你核准的對話框放多久會過期。訊息扣住總不能無限期扣著，你在睡覺，它總得決定天亮前要不要放棄。但這兩句都是我從命名推的，不是文件寫的，請當推測看。

我自己這台機器現在跑的是 2.1.226，功能已經在了，但 ~/.claude/settings.json 裡這兩個 key 一個都沒有，所以我跑的是預設行為。我沒有實際設過它們，也沒有刻意造一個「權限全開的 session 收到外部訊息」的情境去看它到底怎麼攔。所以這篇能給你的是「這道門為什麼會出現、它守在哪個位置」，不是「這兩個值該調多少」。

想確認你自己的狀態，這樣看就好：

1
2
3
4
5
# 看版本有沒有到 2.1.224 以上
claude --version

# 看有沒有顯式設過這兩個 key（沒有就是走預設）
grep -E 'crossSessionInbound|dialogExpiry' ~/.claude/settings.json

該關心這件事的是誰

如果你只用一個 session、全程手動確認、人一直在電腦前，那這道門對你來說幾乎不存在，它守的那條路你根本沒走過。

但只要你符合下面任一種，這件事就跟你有關：習慣用寬鬆權限跑長工作、用 Remote Control 或手機遠端丟任務、有排程或 hook 會主動叫醒 session、跑多 agent 協作。這幾種用法我自己都在用。光是 ~/.claude/projects/ 底下就有 35 個專案目錄，其中有排程每天固定把工作丟進去。

有意思的地方在於，這道門補的其實不是程式的漏洞，是人的假設過期了。你拆那道確認關卡的時候，心裡有一個前提叫「我看著它」。後來遙控、排程、多 agent 一個個加進來，每一項都好用，但沒有任何一個時刻會有人跳出來提醒你：你當初拆門的理由，已經不成立了。

安全設定通常都是這樣長出來的。不是因為有人寫錯了程式，是因為一堆各自合理的功能疊起來，把某個舊前提悄悄掏空了。

那下一個被掏空的前提會是哪一個？現在 agent 已經能叫醒彼此、能排程、能在你睡覺時互相派工。「我最後會看到結果」這個前提，還撐得住嗎？

來源：Claude Code changelog v2.1.224（2026-08-07）。文中引用的 changelog 為原文照錄；兩個設定各自的職責與預設值官方未說明，文中相關描述已標示為推測。本機版本 2.1.226，未實際設定過這兩個值。