---
title: "11 · 該給 AI 多少許可權"
description: "Claude Code 許可權不是安全感按鈕，而是把讀、寫、執行命令、聯網和成本拆成不同信任層級。學會用六種模式、Allow/Ask/Deny、沙盒和預算邊界。"
canonical: "https://xiangyugongzuoliu.com/tag/claude-code"
verifiedAt: "2026-05-08"
---

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

> [!NOTE]
> **這一篇用 15 分鐘換什麼**：第 10 篇講 Hooks，讓 Claude Code 到點自動檢查。第 11 篇講 Permissions：當 Claude Code 想讀檔案、改檔案、跑命令、聯網、呼叫 MCP 工具時，哪些可以自動放行，哪些必須詢問，哪些應該永遠拒絕。

## 1. 從一個 `git push` 開始

你讓 Claude Code 修一個小 bug。

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

```bash
git push origin main
```

這時彈出視窗出現了。

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

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

> [!IMPORTANT]
> **第一性原理**：許可權系統不是在判斷 Claude Code 聰不聰明，而是在判斷某個動作一旦發生，代價由誰承擔。

Claude Code 官方 [Permission modes](https://code.claude.com/docs/en/permission-modes) 文件說得很直接：當 Claude 想編輯檔案、執行 shell 命令或發起網路請求時，會暫停並請求批准；permission mode 決定這種暫停出現得有多頻繁。

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

```mermaid
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` | 讓 Claude 知道你希望怎麼做 | “這個專案用 pnpm，不用 npm” |
| Hooks | 某個事件點必須自動檢查 | “寫 `.env` 前攔住” |
| Permissions | 某個工具呼叫能不能發生 | “能不能執行 `git push`？” |
| Sandbox | Bash 程序能碰到哪裡 | “命令就算跑了，能不能讀 SSH key？” |

一句話：

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

> [!TIP]
> **新手判斷法**：如果問題是“Claude 應該記住什麼”，寫 `CLAUDE.md`；如果問題是“到點必須查什麼”，用 Hook；如果問題是“這個工具能不能用”，配 Permission；如果問題是“命令即使跑起來也不能越界”，開 Sandbox。

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

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

| 模式 | 不問你就能做什麼 | 適合什麼 |
|------|------|------|
| `default` | 讀檔案 | 新手上手、敏感專案 |
| `acceptEdits` | 讀檔案、改工作目錄內檔案、常見檔案命令 | 你願意事後看 diff |
| `plan` | 讀檔案、探索、提出方案，不直接改原始碼 | 多檔案任務、先審方案 |
| `auto` | 大多數操作自動執行，但經過後臺安全分類器 | 長任務、減少確認疲勞 |
| `dontAsk` | 只允許預先批准的工具和只讀 Bash | CI、指令碼、鎖死環境 |
| `bypassPermissions` | 基本全部放行 | 只限隔離容器 / VM |

最容易誤解的是這三個：

**`acceptEdits` 不是全自動。**

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

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

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

**`bypassPermissions` 不是高手模式。**

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

> [!CAUTION]
> **最危險的誤解**：`bypassPermissions` 不是“我很信任 Claude”。它是“這個環境壞了也無所謂”。如果環境不是一次性的，就不要把它當預設工作模式。

切換方式也別記錯：

```bash
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` 的核心差別：

| 模式 | 表面體驗 | 底層含義 |
|------|------|------|
| `auto` | 少彈出視窗 | 仍有後臺安全判斷 |
| `bypassPermissions` | 不彈出視窗 | 跳過許可權層和安全檢查 |

> [!IMPORTANT]
> **一句話理解**：想減少彈出視窗，優先考慮 `auto` 或 sandbox；想完全跳過檢查，只有一次性隔離環境才考慮 `bypassPermissions`。

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

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

官方 [Permissions](https://code.claude.com/docs/en/permissions) 文件把規則分成三類：

| 規則 | 含義 | 例子 |
|------|------|------|
| `allow` | 自動允許，不彈出視窗 | `Bash(npm test)` |
| `ask` | 每次詢問 | `Bash(git push *)` |
| `deny` | 直接拒絕 | `Read(./.env)` |

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

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

```json
{
  "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`，直接拒絕。

> [!WARNING]
> **不要寫過寬的 allow**：`Bash(*)` 看起來省事，實際是在把 shell 的風險整體交出去。能寫窄，就寫窄到具體命令。

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

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 目錄的刪除，仍然會觸發最後的斷路保護。

> [!CAUTION]
> **這就是為什麼舊經驗不可靠**：許可權細節會隨版本變。寫教程時不能只靠印象，必須按當前官方文件核對。

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

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

官方 [Sandboxing](https://code.claude.com/docs/en/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 裡用：

```text
/sandbox
```

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

> [!TIP]
> **實操策略**：日常開發不要只靠許可權彈出視窗。能開 sandbox 的場景就開 sandbox，再配少量 deny 規則，把彈出視窗留給真正高風險動作。

## 8. 成本也是一種邊界

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

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

官方 [Costs](https://code.claude.com/docs/en/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 場景都有的通用開關。

> [!IMPORTANT]
> **一句話理解**：許可權防止 Claude Code 做錯事，預算防止 Claude Code 做太久。兩者都是邊界設計。

## 9. 新手該怎麼選

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

```mermaid
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`。

> [!WARNING]
> **反模式**：不要因為彈出視窗煩，就直接開 `bypassPermissions`。正確順序是：先收窄 allowlist，再考慮 sandbox，再考慮 auto，最後才是隔離環境裡的 bypass。

## 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 的規則仍然會阻止呼叫。

```mermaid
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
```

> [!TIP]
> **一句話理解**：Permission 負責“這類工具呼叫能不能過”；Hook 負責“過之前或過之後要不要做額外檢查”。

## 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。

> [!IMPORTANT]
> **過關標準**：你能為一個真實專案寫出三條規則：一個 allow、一個 ask、一個 deny，並能解釋為什麼這三條對應不同風險。

<details id="glossary">
<summary><b>📖 本篇術語速查表</b></summary>

- Permission：許可權。Claude Code 工具呼叫能不能執行的規則體系。
- Permission mode：許可權模式。一次會話的整體批准策略。
- `default`：預設模式。讀檔案自動，其他高風險動作詢問。
- `acceptEdits`：自動接受編輯。檔案改動自動透過，適合事後看 diff。
- `plan`：計劃模式。先探索和出方案，不直接改原始碼。
- `auto`：自動模式。少彈出視窗，但後臺 classifier 做安全檢查。
- `dontAsk`：不詢問模式。只執行預批准工具，其他自動拒絕。
- `bypassPermissions`：跳過許可權。跳過許可權提示和安全檢查，只適合隔離環境。
- Allow：允許規則。匹配後自動透過。
- Ask：詢問規則。匹配後要求人工確認。
- Deny：拒絕規則。匹配後直接阻止。
- Sandbox：沙盒。對 Bash 程序做作業系統級檔案和網路隔離。
- Classifier：安全分類器。`auto` 模式下判斷動作是否越界的後臺模型。
- Protected paths：受保護路徑。`.git`、`.claude` 等不應輕易自動修改的位置。

</details>

## 官方資料

- [Configure permissions](https://code.claude.com/docs/en/permissions)
- [Choose a permission mode](https://code.claude.com/docs/en/permission-modes)
- [Sandboxing](https://code.claude.com/docs/en/sandboxing)

## 接下來去哪

<Cards>
  <Card href="/zh-Hant/docs/claude-code/understanding/12-plugins" title="➡️ 12 · 外掛怎麼擴充套件" description="Permissions 解決工具能不能用，Plugins 解決能力怎麼打包和分發。下一篇講 Claude Code 外掛體系。" />
  <Card href="/zh-Hant/docs/claude-code/understanding/10-operation-control" title="10 · 怎麼讓操作 100% 執行（上一篇）" description="如果你還分不清 Hook 和 Permission，先回看上一篇：Hook 是確定性檢查點。" />
  <Card href="/zh-Hant/docs/claude-code/understanding/05-thinking-depth" title="05 · 思考深度怎麼選" description="許可權管動作邊界，effort 管思考成本。成本敏感時，這一篇也要一起看。" />
</Cards>

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