這篇是 2026 年 9 月 2 日補寫的（排程斷了幾天，回頭把日期補齊）。文中的版本號與「目前」指的是撰寫當日的官方文件狀態。

claude --restricted 打下去，畫面跟平常沒有任何不同。同一個提示符，同一份 CLAUDE.md 的味道，同一個模型。那它到底把什麼東西關掉了？

先看它自己怎麼講。CLI reference 裡 --restricted 這條的原文是：

Start in restricted mode. Use it when an evaluation harness drives claude on a shared machine and Claude Code must not run commands or read that machine’s user and project settings. … Requires Claude Code v2.1.248 or later

版本這件事順便對一下：2.1.248 上 npm 的時間就是今天，2026 年 8 月 27 日。所以你昨天裝的那版打這個旗標，它不認得。

拆開來只有四條規則

restricted 模式啟動的當下，照文件的描述，它做掉四件事。

最大的一刀砍在會動手的工具上：跑指令、跑程式碼的內建工具，加上 WebFetch，一律移除。除非你在 --tools 裡把它們逐個點名。

檔案工具沒被拿走，是被關進籠子：只能在 working directories 裡面活動，出了那個範圍就不行。

設定檔那條比較隱晦。它只載 managed settings 與你用 --settings 明確指定的那一份，user、project、local 三層設定檔完全不讀。你 ~/.claude/settings.json 裡那些調了半年的偏好，在這個模式底下當作不存在。

剩下的是兩個直球拒絕：拒絕 bypassPermissions，也拒絕建立 cloud session。不是問你要不要，是不給。

四條，就這樣。沒有第五條。

--tools "default" 救不回 WebFetch

第一條裡那句「除非在 --tools 裡逐個點名」，是這整個模式最容易讓人以為自己開了、其實沒開的地方。

--tools 收得下 preset。你寫 --tools "default"，直覺上就是「用預設那套工具」，聽起來 WebFetch 當然在裡面。但文件的措辭是逐個點名，preset 不是點名，是一個群組的代稱。照文件這樣讀下去，--tools "default" 不會把 WebFetch 救回來。

這件事的難處在於它沒有錯誤訊息可以看。工具被移除不會噴 error，模型只是不去用它，然後回你一段沒有引用網頁內容的答案。你會以為它查過了、只是查得不好。要點名就得把工具名一個一個寫出來，寫得很醜，但那是唯一會生效的寫法。

先標清楚：這一段是照文件的字面推的讀解，我沒有實際跑過 claude --restricted --tools "default" 去看 WebFetch 到底在不在。文件是這樣寫的，行為是不是完全照這句話，我不知道。要拿它做重要的事之前，自己開一個 session 問它「你現在有哪些工具」比較保險。

這四條有一個共同點

把四條擺在一起看，會發現它們動的都是同一件事：Claude 能不能做某類動作。

能跑的沒了、能抓的沒了，越界讀檔和跳過權限檢查也一樣。它一條都沒有在講「哪個指令可以跑、哪個不行」。

那個「哪個可以哪個不行」是 permissions 的 allow / deny 在管的，是另一層。這兩層的關係是 AND，不是 OR：restricted 模式先決定 Claude 手上有哪些工具，permissions 再決定拿著這些工具能不能碰某個具體目標。第一層把工具收走了，第二層寫得再漂亮也沒有東西可以管；第一層留著工具，第二層照樣可以擋。

寫成一句順序：能力層先過濾，規則層再過濾，兩關都過才動得了。

--safe-mode 關掉的是完全不同的一半

Claude Code 現在有三個「把東西關掉」的旗標，名字都很像，切的層完全不同。

旗標 關掉什麼 留下什麼
--safe-mode 客製化：CLAUDE.md、skills、plugins、hooks、MCP 一律不載 工具與權限照常運作，手還是那雙手
--restricted 能力：跑指令與跑程式碼的工具、WebFetch、越界的檔案存取、bypassPermissions 客製化的載入規則不歸它管，但設定只讀 managed 與 --settings
--bare headless 啟動時的額外載入 用途是加速啟動，不是收權限

借出差的情境講會比較清楚。--safe-mode 是你借同事的電腦做事：桌布、快捷鍵、你裝的外掛全部沒有，用出廠設定硬幹。手還是你的手，能做的事情一樣多，只是做起來很卡。

--restricted 是你進到別人公司的訪客網路：桌面照樣長你熟悉的樣子，習慣一個都沒少，但 USB 孔封起來了、外網擋掉了、只准碰指定的那個資料夾。

一個關掉的是習慣，一個關掉的是權限。兩者的交集只有「Claude 會變笨」這個結果，笨在哪一半差很多。搞錯的代價很實際：你的 hook 壞了想找原因，該用的是 --safe-mode；你要跑一份來路不明的 repo，該用的是 --restricted。用反了，前者查不到問題，後者防不到該防的。

文件寫的情境，跟你會用到的情境不一樣

官方講的使用時機很窄：evaluation harness 在共用機器上驅動 claude，而 Claude Code 不可以跑指令、不可以讀那台機器的 user 與 project 設定。

翻譯一下這個情境在防什麼。共用機器上跑自動化評測，最怕兩件事：一是評測過程把機器弄髒（跑了不該跑的指令），二是評測結果被機器上別人的設定汙染（讀到某個 project 的 CLAUDE.md，結果同一份題目在不同機器上分數不一樣）。第三條規則不讀 user 與 project 設定，防的是後者，那是可重現性的問題，不是安全問題。

一般人不會有 evaluation harness。但把這四條規則湊起來看，它描述的其實是幾種很日常的場合。

最常見的是跑別人給的 repo。你 clone 一個沒看過的專案下來想請 Claude 幫你摸清楚結構，那個 repo 裡可能有 .claude/settings.json、可能有 hooks、可能在 CLAUDE.md 裡寫了對你不利的指示。restricted 模式不讀 project 設定，也不讓它跑指令。

餵不信任的 prompt 也算。從網路上抄來一段很長的 prompt 想試效果，裡面藏了什麼你沒有逐字讀過。工具都被收走的情況下，最壞結果是它輸出一段廢話。

還有 CI 裡的唯讀分析。讓 Claude 讀 diff 寫摘要、跑靜態檢查的判讀，本來就不需要它能跑指令；能力收掉之後，這個 job 就不可能因為模型「自己想試試看」而動到 build 環境。

我的立場是：日常開發不要開它。四條規則裡有兩條會直接讓正常工作流失效（不能跑指令、不讀你自己的設定），你會花整個下午在跟工具吵架。它該長的位置是 CI 與「跑別人給的東西」這條路上。如果哪天 --tools 的點名可以用群組表達，或文件明確承認 preset 也算點名，日常用它的摩擦會小很多，那時候我會改口。

同一個切法可以搬到別的地方

把能力層跟規則層分開，這個想法不是 Claude Code 發明的。

容器的 capability drop 是同一套：你可以寫再細的檔案權限規則，但只要 process 手上還有 CAP_SYS_ADMIN，那些規則的意義就有限。先把能力砍掉，再談規則，順序不能反。資料庫的唯讀連線也是同一套：與其在應用層一條一條檢查「這個 SQL 是不是 SELECT」，不如發一把根本執行不了寫入的連線。前者是規則層，你得窮舉所有壞情況；後者是能力層，你只要確定那把鑰匙開不了那扇門。

這兩者的差別，用一句話講最清楚：規則層要求你想得到所有壞事，能力層不要求。

所以下次設計任何一個「要限制 AI 能做什麼」的東西，第一個該問的不是「我要禁止哪些動作」，是「這件工作最少需要哪些能力」。前者是一份永遠列不完的黑名單，後者是一份通常短得意外的白名單。--restricted 只有四條規則就講完了，正是因為它走的是後者。

順便講一下這篇的邊界：我只讀了官方 CLI reference 與 CHANGELOG，沒有實際跑過 claude --restricted，上面所有行為描述都是文件寫的行為。版本與日期的對應是查 npm registry 的發布時間得到的，不是搜尋摘要。

參考連結