官方設定頁的排錯段落，有一句讀起來像在跟自己打架：「A security key keeps its strict value. For a few keys Claude Code honors the restrictive value from any file, so a project true for disableClaudeAiConnectors stays on」（出處：Settings，2026-11-09 取得）。

managed 設定明明在優先序的最頂端，那一個 repo 裡的 true，憑什麼留得下來？答案在同一頁另一張表裡，標題叫「Exceptions to managed settings precedence」，列了 12 個 key。下面把它拆開。

以前的讀法：越上層越大

先把一般規則放在手邊。同一頁寫的優先序，高到低是：managed settings、command line、project local、shared project、user。managed 那條的原文是「Nothing in your own settings files or --settings overrides a managed key」。我的 key 在 managed 裡有值，我在任何自己的檔案裡寫什麼都沒用。

這套規則在站上五層優先序那篇講過。拿它回答「誰說了算」，大部分時候夠用。

例外表回答的是另一種問題：有些 key 的值是在限制 session，官方的說法是「Claude Code honors a restrictive value from a scope that otherwise couldn’t override managed settings」。也就是說，原本蓋不掉 managed 的那一層，只要寫的是比較嚴的值，就算數。

這張表列了什麼

下表的第二欄照官方原文，第三欄只放表內有寫的版本需求。

key 算數的值 表內版本需求
disableClaudeAiConnectors true from any scope 未標
enableArtifact false from any scope, and disableArtifact: true from any scope v2.1.242
isolatePeerMachines true from any scope 未標
permissions.blockReadsOutsideWorkingDirectories true from any scope v2.1.257
permissions.blockWritesOutsideWorkingDirectories true from any scope v2.1.314
autoMode.classifyAllShell true from ~/.claude/settings.json or --settings 未標
remoteControlAtStartup false from .claude/settings.json or .claude/settings.local.json 未標
crossSessionInbound A stricter value from .claude/settings.json or .claude/settings.local.json, on the accept < hold < refuse ladder 未標
useAutoModeDuringPlan false from any managed source, --settings, ~/.claude/settings.json, or .claude/settings.local.json 未標
syncClaudeAiSkills false from any managed source, --settings, ~/.claude/settings.json, or .claude/settings.local.json 未標
syncClaudeAiPlugins 同上一列 未標
maxEffortLevel A lower cap from any scope, including --settings v2.1.267

先講一個我不想替官方補的地方：這張表列了 12 個 key，官方沒說還有沒有別的「較嚴格者勝」的 key 沒列進來，我也沒掃過全部設定。所以我只能說「這張表列了 12 個」，不能說「只有 12 個」。

表裡 blockReads 與 blockWrites 兩列，站上工作目錄圍籬那篇已經寫過，這裡不重複。

同樣寫 false，認的層級剛好相反

整張表最容易踩的是第二欄的「from 哪裡」。

挑兩列對著看。syncClaudeAiSkills 認的是 managed、--settings、~/.claude/settings.json、.claude/settings.local.json 裡的 false，而且那一格後面特別註明「a false in .claude/settings.json is ignored」，也就是共用的專案檔裡的 false 不算。條目頁（Settings reference）的講法是「A repository can’t turn it off for you」，專案不能替你把它關掉。

remoteControlAtStartup 整個翻過來：認的是 .claude/settings.json 或 .claude/settings.local.json 裡的 false，備註是「a project or local true is ignored」。條目頁的原話是：repository 可以替它的 checkout 把自動連線關掉，但開不起來。

1
2
3
4
5
6
7
8
// 依表的寫法，放在不同的檔案，認不認得不一樣

// ~/.claude/settings.json：syncClaudeAiSkills 的 false 算數
{ "syncClaudeAiSkills": false }

// 共用的 .claude/settings.json：同一個 false 被忽略
// 但 remoteControlAtStartup 的 false 在這裡算數
{ "remoteControlAtStartup": false }

一個 key 是「專案不能替你關」，另一個是「專案只能關、不能開」。管理員要是憑印象把例外表當成同一條規則記，兩種都會記錯。

這篇全部來自官方文件。我只讀了文件，沒有實際設定跑過，上面的 JSON 是照表排出來的寫法，不是我跑出來的結果。

crossSessionInbound：用三段刻度比嚴不嚴

多數列是布林，crossSessionInbound 是三段。（maxEffortLevel 的上限也分高低，但它的規則是多個來源同時設時取最低的那個。）值有 "accept"（遞送給 Claude）、"hold"（「shows a notice for the message without delivering it」）、"refuse"（「drops the message」），官方定義 refuse 比 hold 嚴，hold 比 accept 嚴。

它的規則比表上那一行長。Claude Code 先讀 managed，再讀 --settings，再讀 user，取第一個找到的值。專案或本機的值只有在「比那個值更嚴」的時候才算數；三個可信來源都沒設值的話，專案或本機的 hold 或 refuse 照樣生效，取代每則訊息自己判斷的預設行為。

最有意思的是無法辨識的值。官方寫：只要 user、project、local 或 --settings 檔裡有個認不得的值，Claude Code 就 hold 收到的訊息，即使優先序更高的來源寫了 accept；別處設的 refuse 仍然有效。managed 裡有認不得的值，則是當成 refuse，直到管理員修好。官方還補了一句：v2.1.248 之前，Claude Code 會默默忽略認不得的值。

打錯字的後果，在這個 key 上是變嚴，不是變鬆。我猜這是刻意的，但官方沒講理由，所以只是我的猜測。

enableArtifact：關掉就沒有回頭路

另一個值得單拎的是 enableArtifact。條目頁寫「Every file can turn the tool off, and none can turn it back on」，每個檔案都能把這個工具關掉，沒有任何檔案能把它開回來。true 的意思等於沒設，因為它「never overrides a false from another file, from CLAUDE_CODE_DISABLE_ARTIFACT, or from your organization’s admin setting」。舊的 disableArtifact 已棄用，disableArtifact: true 仍然等於 enableArtifact: false，disableArtifact: false 被忽略。

syncClaudeAiSkills 也是同款：「Claude Code honors only false: true is the same as unset and doesn’t turn syncing on where it’s otherwise off」。

所以有一種寫法，看文件就知道會白費力氣：在某一層寫 true，想把別人關掉的功能硬開回來。enableArtifact 與 syncClaudeAiSkills 這兩個 key，true 沒有任何力量。

文件自己沒對齊的兩處

寫的時候撞到兩個官方文件互相不一致的地方，我不替官方裁決，只把兩邊都記下來。

第一處是錨點。條目頁的 remoteControlAtStartup 引用了 settings.md#security-keys-where-the-stricter-value-applies，而我讀到的設定頁，那張表的標題是「Exceptions to managed settings precedence」。錨點名稱和標題對不上，可能是改名後留下的失效連結，也可能我讀到的不是同一個版本，我沒有驗證，所以正文都只引用標題。

第二處是 autoMode.classifyAllShell。設定頁的例外表寫「true from ~/.claude/settings.json or --settings」，條目頁的 Scope 寫的是「User or managed」。表多了 --settings，條目頁多了 managed，兩邊字面不一樣。

順手把 autoMode.classifyAllShell 本身的行為記下來：預設情況下，auto mode 只會暫停可以跑任意程式碼的 allow 規則，像 Bash(*) 或 Bash(python *)；Bash(npm test) 這種規則的指令會跳過 classifier（除非那條規則帶有 per-command allowed domains）。設成 true 後，整個 session 的每一條 shell allow 規則都暫停，classifier 看得到每一個指令，需要 v2.1.193 以上。

我的讀法，以及會讓我改口的條件

依這張表推得：managed 設了 false，不代表使用者沒法再收緊，使用者在自己的層級寫更嚴的值，表上多數列都算數；反方向放寬，一個都不行。我會把這張表當成「managed 只管得到下限」來讀，想要鎖死的管理員，不能指望 managed 幫你擋掉使用者往嚴的方向走，也不該為此傷腦筋，因為那個方向本來就是你要的。

要是我讀反了，最可能反在兩個地方：一是官方補上一句這張表是完整清單，或反過來說明還有別的 key 遵守同樣規則；二是有人實際跑過，發現 remoteControlAtStartup 或 classifyAllShell 的行為和表上的字不同。第二種我沒辦法替你做，上面說過，我沒有跑。

自己對照的方法

照官方的診斷指令：在 Claude Code 裡跑 /status，看有哪些設定來源生效。官方也明說，這一行只確認讀了哪些檔案，不會告訴你每個 key 是哪個檔案給的；被拒絕的條目要用 claude doctor 列出來（出處：同一個設定頁的 Confirm what loaded）。

版本基準：npm 上 @anthropic-ai/claude-code 在 2026-11-09 的最新版是 2.1.319。表內版本需求最高的是 blockWrites 的 v2.1.314，所以這一版都夠用。

想把全局讀順，順序是：先讀五層優先序那篇弄懂一般規則，再讀工作目錄圍籬那篇看兩個典型例外，最後拿 /status 在自己機器上對一次。