讓 Claude Code 自主到什麼程度：permission modes、auto mode 分類器與 allow/deny rules

TL;DR Claude Code 共有六個 permission mode，日常主要在 Manual、Accept edits、Plan、Auto 四個之間用 Shift+Tab 切換；Pro／Max／Team 的互動終端機與 VS Code session 在條件符合時預設進入 auto mode，由背景分類模型審查多數動作，預設攔下 force push、`curl | bash`、production deploy 等風險操作。本文講四個模式的取捨、permission rules 的寫法，以及組織層的 trust config。

#claude-code #permissions #auto-mode

四個模式構成的光譜
Auto mode 怎麼運作
用 permission rules 微調
組織層治理
怎麼選
參考資料
更新紀錄

系列: Claude Code 深入介紹 (7 / 38)

Claude Code settings.json 設定大全：五層 scope、合併規則與常用欄位 Claude Code Permission Modes 全解析：從預設到 Auto Mode 的五種權限模式

🌏 English version

上一篇系列入口提到，checkpoints 和 permission modes 是 Claude Code 的兩道安全防線。這篇把第二道展開：它解決的是一個兩難——每次動作都問你，長任務會被提示打斷到失去耐心；完全不問，你又等於把檔案系統和終端機整台交出去。Permission modes 就是這兩個極端之間的刻度。

四個模式構成的光譜

按 Shift+Tab 會在模式間循環切換，狀態列顯示目前所在位置。官方文件列出六個值，但日常會碰到的主要是四個：

模式（config 值）	不問你就先做什麼	適合
Manual（`default`）	只有讀取	敏感工作、不熟的 codebase
Accept edits（`acceptEdits`）	讀取、改檔案、常見檔案指令（`mkdir`、`touch`、`mv`、`cp`、`sed` 等），限工作目錄內	一邊跑一邊用 git diff 事後審
Plan（`plan`）	讀取、探索；auto mode 可用時可跑分類器核准的指令，編輯被封鎖直到你核准計畫	動手前先看懂現場
Auto（`auto`）	幾乎所有事，但每個動作先過一道背景分類器	長任務、減少提示疲勞

另外兩個是邊界案例：dontAsk 不出現在 Shift+Tab 循環裡，只放行預先核准的工具，給鎖死 allowlist 的 CI 用；bypassPermissions 則跳過日常權限提示，但仍有 ask rule、需要使用者互動的工具、critical path 刪除、跨 session 傳訊保護等例外——那是另一篇文章的主題，結尾會談。

幾個細節值得知道：Manual 在 UI 上叫 Manual，但 config 值是 default，CLI 也接受 manual 別名；auto 從專案的 .claude/settings.json 設定不生效，要放在 ~/.claude/settings.json；寫入 protected paths（如 .git、.claude）通常不會被自動核准，例外是 bypassPermissions 和某些可切到 bypass 的 plan-mode session。

Auto mode 怎麼運作

Auto mode 的核心不是「不檢查」，而是把檢查者從你換成一個獨立的分類器模型：多數 tool call 會先送審，攔下超出任務範圍、指向陌生基礎設施、或疑似被 Claude 讀到的惡意內容驅動的操作；少數互動工具、明確 ask 規則和其他安全檢查則走各自的提示或拒絕路徑。在 Pro／Max／Team 方案，它是 v2.1.228 起（Windows 為 v2.1.233）互動 session 的內建起始模式；首次以 auto mode 開 session 時會顯示通知並連到說明頁。

分類器有一份很長的預設封鎖清單，包括：

下載即執行（curl | bash）、把敏感資料送到外部端點
production 部署與 migration、雲端儲存的大量刪除、授予 IAM 或 repo 權限
force push、git reset --hard 這類丟棄未 commit 變更的操作、terraform destroy
commit 或 push 會在執行時把 secret 送出 repo 的變更

預設放行的則包括：工作目錄內的檔案操作、安裝 lockfile 或 manifest 宣告的依賴、讀 .env 並把憑證送給對應 API、唯讀 HTTP 請求，以及 push 到目前工作 repo 的任何分支。想看完整清單可以跑 claude auto-mode defaults。

分類器內部有四層優先序：hard_deny 無條件擋（使用者意圖和例外規則都不適用）→ soft_deny 可被明確的使用者意圖覆蓋（「清理一下 repo」不算授權 force push，「force-push 這個分支」才算）→ allow 規則作為 soft block 的例外 → 其餘放行。而 permissions.deny 又在分類器之前評估——它在所有模式下都生效，包括 bypassPermissions，是最硬的一道。

官方文件對此模式的警告重點是：auto mode 會減少提示，但 “does not guarantee safety”。它適合你信任大方向的任務，不是敏感操作的審查替代品。

用 permission rules 微調

Mode 決定基線，permission rules 疊在上面處理個案。規則格式是 Tool 或 Tool(specifier)，分成 allow（免問）、ask（強制問）、deny（禁止）三種，評估順序固定為 deny → ask → allow，規則再具體也改不了這個順序：

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "ask": ["Bash(gh pr create *)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "WebFetch(domain:evil.example)"]
  }
}

幾個寫法要點：* 放在子命令之後——Bash(git log *) 只放行 git log 系列，Bash(git *) 等於放行所有 git 操作；Read 和 Edit 規則用 gitignore 語法，Read(./.env) 一條就能連帶擋掉同路徑的編輯和新建檔；deny 一條裸工具名（如 "WebFetch"）會把工具整個從 Claude 的 context 移除。特別重要的是 ask 規則連 auto mode 都會強制跳出提示——想要「其他全自動、push 前一定要過人」就是靠它。

組織層治理

個人偏好之上還有第四層：managed settings。管理員可以在這層設定 permissions.defaultMode 統一起始模式，用 permissions.disableBypassPermissionsMode 或 permissions.disableAutoMode 設成 "disable" 直接移除對應模式——被移除的 auto 連 Shift+Tab 都不再出現，--permission-mode auto 起動的 session 會退回 Manual。

Auto mode 自己還有一套 trust config，就是 autoMode 設定區塊。核心概念是 autoMode.environment：預設分類器只信任工作目錄和 repo 既有的 remotes，推到公司其他 repo、寫入團隊的 cloud bucket 都會被擋，直到你用自然語言條列哪些 repos、buckets、domains 是可信的。專案慣例和行為邊界則先寫在 Claude 已載入的 CLAUDE.md，因為分類器也會讀同一份記憶內容。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted internal domains: *.corp.example.com"
    ]
  }
}

安全設計上有一點很聰明：分類器不讀專案層的 .claude/settings.json 或 .claude/settings.local.json 裡的 autoMode，只接受 user settings、managed settings 和 --settings 旗標三個來源——因為專案目錄裡的檔案可能來自別人 check-in 的 repo，不能讓 repo 替自己擴大信任範圍。個人可以追加條目，但刪不掉 managed settings 給的條目；要絕對不可逾越的邊界，還是用前一節的 permissions.deny 放 managed settings。

怎麼選

我的實際用法：不熟的 codebase 先 Plan，看懂了切 Accept edits 邊跑邊審 diff；信任的專案和長任務直接 Auto，配一條 Bash(git push *) 的 ask rule 當人工關卡；碰到金流、資料庫 migration 這類出了事 rewind 也救不回來的操作，回到 Manual。Auto mode 的分類器大幅降低了自主的風險，但它降低的是「意外」，不是「你本來就不該放手的那件事」。

順帶一提：如果你心裡想的是「何必分級，直接全關最快」，那正是 --dangerously-skip-permissions 的世界。想走那條路之前，先看繞過所有權限提示的代價分析（English）——那篇講的是這條光譜最右端的成本。

參考資料

Choose a permission mode — Claude Code Docs — 六個模式的行為對照、Shift+Tab 切換細節、auto mode 分類器的預設封鎖與放行清單
Configure permissions — Claude Code Docs — allow/ask/deny rule 語法、萬用字元比對規則、評估順序
Configure auto mode — Claude Code Docs — autoMode.environment trust 設定、hard/soft deny 分層、managed settings 的組織控制
Settings — Claude Code Docs — settings scope、managed settings 與 permissions.defaultMode 等設定來源

更新紀錄

2026-08-26：初版，依 2026-08 官方文件撰寫（auto mode 為 Pro/Max/Team 預設起始模式，Manual label 需 v2.1.200+）。
2026-08-29：補上 bypassPermissions 例外、protected paths 例外、plan mode 指令行為、settings key 前綴與 CLAUDE.md 對 auto mode 分類器的約束。