Sandbox

沙盒實際上限制的是什麼，跟權限模式的差別在哪？

官方文件把兩者的分工講得很明確：權限規則在任何工具真正執行之前先做判斷，適用於 Bash、Read、Edit、WebFetch、MCP 等幾乎所有工具類型，決定的是「這個工具呼叫該不該被允許執行」；沙盒則是作業系統層級的強制邊界，只作用在 Bash、PowerShell 和 Monitor 這類會產生子行程的指令上，決定的是「這個指令實際執行時，能存取哪些檔案系統路徑、能連到哪些網域」。

兩者的執行方式也不一樣：權限判斷發生在指令執行之前，依據指令字串本身和（在 Auto Mode 下）分類器的判斷；沙盒邊界則是作業系統直接對正在執行的行程做強制限制，不管模型當初選擇執行什麼，只看這個行程實際碰到了什麼——即使一個被核准的指令做了超出預期的事，沙盒仍然會生效。

沙盒預設允許存取哪些範圍，不夠的話能不能擴大？

預設情況下，沙盒化的指令可以寫入當前工作目錄、一個每個使用者專屬的暫存目錄，以及任何透過 --add-dir、/add-dir 或 permissions.additionalDirectories 額外加入的目錄。如果子行程（例如 kubectl、terraform、npm）需要寫入這個範圍以外的路徑，可以用 sandbox.filesystem.allowWrite 開放特定路徑的存取權限，這些路徑會在作業系統層級強制執行，涵蓋沙盒內執行的所有指令與其子行程。

網路存取的設計邏輯類似：指令第一次需要連到新網域時，Claude Code 會提示你批准；在 Auto Mode 下，Claude 則會把指令需要的主機名稱直接附在指令上，交給分類器一起審查。無法被沙盒化的指令（例如需要連到未授權主機的指令）會回退到一般的權限審核流程，介面上會把這類提示標題顯示成「Bash command (unsandboxed)」，跟一般的「Bash command」區分開來。

沙盒有兩種模式，auto-allow 跟一般權限模式差在哪？

Auto-allow 模式：只要指令可以被沙盒化，Claude Code 就會在沙盒裡執行它並自動核准，不詢問你的許可；無法被沙盒化的指令才會回退到一般權限流程。即使在這個模式下，幾種情況仍然會強制走一般流程：明確的 deny 規則永遠優先生效；針對關鍵路徑的 rm 或 rmdir 指令仍會走一般審核；像 Bash(git push *) 這種限定內容的 ask 規則，即使指令已被沙盒化，依然會強制跳出提示。

一般權限模式：所有 Bash 指令都走一般權限流程，即使它已經被沙盒化也一樣——控制力更強，但需要更多次核准。這裡容易搞混的是，沙盒的 auto-allow 跟權限層的 Auto Mode 是兩套完全獨立的機制：auto-allow 讓指令通過，是因為沙盒邊界已經把它框住了；Auto Mode 讓指令通過，靠的是分類器對這個動作內容的判斷，兩者可以同時啟用、彼此不互相取代。

設定沙盒的時候，最常見的實際錯誤組合是什麼？

社群文章〈Claude Code Permission Modes in 2026〉記錄了一個直接的失效案例：一套設定允許 run_command 這個工具被呼叫，卻忘了把沙盒限制在安全的目錄樹範圍內——結果代理程式可以毫無阻礙地執行類似 rm -rf / 的指令。這裡的關鍵是，「允許呼叫這個工具」跟「沙盒實際框住的範圍」是兩個完全獨立的設定項，前者放行了不代表後者也收緊了。

同一篇文章還記錄了另一個案例：團隊為 code review 設定逐一詢問的 Prompt 模式，批准了一次 npm audit fix 的請求，但沙盒設定把 /node_modules 掛載成可讀寫、且具備 root 權限，權限審核這一層順利通過，沙盒隔離這一層卻沒能把安裝套件時可能發生的惡意行為限制在該有的範圍內。