11 · 該給 AI 多少許可權

許可權不是讓 Claude Code 變弱，而是讓它在正確的地方自動做事，在危險的地方停下來問你。真正的問題不是“給不給許可權”，而是“什麼操作值得信任，什麼操作必須留給人判斷”。——翔宇

1. 從一個 git push 開始

你讓 Claude Code 修一個小 bug。

它讀了幾份檔案，改了一行邏輯，跑了測試，最後準備執行：

git push origin main

這時彈出視窗出現了。

很多新手第一反應是煩：剛才都讓你修了，為什麼還問？

但換一個角度看，這個彈出視窗正是許可權系統最有價值的地方。讀檔案不會改變世界；改檔案能回復；跑測試通常安全；直接推到遠端分支，影響就變大了。

Claude Code 官方 Permission modes 文件說得很直接：當 Claude 想編輯檔案、執行 shell 命令或發起網路請求時，會暫停並請求批准；permission mode 決定這種暫停出現得有多頻繁。

所以許可權不是“限制 AI”，而是把動作按風險分層。

flowchart LR
    Read["讀檔案<br/>低風險"]
    Edit["改檔案<br/>可審查"]
    Bash["跑命令<br/>看命令"]
    Network["聯網 / MCP<br/>看目標"]
    Remote["推送 / 部署 / 刪除<br/>高影響"]

    Read --> Edit --> Bash --> Network --> Remote

    style Read fill:#dcfce7,stroke:#22c55e,stroke-width:2px
    style Edit fill:#e0f2fe,stroke:#0284c7,stroke-width:2px
    style Bash fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style Network fill:#ffedd5,stroke:#f97316,stroke-width:2px
    style Remote fill:#fee2e2,stroke:#ef4444,stroke-width:2px

2. 先分清三層邊界

很多人把 Claude Code 的安全能力混成一團：許可權、沙盒、Hooks、CLAUDE.md 都往一個籃子裡放。

先拆開：

一句話：

• CLAUDE.md 是說明書。
• Hooks 是檢查點。
• Permissions 是訪問邊界。
• Sandbox 是作業系統圍欄。

3. 六種許可權模式，不是越松越好

Claude Code 當前有六種 permission mode。舊教程裡常說“五種”，現在已經不夠了，因為官方把 auto 模式單獨放進了許可權模式體系。

最容易誤解的是這三個：

acceptEdits 不是全自動。

它主要是自動接受檔案編輯和一些常見檔案系統命令，比如 mkdir、touch、mv、cp、sed。但作用範圍仍然受 working directory、additionalDirectories 和 protected paths 約束。

plan 不是“不能看程式碼”。

它正適合看程式碼。Claude Code 可以先讀檔案、跑探索命令、寫計劃，然後讓你選擇怎麼執行。多檔案改動、陌生儲存庫、生產風險高的任務，先用 plan 往往更省時間。

bypassPermissions 不是高手模式。

它跳過許可權提示和安全檢查。官方明確建議只在隔離環境裡用，比如容器、VM、無網際網路訪問的 dev container。不要在你的日常開發機上把它當省事開關。

切換方式也別記錯：

claude --permission-mode plan
claude --permission-mode acceptEdits
claude --permission-mode dontAsk
claude --permission-mode bypassPermissions

CLI 裡 Shift+Tab 預設迴圈 default → acceptEdits → plan。dontAsk 不在迴圈裡；auto 和 bypassPermissions 只有滿足條件或用啟用引數啟動後才會出現。

4. auto 模式：減少彈出視窗，不等於沒有風險

auto 是這篇必須單獨講的新模式。

它的目標不是"全部放開"，而是讓 Claude Code 少問你，同時讓後臺 classifier（安全分類器）檢查動作是不是超出了你的請求、是不是碰了不認識的基礎設施、是不是像被惡意內容帶偏。

classifier 怎麼"判"：底層是 Anthropic 訓練的一個專用安全分類模型——每次 Claude 決定動手前，把"動作 + 當前上下文"送給 classifier 二次判斷。它不是規則引擎（寫死哪些命令禁止），是模型（看動作語義和當前任務的相關性）。為什麼這樣設計：規則引擎覆蓋不了"組合危險"——rm -rf + 當前在 / 是危險，但在臨時目錄是正常；規則引擎只看命令字串兩者一樣，模型能看上下文區分。代價：classifier 本身要花推理時間 + token——這是 auto 模式跟 bypassPermissions 在體感上"似乎都沒彈出視窗" 但底層完全不同的原因。

官方當前文件列了幾個關鍵邊界：

官方當前文件列了幾個關鍵邊界：

• 狀態：research preview，不保證絕對安全。
• 賬號：不是所有計劃都可用，Pro 不可用。
• 模型 / 供應商：有模型和 Anthropic API 條件限制。
• 預設信任：工作目錄、本儲存庫 remote、只讀 HTTP、宣告依賴安裝等更容易放行。
• 預設阻止：curl | bash、外發敏感資料、生產部署、雲端儲存批次刪除、IAM / repo 許可權變更、force push 等。
• 會話邊界：你在對話裡說“不要 push”，classifier 會把它當阻止訊號。

這就是 auto 跟 bypassPermissions 的核心差別：

5. 細粒度規則：Allow / Ask / Deny

許可權模式是“整體姿態”，規則才是“具體邊界”。

官方 Permissions 文件把規則分成三類：

順序也很重要：deny → ask → allow。第一條匹配的規則生效，所以拒絕永遠優先。

一個新手可直接照著改的配置：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git diff *)",
      "WebFetch(domain:docs.anthropic.com)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)"
    ]
  }
}

這份配置表達的是：

• 測試、lint、看 diff，可以自動做。
• push、publish，必須問我。
• 讀 .env、讀 secrets、跑 rm -rf，直接拒絕。

新手最常見的兩類配置失控：

1. 嫌彈出視窗煩直接 bypassPermissions：第一週用 Claude Code 覺得彈出視窗煩，改預設模式為 bypassPermissions——結果某天 Claude 在 ~/Documents 裡跑了 rm -rf node_modules 但目錄算錯位置，刪了真實資料。修復：日常 acceptEdits 而不是 bypassPermissions——前者編輯自動透過但 Bash / 網路仍受 ask 約束，後者是"全部跳過"。
2. 寫 Bash(*) 當 allow：嫌每次確認煩，寫 allow: ["Bash(*)"] 把所有 shell 命令都透過——等於 sudo all 給 Claude，連 rm -rf 都不彈。修復：allow 只列頻繁 + 安全的具體命令（Bash(npm test) / Bash(git diff *) / Bash(ls *)），頻繁但有風險的（git push）放 ask，永遠不該的（rm -rf）放 deny。

6. Protected paths：有些地方預設更敏感

Claude Code 對一些路徑有特殊保護，因為這些路徑一旦被改壞，會影響儲存庫狀態、編輯器配置或 Claude 自己的配置。

典型 protected paths 包括：

典型 protected paths 包括：

• 儲存庫狀態：.git、.gitmodules。
• 編輯器 / Git hooks：.vscode、.idea、.husky。
• Claude 配置：.claude、.claude.json、.mcp.json。
• Shell 啟動檔案：.bashrc、.zshrc、.profile。
• 搜尋配置：.ripgreprc。

這裡有一個容易過時的細節：官方當前說明是，除了 bypassPermissions 之外，protected paths 都不會被自動批准；在 default、acceptEdits、plan 裡會詢問，在 auto 裡走 classifier，在 dontAsk 裡拒絕。

而 bypassPermissions 從 v2.1.126 起也會放行 protected paths。只有類似 rm -rf /、rm -rf ~ 這種指向根目錄或 home 目錄的刪除，仍然會觸發最後的斷路保護。

7. Sandbox：許可權之外再加一圈圍欄

許可權規則是在 Claude Code 層面判斷“這個工具呼叫可不可以發生”。沙盒是在作業系統層面限制“這個 Bash 程序和它的子程序能碰到哪裡”。

官方 Sandboxing 文件的關鍵點是：

兩者的邊界：

• 作用物件：許可權規則覆蓋 Bash、Read、Edit、WebFetch、MCP 等所有工具；Sandbox 主要覆蓋 Bash 和它啟動的子程序。
• 執行層級：許可權規則在 Claude Code 應用層；Sandbox 在作業系統層。
• 檔案邊界：許可權規則用 Read / Edit / deny 等表達；Sandbox 限制程序讀寫路徑。
• 網路邊界：許可權規則裡 WebFetch 管 domain；Sandbox 透過代理和域名 allow / deny 限制網路。
• 典型價值：許可權規則不讓 Claude 嘗試危險操作；Sandbox 讓命令即使執行也不能越界。

在 macOS 上，沙盒使用 Seatbelt；Linux 和 WSL2 使用 bubblewrap。它不是 Claude 的“自覺”，而是系統級限制。

你可以在 Claude Code 裡用：

/sandbox

開啟沙盒選單。預設思路是：當前工作目錄內可以更自由，越出邊界就提示或阻止。

8. 成本也是一種邊界

很多人講許可權只講安全，不講成本。

但對自動化 Agent 來說，成本邊界和安全邊界是一類問題：都是防止系統在無人盯著的時候跑出你能承受的範圍。

官方 Costs 文件裡，現在推薦用 /usage 看當前會話的 token 和估算成本。舊稿裡常見的 /cost 說法不適合繼續寫進新教程。

日常你記這三類就夠：

日常你記這三類就夠：

• 看當前用量：/usage。
• 降低思考成本：/effort、/model、/config、MAX_THINKING_TOKENS。
• SDK 自動化限額：max_budget_usd / maxBudgetUsd。

注意邊界：

• /usage 裡的金額是本地估算，不一定等於最終賬單。
• Pro / Max 訂閱使用者看到的是訂閱用量，不等同於 API 賬單。
• max_budget_usd / maxBudgetUsd 是 Agent SDK 裡的預算引數，不要把它誤寫成所有 CLI 場景都有的通用開關。

9. 新手該怎麼選

不用一開始就追求“最安全”或“最自動”。按專案風險選。

flowchart TD
    Start["這次任務風險高嗎？"]
    Sensitive["會碰生產、金鑰、部署、遠端分支？"]
    Multi["會改很多檔案或你不熟悉儲存庫？"]
    Review["你願意事後看 diff 嗎？"]
    CI["是不是無人值守指令碼 / CI？"]
    Isolated["環境壞了也無所謂？"]

    Plan["用 plan 先審方案"]
    Default["用 default"]
    Accept["用 acceptEdits + 看 diff"]
    DontAsk["用 dontAsk + allowlist"]
    Bypass["隔離環境才用 bypassPermissions"]

    Start --> Sensitive
    Sensitive -->|是| Plan
    Sensitive -->|否| Multi
    Multi -->|是| Plan
    Multi -->|否| Review
    Review -->|是| Accept
    Review -->|否| Default
    CI --> DontAsk
    Isolated --> Bypass

    style Plan fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style Bypass fill:#fee2e2,stroke:#ef4444,stroke-width:2px

更具體一點：

更具體一點：

• 第一次用 Claude Code：default。
• 熟悉專案、頻繁小改：acceptEdits。
• 多檔案重構 / 陌生儲存庫：plan 開始，審完再執行。
• 想減少彈出視窗但還要安全檢查：符合條件時用 auto。
• CI / 自動指令碼：dontAsk + 明確 allowlist。
• 一次性容器 / VM：必要時才用 bypassPermissions。

10. 和 Hooks 放在一起看

第 10 篇講 Hooks，這一篇講 Permissions。兩者經常一起用，但職責不同。

職責邊界可以這樣記：

• “能不能執行 git push？”：Permission。
• “每次寫 .env 前必須攔住並解釋原因”：Hook。
• “如果測試輸出太長，自動只保留失敗資訊”：Hook。
• “任何 MCP 瀏覽器工具都不許點發布按鈕”：Permission + Hook。
• “只允許讀取 docs，不允許讀 secrets”：Permission。

官方 Permissions 文件也說明了這個關係：PreToolUse hook 會在許可權提示前執行，hook 可以 deny、強制詢問或跳過提示；但 hook 決策不能繞過 deny / ask 規則。匹配到 deny 的規則仍然會阻止呼叫。

flowchart LR
    Action["Claude 準備呼叫工具"]
    Hook["PreToolUse Hook<br/>執行自定義檢查"]
    Rules["Permission Rules<br/>Deny / Ask / Allow"]
    Mode["Permission Mode<br/>default / auto / ..."]
    Run["工具執行"]
    Block["阻止或詢問"]

    Action --> Hook --> Rules --> Mode
    Hook -->|blocking| Block
    Rules -->|deny / ask| Block
    Mode -->|允許| Run

    style Hook fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style Rules fill:#e0f2fe,stroke:#0284c7,stroke-width:2px
    style Block fill:#fee2e2,stroke:#ef4444,stroke-width:2px

11. 本章自檢

試著用自己的話回答：

1. 為什麼許可權彈出視窗不是"AI 不夠強"，而是"動作後果需要分層"？對應 §1-§2。
2. acceptEdits、auto、bypassPermissions 的差別是什麼？對應 §3-§4。
3. 為什麼 deny 規則應該比 allow 規則更窄但更堅決？對應 §5。
4. Sandbox 為什麼只能補強 Bash 邊界，不能替代所有 Permission？對應 §7。
5. 動手題 ⭐：在你最常用的專案根 .claude/settings.json 寫 3 條規則——1 條 allow（寫一條你真的常用的命令，比如 Bash(pnpm test)）、1 條 ask（寫一條頻繁但有風險的命令，比如 Bash(git push *)）、1 條 deny（寫一條永遠不該自動執行的，比如 Read(./.env)）。每條解釋為什麼放這一檔。這一題做完你才會真懂"分層"不是道理，是配置檔案。對應 §5 + §9。

官方資料

• Configure permissions
• Choose a permission mode
• Sandboxing

接下來去哪

如果只記一個判斷：許可權不是越松越先進，也不是越嚴越安全；好的許可權配置，是讓低風險動作自動發生，讓高影響動作必須經過你。