如果我已經開了 Auto Mode，還有必要另外設定沙盒嗎？
有必要，而且兩者不能互相取代。Auto Mode 控制的是「這個工具呼叫該不該執行」，靠的是分類器對動作內容的判斷；沙盒控制的是「這個指令執行後能碰到哪些檔案系統路徑跟網域」，靠的是作業系統層級的強制邊界。這兩層各自覆蓋不同的風險：Auto Mode 沒有擋下的動作，如果沙盒邊界設得夠緊，仍然有機會把實際傷害限制在安全範圍內；反過來，沙盒邊界即使設得再嚴，也管不到 Read、Edit、WebFetch、MCP 這些不會產生子行程的工具類型，這些仍然完全依賴權限規則把關。只開一層，等於把另一層的攻擊面完全暴露出來。
沙盒的 auto-allow 模式跟權限層的 Auto Mode，名字這麼像，是不是同一個東西的兩種說法？
不是，這是官方文件特別澄清過的一點。沙盒的 auto-allow 模式，讓 Bash 指令不需要逐次詢問就能執行，原因是這個指令已經被沙盒邊界框住了，就算它想做壞事，能碰到的範圍也有限；權限層的 Auto Mode，讓工具呼叫不需要逐次詢問就能執行，靠的是一個分類器對這次動作內容進行審視、判斷是否安全。
這兩個機制可以同時啟用、彼此獨立運作，但取代「詢問」這件事的機制完全不同——一個是硬邊界擋下越界存取，一個是軟性的內容判斷。如果只看名字裡都有「auto」就以為是同一層在管，很容易誤判自己的實際防護範圍。
如果我用 --dangerously-skip-permissions，是不是代表沙盒也一起被跳過了？
不是同一件事，這正是這個旗標容易被誤解的地方。--dangerously-skip-permissions 管的是權限層——它讓每一次工具呼叫都不再需要核准，連保護路徑檢查都會被跳過，取代詢問的機制是「什麼都沒有」。但沙盒是獨立於權限層之外的另一套機制，是否啟用取決於你自己的沙盒設定（例如 sandbox.enabled），跟你有沒有加這個旗標沒有直接關係。
這也代表一個常被忽略的風險：如果你同時跳過了權限層、又沒有另外啟用或收緊沙盒設定，等於兩道防線同時失守，任何工具呼叫都不會被過濾，實際能碰到的檔案系統跟網路範圍也完全沒有邊界。這個旗標的名字裡本來就寫著「dangerously」，用之前務必先確認沙盒這一層有沒有獨立扛住。
我不是安全專家，只想確認自己的自動化流程有沒有踩到這個坑，最簡單的檢查方式是什麼？
不需要一開始就記住每個設定鍵，先做一件事就好：找出你目前允許 Claude 自動執行的工具清單，針對清單裡任何會呼叫 Bash、PowerShell 或類似指令列工具的項目，去確認沙盒有沒有把它限制在一個明確、安全的目錄範圍內，而不是預設放行整個系統。如果答案是「沙盒設定我沒特別調過」，那大概率代表你目前只靠權限層這一道防線在守，沙盒範圍可能比你以為的寬得多。
確認完設定之後，找一個安全的測試環境，故意模擬一次「工具呼叫被允許，但嘗試碰觸不該碰的路徑或網域」的情境，實際看它有沒有被沙盒擋下來。這個測試比讀懂任何一份設定文件都更能告訴你，自己的防線到底在哪裡。
「我開了 Auto Mode，應該不會出什麼大事」——這句話背後藏著一個常見誤會：把「Claude 敢不敢動手」跟「Claude 動手之後能碰到什麼」當成同一件事在管理。這兩者其實是完全獨立的兩道防線，一道決定「這個工具呼叫要不要先問過你」，另一道決定「就算被批准了，這個指令實際能碰到哪些檔案、連到哪些網域」。搞混這兩層，是目前團隊在設定 Claude Code 自動化流程時最容易犯、也最容易造成實質損害的錯誤。
官方文件對這兩層的分工給出了明確定義：權限規則（permission rules）在任何工具真正執行之前先做判斷，適用於 Bash、Read、Edit、WebFetch、MCP 等幾乎所有工具類型，決定的是「這個工具呼叫該不該被允許執行」。沙盒（Sandbox）則是作業系統層級的強制邊界，只作用在 Bash、PowerShell 和 Monitor 這類會產生子行程的指令上，決定的是「這個指令實際執行時，能存取哪些檔案系統路徑、能連到哪些網域」。
這兩者的執行方式也不一樣：權限判斷發生在指令執行之前，依據的是指令字串本身，以及在 Auto Mode 下，一個獨立分類器對這個指令是否安全的判斷。沙盒邊界則是作業系統直接對正在執行的行程做強制限制，這代表即使一個指令的名稱看起來無害、內容卻做了超出預期的事，沙盒邊界仍然會生效——它不管模型當初「選擇」執行什麼，只管這個行程實際上碰到了什麼。
社群文章〈Claude Code Permission Modes in 2026〉（作者 jsmanifest）給出了一個直接的失效案例：一套設定允許 run_command 這個工具被呼叫，卻忘了把 Bash 沙盒限制在安全的目錄樹範圍內——結果就是代理程式可以毫無阻礙地執行類似 rm -rf / 這種指令。這裡的關鍵是，「允許呼叫這個工具」跟「這個工具能碰到系統的哪個角落」，是兩個完全獨立的設定項，前者放行了，不代表後者也已經被收緊。
同一篇文章還記錄了另一個生產環境案例：團隊為 code review 流程設定 Prompt 模式（也就是逐一詢問），批准了一次 npm audit fix 的請求，但沙盒設定把 /node_modules 掛載成可讀寫、且具備 root 權限。權限審核這一層順利通過了，但沙盒隔離這一層沒能把安裝套件時可能發生的惡意行為限制在該有的範圍內。這個案例點出一件事：即使你在權限這一層做得再仔細，沙盒邊界沒對齊，防線一樣會被繞過。
Claude Code 官方文件用一張對照表講得很直接：/sandbox 控制的是「Bash 指令執行後能碰到什麼」，取代逐次詢問的機制是沙盒邊界本身（在 auto-allow 模式下）；而 Auto Mode（權限模式的一種）控制的是「每一次工具呼叫是否要執行」，取代逐次詢問的機制是一個會審視動作內容的分類器；至於 --dangerously-skip-permissions，控制的同樣是「每次工具呼叫是否要執行」，但取代詢問的機制是「什麼都沒有」——連保護路徑檢查都會被跳過，只剩少數任何模式都無法自動核准的動作仍然受限。
文件也特別強調：沙盒的 auto-allow 模式跟權限層的 Auto Mode，是兩套獨立運作、彼此不互相取代的機制。auto-allow 讓 Bash 指令自動通過，是因為沙盒邊界已經把它框住了；Auto Mode 讓工具呼叫自動通過，靠的是分類器對這個動作內容的判斷。兩者可以同時啟用、彼此獨立運作，但也代表其中一層寬鬆，不會被另一層自動補起來。
如果要動手調整，官方文件列出的對照相當具體：檔案系統這一側，sandbox.filesystem.allowWrite 用來把工作目錄以外的路徑開放給子行程寫入，sandbox.filesystem.denyWrite 和 denyRead 用來封鎖特定路徑，這些跟權限層的 Edit allow 規則、Read／Edit deny 規則是分開設定、但最終會合併進沙盒的實際配置裡。網路這一側，沙盒的 allowedDomains／deniedDomains 控制 Bash 指令能連到的網域，跟權限層的 WebFetch(domain:...) allow/deny 規則也是分開的兩組設定。換句話說，同一個「這個路徑能不能寫」的問題，會同時受權限規則跟沙盒設定影響，兩邊都要檢查過，才能確定實際邊界在哪裡。
不完全是這樣理解。沙盒邊界的強制力確實更硬——它是作業系統層級的限制，不看模型選擇執行什麼，只看行程實際碰到什麼，這意味著即使一個被核准的指令做了超出預期的事，沙盒仍然能擋下越界的存取。但沙盒只覆蓋 Bash、PowerShell、Monitor 這幾類會產生子行程的工具，Read、Edit、WebFetch、MCP 呼叫等其他工具類型，仍然完全依賴權限規則這一層來把關。兩層各自覆蓋不同的攻擊面，缺一不可，不存在「只要沙盒夠嚴就不用管權限規則」這種簡化說法。
比起記住每一個設定鍵的名字，更實際的做法是先問自己兩個問題：如果 Claude 被批准呼叫某個工具，這個工具實際執行時能碰到的檔案系統範圍夠不夠窄；以及即使沙盒邊界設得再嚴，有沒有某類工具（例如 MCP 呼叫）完全繞過了沙盒、只靠權限規則把關，而權限規則本身是不是也已經收緊。任何自動化流程上線之前，值得针對這兩個問題各自做一次實測——故意讓一個被允許的動作嘗試碰觸它不該碰到的東西，親自確認它有沒有真的被擋下來，而不是假設「設定寫了就一定生效」。