--restricted 是不是就等於「Claude Code 現在有沙盒了」?
不是。官方文件裡明確把這件事講清楚:--restricted 是一個有用的低權限起點,適合用來審查不熟悉的程式庫,或執行範圍很窄的 CI 任務,但它「不是」作業系統層級的沙盒。它做的事情是縮小 Claude Code 這個應用程式自己能存取的工具、檔案範圍、設定來源,不是在作業系統層級隔離整個處理程序、網路連線或憑證存取。
如果你的情境是「這份輸入完全不可信,而且需要能執行任意程式碼」,官方建議的做法是把整個流程放進強化過的容器或虛擬機裡,再另外套用 Claude Code 自己的沙盒控制作為額外一層——--restricted 可以是這個流程裡的一部分,但不能單獨扛起「隔離不可信輸入」這件事。
為什麼「使用者、專案、本機設定被忽略」跟「MCP 伺服器不受影響」要分開處理,不能一起收緊?
這反映的是這兩類設定原本的性質不同。使用者、專案、本機這三層設定檔,主要是「這個人或這個專案平常怎麼用 Claude Code」的個人化偏好與慣例——忽略它們,能確保這個 session 不會不小心繼承你平常在別的專案裡養成的習慣性規則。但 MCP 伺服器是「外部系統的連接點」,它的存在與否,通常牽涉到你當下這個任務究竟需不需要連到某個外部服務,這是一個跟「個人慣例」不同維度的問題。
如果 --restricted 自動連 MCP 伺服器都一併清空,對於真的需要透過 MCP 存取某個內部工具的受限任務(例如只需要用某個唯讀的內部知識庫 MCP 伺服器),會變得綁手綁腳,你還得另外想辦法把它加回來。把「清空個人化設定」跟「決定要不要保留 MCP 連線」拆成兩個獨立的決定(後者要靠 --strict-mcp-config 主動觸發),讓使用者可以依照任務的實際需求分別調整,而不是被迫全有或全無。
如果我想拿 --restricted 來做一個純唯讀的程式庫審查,實際上該怎麼組合這些選項?
最直接的組合方式,是同時明確宣告工具清單跟 MCP 設定,而不是只開 --restricted 就期待它自動變成唯讀。實務上會是類似這樣的組合:--restricted --tools "Read,Grep,Glob" --strict-mcp-config --mcp-config ./restricted-mcp.json——用 --tools 明確只列出讀取類的工具,不包含任何會執行指令或編輯檔案的工具;--strict-mcp-config 搭配一份你自己準備、內容為空或只含真正需要的伺服器的 MCP 設定檔,確保沒有其他來源的 MCP 伺服器意外介入。
如果這個審查過程中發現真的需要做編輯,比較保守的做法是額外加入範圍很窄的檔案編輯工具,並保留對受保護檔案的核准機制,而不是直接把整個 --restricted 的效果換成寬鬆的 Bash 權限,然後告訴自己這個 session 還是「低權限」的——一旦恢復了會執行指令的工具,就已經不是原本 --restricted 想要維持的那種低權限狀態了。
如果我團隊裡本來就有受管理的組織設定(managed settings),使用 --restricted 的時候會有什麼特別要注意的?
最需要先確認的一點,是受管理設定不會因為 --restricted 而被繞過——這代表如果你的組織原本就透過受管理設定強制某些安全政策(例如禁用 bypassPermissions、限制某些高風險工具),這些政策在 --restricted session 裡依然有效,不需要擔心 --restricted 意外削弱了組織既有的防護。
但反過來也要注意:--restricted 忽略的是使用者、專案、本機這三層,如果你的團隊習慣把某些安全性的自訂規則(例如額外的 deny 規則)寫在專案層級的設定檔裡,而不是受管理設定裡,這些規則在 --restricted session 裡會被忽略——這代表如果你原本依賴專案層級的規則來補強某個特定風險,--restricted 反而可能讓這個補強暫時失效,需要額外確認這類規則是不是也該提升到受管理設定的層級,才能確保任何啟動方式下都持續生效。
Claude Code 2.1.248(2026 年 8 月 27 日)新增了 --restricted 這個啟動旗標,連同對應的環境變數 CLAUDE_CODE_RESTRICTED=1。這個模式的定位很明確:它不是作業系統層級的沙盒,而是一個「預設把權限收到最小、由你自己決定要不要一項一項加回來」的啟動設定,特別適合處理你不熟悉、還沒建立信任的程式碼庫。
啟用 --restricted 之後,內建的指令執行與程式碼執行工具(例如 Bash),以及 WebFetch,預設會被移除,除非你用 --tools 明確把它們加回來。它同時會忽略使用者、專案、本機這三層設定檔,檔案工具的存取範圍會被限制在啟動時所在的工作目錄(以及你用 --add-dir 額外加入的目錄),而且拒絕接受 bypassPermissions 這種完全跳過權限確認的模式。
第一個容易誤解的地方,是「設定檔被忽略」不等於「所有設定都失效」——受組織管理的設定(managed settings),以及你用 --settings 明確指定的設定檔,依然會生效。如果你只看到「使用者、專案、本機設定被忽略」就以為這個 session 完全乾淨,沒有檢查是否還有受管理設定在背後運作,可能會誤判實際的權限範圍。
第二個容易誤解的地方,是 MCP 伺服器的處理方式跟其他工具不一樣——--restricted 本身不會自動清空既有的 MCP 設定,如果你的情境需要確保沒有任何外部 MCP 伺服器介入,需要額外加上 --strict-mcp-config,搭配一份你自己準備、內容經過檢視的 MCP 設定檔。單純啟用 --restricted,不代表 MCP 這個管道也一併被收緊。
如果你之前做過的是審查、收緊 Bash 萬用字元規則(例如把過寬的 Bash(git *) 改成更精確的規則),那是在「指令執行工具已經存在」的前提下,限制它能執行哪些指令。--restricted 處理的是更早一層的問題——這個 session 裡,指令執行與程式碼執行工具本身要不要存在,預設答案改成「不存在」,你得主動決定要不要把它加回來,而不是預設存在、只靠規則限縮範圍。
比較穩妥的起手式,是先固定住實際在用的版本(不同安裝方式、不同介面掛的版本可能不一致,先確認 --version 印出的版本號正確),然後從一個不含正式環境憑證、範圍夠小的目錄開始,而不是圖方便直接從 home 目錄或整個 monorepo 根目錄啟動——因為 --add-dir 會直接擴大檔案工具能碰到的範圍,每加一個目錄,都值得先想清楚為什麼需要。對於單純的唯讀程式碼審查情境,直接明確列出 --tools "Read,Grep,Glob",搭配一份不含任何伺服器的 MCP 設定檔,會比先啟用再事後檢查更清楚。