權限模型與安全性

你將學到什麼

Claude Code 的安全性不是單一開關，而是以下控制的組合：

1. 設定 session 基準的權限模式
2. 針對特定工具呼叫的 allow、ask、deny 規則
3. 受保護路徑與組織政策
4. 可選的 Bash 與子程序 OS 層 sandbox
5. 在工具執行前後進行確定性檢查的 hooks

本堂課著重於如何有意識地選擇控制，尤其是 Auto 模式與 bypass permissions 的差異。

權限模式

UI 標籤	設定值	不需例行核准即可執行	適合情境
Manual	default（manual 別名）	讀取	敏感或不熟悉的工作
Edit automatically	acceptEdits	讀取、檔案編輯、常見檔案系統命令	經審查的本機迭代
Plan	plan	讀取與唯讀探索	實作前先設計
Auto	auto	通過背景安全檢查的動作	方向可信、減少中斷
Don’t ask	dontAsk	預先核准及內建唯讀動作	鎖定範圍的 CI 與 scripts
Bypass permissions	bypassPermissions	幾乎所有動作	僅限隔離的 containers 與 VMs

Manual / default

Manual 是目前 UI 標籤；default 仍是 settings、hooks、SDK 整合使用的設定值。v2.1.200 之後，CLI 也接受 manual 別名。

在工作目錄內，讀取通常不需詢問；檔案編輯和非唯讀 Bash 命令通常會提示。這是最安全的通用起點，因為使用者可以逐一審查副作用。

claude --permission-mode default
# v2.1.200+
claude --permission-mode manual

Plan / plan

Plan 模式用於唯讀調查與設計。Claude 可以讀取檔案、使用內建唯讀 shell 命令，但不會編輯原始碼。非唯讀 shell 命令即使在規劃中仍會提示。

claude --permission-mode plan

Plan 模式並不表示「每次讀取都要核准」。它在實作前建立 checkpoint：你可以審查方案、繼續修改，或核准後選擇執行階段使用的模式。

Auto / auto

Auto 模式移除例行權限提示，但保留背景安全檢查。獨立分類器會評估尚未由明確規則或安全本機行為決定的動作。deny 與 ask 規則仍然有效；若動作超出需求、指向不熟悉的基礎設施，或疑似受到惡意內容影響，分類器可以封鎖。

claude --permission-mode auto

Auto 模式能減少提示疲勞，但不保證安全，也不能取代敏感操作的審查。可用性取決於帳號、模型、provider 與組織設定。

Don’t ask / dontAsk

dontAsk 不會等待權限輸入。原本需要詢問的呼叫會直接拒絕；它只執行預先核准的動作、內建唯讀 Bash 命令，以及適用 hook 所核准的呼叫。

claude --permission-mode dontAsk

適合無法等待人工輸入、且已預先定義可用範圍的 CI 或 scripts。

Bypass permissions / bypassPermissions

Bypass 模式跳過一般權限提示與安全檢查。只能在隔離的 container 或 VM 中使用，而且環境內不應有重要憑證，也不能傷害 host 或 production systems。

claude --permission-mode bypassPermissions
# 等價的舊式旗標：
claude --dangerously-skip-permissions

dangerous 旗標不是 Auto 模式。少數 circuit breakers 與外部要求的 consent 提示仍可能出現，但 bypass 模式不提供一般性的 prompt injection 或意外動作保護。

規則：先 Deny，再 Ask，最後 Allow

規則放在 permissions.allow、permissions.ask、permissions.deny：

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Read(/docs/**)",
      "WebFetch(domain:docs.example.com)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(~/.ssh/**)",
      "WebFetch(domain:paste.example)"
    ]
  }
}

規則使用 Tool 或 Tool(specifier) 語法，並依 deny → ask → allow 判定；更精確的規則不會改變這個順序。若已 deny Bash(aws *)，較窄的 Bash(aws s3 ls) allow 也無法穿透。

用 /permissions 查看與編輯有效規則。allow pattern 應保持精確；Bash(npm test *) 比開放整個 Bash 更容易推理。

權限與 Sandbox 是不同控制

權限決定 Claude Code 能否呼叫某個工具。Sandbox 啟用後，會在 OS 層限制 Bash 命令與其子程序可存取的檔案系統和網路。

模型提出 Bash 命令
        ↓
權限模式 + 規則 + hooks
        ↓ 已允許
可選的 OS sandbox 邊界
        ↓
作業系統執行或封鎖副作用

Sandbox 不會自動與任何權限模式綁定，必須另外設定。也不要假設一條權限規則就能阻止任意 Python 或 Node 子程序讀取檔案；若 threat model 包含不受信任程式碼或 prompt injection，應同時使用兩層控制。

即使 sandbox 自動允許命令，明確 deny 規則仍有效。除 bypass 外，受保護路徑在各模式中也會受到額外保護；bypass 會略過大多數受保護路徑檢查。

Hooks 與組織政策

PreToolUse hook 可以檢查即將執行的動作，並在執行前封鎖。Hooks 適合實作確定性要求，例如拒絕 production target 或強制使用核准的命令 wrapper。它們補充權限規則，但不能覆寫已符合的 deny 或 ask 規則。

組織可發布使用者和專案都無法覆寫的 managed settings。因為任何設定層級的 deny 都優先，專案 allow 無法覆寫組織 deny。

如何選擇模式

需要理解後才能編輯？             → plan
想逐一審查副作用？               → default / Manual
信任本機編輯，但要審查命令？      → acceptEdits
想減少提示並保留安全檢查？        → auto
需要 allowlist 的非互動 CI？      → dontAsk
完全隔離、可丟棄的環境？          → bypassPermissions

若需要長期有效的人類 checkpoint，請設定 ask 或 deny 規則。像「不要 push」這類對話指示能協助 Auto 分類器，但 context compaction 後可能遺失；權限規則才是較強的邊界。

安全檢查清單

• 從能讓工作繼續的最低權限模式開始。
• 不要把 secrets 與 production credentials 放進自主執行環境。
• 使用精確 allow patterns，並為發布或部署加入 ask。
• 對絕不能觸碰的路徑與命令加入 deny。
• 執行不受信任程式碼時啟用 sandbox。
• 把 MCP servers、抓取內容與 repository instructions 視為可能的 prompt-injection 來源。
• 驗證實際副作用，例如 tests、diff、deployment state，而不只相信 Claude 宣稱任務已完成。

官方依據

• 選擇權限模式
• 設定權限
• Sandboxing
• Hooks 參考

最後驗證：2026-07-20。