Claude Code 只答應管住三支筆：2.1.314 的寫入邊界，核對前先分清工具

Anthropic 在 2026 年 10 月 30 日發布 Claude Code v2.1.314，加入一項新權限設定 permissions.blockWritesOutsideWorkingDirectories。依官方發布說明的文字，Write、Edit 與 NotebookEdit 三種檔案工具「在各種 permission mode 下，拒絕工作目錄以外的路徑」。

規格表上看不到的，往往才是重點。這段說明承諾的範圍是列出的三種工具加上工作目錄邊界，沒有把 Bash、MCP 或其他外部程序列入，也沒有宣稱這項設定等同作業系統層級的檔案系統隔離。把承諾範圍讀清楚，比設定名稱本身重要。

一個 worktree 案例，把問題具體化了

這項功能被討論，源頭之一是 GitHub issue #88038 的使用者回報。回報者描述的情境是：每項自動化任務各啟動一個 Claude Code 命令列工作階段，並用 Git worktree 把任務彼此隔開。在 macOS、非互動模式與 acceptEdits 權限模式下，他比較 Bash 與 Write 對同一個 worktree 外絕對路徑的寫入；依其描述，Bash 被拒絕，Write 卻成功建立了檔案。

用一個日常比喻：你把每位客人都安排在各自的包廂，門口的保全（Bash 權限）確實攔住了想跨廳走動的人，但另一位服務生（Write）拿了鑰匙直接從側門進了別的包廂。包廂的隔間沒問題，問題在每個通道各有一套守門規則。

回報者另提到，真實自動化工作中檔案落到同一專案的另一個 checkout，後續 git commit 把它提交到當時使用的分支，形成重複且非預期的提交。該次情況沒有資料遺失，也沒有推送出去。

必須分清的是：這是單一使用者的重現描述。#88038 在 GitHub 上以「not planned」狀態關閉，較早的 #7150 也有使用者回報類似的工作目錄外修改，之後以重複問題關閉。issue 狀態只能說明討論串如何結束，不能證明所有版本都有同一問題，也不能當成 v2.1.314 已全面修復的證明。

官方承諾的三支筆，與沒承諾的部分

回到發布說明本身。需要逐一核對的是三種工具：Write（建立或覆寫檔案）、Edit（修改檔案）、NotebookEdit（編輯筆記本）。這三者的共同點是「直接以檔案路徑為對象」，因此能用工作目錄這個地理概念來設限。

但 Bash 不是這種工具。Shell 指令可以透過重定向、間接呼叫等方式碰觸檔案，它的路徑行為由另一套沙箱與權限規則處理。發布說明沒有把 Bash 列入這次承諾，把兩者當成同一個驗證項目，測試結論就會張冠李戴。

這對日常工作的意涵很直接：如果你的自動化流程同時用 Bash 與 Write 寫檔，只測其中一種，等於只鎖了大門沒看側門。路徑邊界的一致性要按工具逐一驗證，與我們先前整理過的多代理權限統一管理思路相同，工具越多，逐項驗證的成本越不能省。

另外兩個官方說明沒交代的細節也值得記下：符號連結如何解析、路徑正規化的完整規則。遇到專案內含 symlink 的情境，這些未載明的行為需要本機實測確認，不能從設定名稱推論。

導入前可以做的三個核對

來源文章建議的驗證順序，可整理成一個可操作的檢查流程：

一、對齊三層路徑認知。專案實際路徑、Claude Code 認定的工作目錄、實際執行寫入的工具，三者若未對齊，只看啟動路徑容易誤判寫入範圍。特別是 worktree 情境，啟動目錄與專案根目錄經常不同。

二、分工具測試。在工作目錄外準備一個絕對路徑的測試檔，分別用 Write、Edit、NotebookEdit 與 Bash 各寫一次，記錄哪些被拒絕、哪些成功。測試結果對照官方說明，才是本機版本的實際邊界。

三、檢查整合流程。CI 或自動化腳本若有跨 checkout、跨分支的檔案搬移，先確認這些路徑在新設定下的行為，再上線。#88038 的案例正是自動化提交落到非預期分支，事前多一分核對，事後少一次 revert。

所以呢

這次更新的價值，在於把「工作目錄」從啟動參數的隱含假設，變成一個可明確設定的邊界。但邊界只覆蓋官方列出的範圍，其餘通道仍是各自獨立的規則。對開發者而言，比較務實的態度是把這項設定當成清單上的一格，而非全部：打勾之後，Bash、MCP 與外部程序的行為，仍要按各自機制另行驗證。這也是 AI 代理工具走向工作流核心時，基礎設施跟著代理負載重設計的另一個切面：當機器開始大量讀寫檔案，路徑與權限的契約就得寫得更明白。