[Claude Code #3] 權限管理總整理：/permissions 與模式循環

Claude Code 權限透過 allow、ask、deny 規則運作，並依 deny 優先的順序評估。本文整理 /permissions 用法、Bash 萬用字元語法、Shift+Tab 模式循環，以及設定檔優先順序。

SeokWoo Lee資深 iOS 軟體工程師發佈 2026年8月20日閱讀 5 分鐘

[Claude Code #3] 權限管理總整理：/permissions 與模式循環封面圖

使用 AI 程式設計工具時，會遇到一個兩難：每次都要求許可很麻煩，但全部放行又會讓人害怕git push或rm -rf。

Claude Code 透過權限規則解決這個平衡。有些指令靜默通過，有些一定要詢問，有些則直接封鎖。

上一集Claude Code 第 2 篇介紹的計畫模式，也是建立在這套權限系統上運作。本篇整理完整全貌。

基本行為：哪些操作會詢問？

依據官方權限文件，不同工具類型有不同的預設規則。

讀取檔案或搜尋等唯讀工具，在工作目錄內可免核准執行。

Shell 指令原則上需要核准。不過，內建的唯讀指令集合例外。

修改檔案時一定會詢問。即使選擇「不要再詢問」，工作階段結束後也會重設。相對地，Shell 指令的「不要再詢問」會儲存為每個儲存庫的規則，並延續到下一個工作階段。

使用 /permissions 檢視規則

在工作階段中輸入/permissions，即可開啟目前套用中的規則清單，也會顯示每條規則來自哪個 settings.json。

規則分為三種。

allow：允許執行而不詢問
ask：每次嘗試時都要求確認
deny：直接封鎖執行

評估順序就是一切

規則重疊時會怎樣？順序是 deny → ask → allow，先匹配到的規則優先。

重點是，具體程度無法改變順序。將Bash(aws *)加入 deny 後，即使在 allow 中寫得再具體的Bash(aws s3 ls)也會被封鎖。

deny 規則不允許例外。「全部封鎖 aws，但只允許查詢 s3」這類設定無法成立，因此必須把規則拆得更精確。

展示 Claude Code 權限規則 deny、ask、allow 評估順序的流程圖 — 這就是規則評估順序：先檢查 deny，先匹配到的規則優先。

另外，若在 deny 中只填工具名稱而不加括號，例如Bash，該工具會從 Claude 的上下文中完全消失。像Bash(rm *)這種縮小範圍的規則，會保留工具，只封鎖特定呼叫。

快速瀏覽規則語法

規則格式為도구或도구(지정자)。Bash 規則支援*萬用字元，位置也不受限制。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(* --version)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

若指令結尾的星號前有空格（Bash(ls *)），就會遵守單字邊界。ls -la會匹配，但lsof不會。沒有空格的Bash(ls*)則連lsof也會匹配。

像git status && npm test這類複合指令，所有子指令都必須符合規則才能通過。即使允許Bash(safe-cmd *)，safe-cmd && other-cmd仍然無法通過。

檔案路徑規則只檢查Read(경로)與Edit(경로)，並使用 gitignore 模式語法。寫成Write(docs/**)會被忽略，因此要寫成Edit(docs/**)。

此外，Read deny 也會一併封鎖相同路徑的編輯與寫入。上例只用一條Read(./.env)，就能同時阻擋讀取與修改。

權限模式：使用 Shift+Tab 循環

如果說規則是精準瞄準，權限模式就是整個工作階段的基調。

每按一次 Shift+Tab，就會依序循環 default（手動核准）→ acceptEdits（自動核准編輯）→ plan（計畫模式）。計畫模式已在上一集介紹。

根據官方權限模式文件，符合帳戶與方案條件時，auto 模式也會加入循環。這種模式由分類器模型只攔截危險行為，其餘操作不再詢問。即使如此，明確的 ask 規則仍會強制顯示提示。

補充說明，根據官方公告依據，自 2026 年 8 月 14 日起，Pro、Max、Team 方案的新工作階段預設使用 auto 模式。

設定檔之間的優先順序

規則可以分散在多層 settings.json 中，包括個人全域設定（~/.claude/）、專案設定（.claude/settings.json）、僅限本機的設定，以及組織管理設定。

官方設定優先順序文件說明的原則很簡單：只要任何一層匹配 deny，其他層的 allow 都無法推翻它。

專案允許的操作可以由個人設定中的 deny 封鎖，反過來也一樣。組織管理設定中的 deny，即使使用命令列旗標也無法解除。

規則由工具遵守，而不是由模型遵守

最後補充一個容易誤解的地方。

在 CLAUDE.md 寫下「不要 git push」是請求，不是強制。如果模型忘記指示或判斷錯誤，就可能被繞過。

權限規則則不同。Claude Code 用戶端不論模型如何判斷，都會機械式執行規則。一定要封鎖的操作，請放進 deny 規則，而不是只寫在 CLAUDE.md。

以 RULES NOT REQUESTS 字樣、便利貼上的請求與上鎖鐵門形成對比的插圖 — 請求放在 CLAUDE.md，強制規則放在 deny 中。

總結

權限系統的骨架有三部分：allow・ask・deny 規則、deny → ask → allow 的評估順序，以及決定工作階段基調的權限模式。

基本策略是將常用且安全的指令加入 allow，以減少提示疲勞；對危險指令則用 deny 徹底封鎖。

下一篇將介紹用來延續與分叉對話的/resume、/branch、/fork三件組。

來源與確認標準

Claude Code 官方文件 — Configure permissions（Anthropic，確認於 2026-08-13）
Claude Code 官方文件 — Choose a permission mode（Anthropic，確認於 2026-08-13）