權限模型概覽：多層次的安全防護

Claude Code 的權限模型採用分層設計，不同類型的工具有不同的安全等級。核心原則是「最小權限」——預設情況下，只有唯讀操作可以自動執行，任何可能修改系統狀態的操作都需要使用者明確授權。

當你在 Claude Code 中操作時，每次 Claude 需要執行需要授權的工具，都會顯示一個權限確認對話框，讓你選擇允許或拒絕。你也可以選擇「不再詢問」來跳過後續同類操作的確認步驟。

權限規則設定：Allow、Deny 與 Ask

Claude Code 的權限規則分為三種類型：allow（允許）、deny（拒絕）和 ask（詢問）。這些規則可以在不同層級的設定檔中定義，並遵循嚴格的優先順序。

規則優先順序

權限規則的評估採用「拒絕優先」原則，依以下順序匹配：

Deny 規則 → Ask 規則 → Allow 規則
（第一個匹配的規則生效）

這代表如果一個操作同時被 deny 和 allow 規則匹配，deny 規則會優先生效。這個設計確保了安全性——即使某個層級允許了某個操作，更高層級的拒絕規則仍然可以封鎖它。

規則語法與萬用字元

權限規則的格式為 Tool 或 Tool(specifier)，其中 specifier 支援萬用字元（*）和 Glob 模式。以下是一個完整的設定範例：

{
  "permissions": {
    "allow": [
      "Bash(npm run test)",
      "Bash(npm run build)",
      "Bash(git commit *)",
      "Bash(git pull)",
      "Read(/src/**)",
      "Edit(/src/**/*.ts)"
    ],
    "deny": [
      "Bash(git push origin main)",
      "Bash(curl * | bash)",
      "Bash(rm -rf /)",
      "Read(./.env*)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(npm install *)"
    ]
  }
}

Bash 萬用字元匹配規則

Bash 規則中的萬用字元 * 有一個重要的細節——空格的位置會影響匹配行為：

檔案路徑模式

檔案相關的權限規則支援四種路徑格式，遵循 gitignore 規範：

MCP 工具與 Subagent 權限

你也可以控制 MCP Server 提供的工具和 Subagent 的存取權限：

{
  "permissions": {
    "allow": [
      "mcp__github",
      "mcp__puppeteer__navigate",
      "Agent(Explore)",
      "WebFetch(domain:github.com)",
      "WebFetch(domain:*.anthropic.com)"
    ],
    "deny": [
      "mcp__untrusted_server",
      "WebFetch(domain:malicious-site.com)"
    ]
  }
}

權限模式：六種模式滿足不同場景

Claude Code 提供六種權限模式，讓你根據不同的工作場景選擇最適合的安全等級。你可以在啟動時透過 --permission-mode 參數指定模式，也可以在 Session 中使用 Shift+Tab 切換。

Default 模式

預設模式是最安全的選項，所有非唯讀操作都需要手動確認。適合處理敏感專案或剛開始使用 Claude Code 時：

claude --permission-mode default

Accept Edits 模式

在這個模式下，Claude 可以自動執行檔案讀取和編輯操作，但 Bash 指令仍需要確認。適合你正在審查 Claude 寫的程式碼，需要它快速迭代修改的場景：

claude --permission-mode acceptEdits

Plan 模式

Plan 模式讓 Claude 只分析但不修改任何檔案或執行指令。適合在動手之前先讓 Claude 分析程式碼並提出建議。你也可以在對話中使用 /plan 指令臨時切換：

claude --permission-mode plan

# 或在對話中使用
/plan 分析這個專案的架構並提出重構建議

Auto 模式（研究預覽）

Auto 模式是最新推出的功能，它使用一個安全分類器來自動判斷操作是否安全。安全的操作會自動執行，而高風險操作仍會要求確認。使用此模式需要 Team、Enterprise 或 API 方案，並且需要管理員在設定中啟用。

claude --enable-auto-mode

Auto 模式的安全分類器會自動封鎖以下類型的操作：

• 下載並執行外部程式碼（如 curl | bash）
• 將敏感資料傳送到外部端點
• 正式環境的部署與資料庫遷移
• 大量刪除雲端儲存檔案
• 修改 IAM 或 Repo 權限
• Force push 或推送到 main 分支

你可以透過 autoMode 設定來自訂分類器的行為，提供組織環境資訊和額外的規則：

{
  "autoMode": {
    "environment": [
      "Organization: ACME Corp",
      "Source control: github.company.com/acme-corp",
      "Cloud provider: AWS",
      "Trusted domains: *.internal.company.com"
    ],
    "allow": [
      "部署到 staging 環境是允許的：隔離且每晚重置"
    ],
    "soft_deny": [
      "永遠不要直接推送到 main 分支",
      "不要在 CI/CD 管道外部署到正式環境",
      "不要修改 infra/terraform/prod/ 下的檔案"
    ]
  }
}

Don’t Ask 模式

Don’t Ask 模式會自動拒絕所有沒有被明確允許的工具。只有在 permissions.allow 清單中的操作才會被執行，完全不會顯示任何權限提示。這個模式非常適合 CI/CD 管道和自動化腳本：

claude --permission-mode dontAsk

Bypass Permissions 模式（危險）

這是最危險的模式，會跳過幾乎所有權限提示。請只在完全隔離的容器或虛擬機中使用此模式。即使在此模式下，寫入受保護路徑（如 .git、.claude、.bashrc 等）仍然需要確認。企業管理員可以完全停用此模式：

// 企業設定中停用 Bypass 模式
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

沙箱機制：作業系統層級的隔離防護

傳統的權限提示機制有一個根本問題——「核准疲勞」。當你頻繁地被要求確認操作時，容易不加思索地點擊「允許」，降低了安全防護的實際效果。Claude Code 的沙箱機制透過作業系統層級的隔離來解決這個問題，在 macOS 上使用 Seatbelt sandbox，在 Linux/WSL2 上使用 bubblewrap。

啟用沙箱

在 Claude Code 中輸入 /sandbox 即可開啟沙箱設定。在 Linux 環境需要先安裝相依套件：

# Ubuntu/Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

檔案系統隔離

沙箱的檔案系統隔離預設行為如下：

• 寫入權限：僅限目前工作目錄及其子目錄
• 讀取權限：整台電腦（可透過設定限制）
• 父目錄寫入：明確封鎖，除非授權

你可以透過 sandbox 設定來自訂檔案系統的存取範圍：

{
  "sandbox": {
    "enabled": true,
    "mode": "auto-allow",
    "filesystem": {
      "allowWrite": [
        "~/.kube",
        "/tmp/build",
        "./output"
      ],
      "denyRead": ["~/private"],
      "allowRead": ["."],
      "denyWrite": ["/etc"]
    },
    "failIfUnavailable": true
  }
}

網路隔離

沙箱同時提供網路隔離功能，透過 Proxy Server 控制可存取的網域。只有核准的網域可以被存取，未知網域會觸發權限提示：

{
  "sandbox": {
    "network": {
      "allowedDomains": [
        "github.com",
        "registry.npmjs.org",
        "api.example.com",
        "*.internal.company.com"
      ]
    }
  }
}

需要注意的是，網路沙箱是以網域為單位進行過濾，無法檢查流量內容。因此，像 github.com 這樣的大型網域在理論上可能被利用來外洩資料。建議盡量使用更精確的子網域來降低風險。

設定檔層級：從個人到企業的權限管理

Claude Code 的安全設定遵循嚴格的層級結構，高層級的設定永遠優先於低層級。這個設計確保了企業管理員可以強制執行安全策略，而使用者和專案只能在允許的範圍內進行自訂。

重要原則：如果某個操作在任何層級被 deny，則沒有任何更低層級的 allow 可以覆蓋它。

專案共享設定（.claude/settings.json）

這個檔案會提交到版本控制系統，與團隊成員共享。適合定義專案層級的安全規則：

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test)",
      "Bash(git commit *)",
      "Bash(git pull)",
      "Read(/src/**)",
      "Edit(/src/**)"
    ],
    "deny": [
      "Bash(git push origin main)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./secrets/**)",
      "Read(./.env*)"
    ]
  }
}

專案本機設定（.claude/settings.local.json）

這個檔案會被 gitignore，僅在本機生效。適合開發者個人的額外設定：

// .claude/settings.local.json（不加入版本控制）
{
  "permissions": {
    "allow": [
      "Bash(npm run dev)"
    ]
  }
}

使用者設定（~/.claude/settings.json）

全域的使用者設定，適用於所有專案。適合設定你常用的安全指令白名單：

// ~/.claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(npm *)",
      "Bash(python*)"
    ]
  }
}

企業安全設定：組織層級的安全管理

對於使用 Claude for Teams 或 Enterprise 方案的組織，Claude Code 提供了伺服器管理設定（Server-Managed Settings），讓管理員可以集中管理整個組織的安全策略。這些設定無法被使用者或專案覆蓋，確保了組織層級的合規性。

啟用企業管理設定

管理員需要在 Admin Settings > Claude Code > Managed settings 中進行設定。需要 Claude Code v2.1.38+（Teams）或 v2.1.30+（Enterprise）以上版本。

企業專屬的管理設定

以下設定只能在企業管理層級使用，提供最嚴格的安全控制：

完整的企業安全設定範例

以下是一個企業組織的完整安全設定範例，涵蓋了權限控制、沙箱配置和安全稽核：

{
  "permissions": {
    "defaultMode": "plan",
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(git push origin main)",
      "Read(./.env*)",
      "Read(./secrets/**)"
    ],
    "allow": [
      "Bash(npm test)",
      "Bash(npm run build)",
      "Bash(npm install)",
      "Bash(git commit *)",
      "Bash(git pull *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "mode": "auto-allow",
    "failIfUnavailable": true,
    "filesystem": {
      "denyRead": ["~/.*"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": [
        "github.company.com",
        "registry.npmjs.org",
        "*.internal.company.com"
      ],
      "allowManagedDomainsOnly": true
    }
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "forceRemoteSettingsRefresh": true,
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/local/bin/audit-bash.sh"
          }
        ]
      }
    ]
  }
}

Drop-In 設定目錄

企業管理員還可以使用 Drop-In 目錄來管理設定，將不同面向的安全策略拆分為獨立的 JSON 檔案。這些檔案會依字母順序合併，方便不同團隊管理各自的安全規則：

/etc/claude-code/managed-settings.d/
├── 010-permissions.json    # 權限規則
├── 020-sandbox.json        # 沙箱設定
├── 030-mcp-servers.json    # MCP Server 白名單
└── 040-hooks.json          # 稽核 Hooks

權限持久化：Session 與永久記憶

了解權限的持久化行為，有助於你更有效率地管理日常開發流程。不同類型的操作有不同的記憶方式：

當你在權限提示中選擇「Yes, don’t ask again」時，對應的 Bash 指令會被自動加入到專案設定檔的 permissions.allow 清單中。你可以隨時透過 /permissions 指令查看和管理所有已設定的權限規則。

實戰應用：打造安全的開發工作流程

範例一：前端專案的安全設定

以下是一個 React 前端專案的安全設定範例，允許常用的開發指令，封鎖危險操作：

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run dev)",
      "Bash(npm run build)",
      "Bash(npm test *)",
      "Bash(npm run lint)",
      "Bash(npx prettier *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Read(./.env.production)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["./dist", "./build", "./node_modules"]
    }
  }
}

範例二：CI/CD 管道中的安全設定

在 CI/CD 環境中使用 dontAsk 模式搭配嚴格的白名單，確保 Claude Code 只執行預先核准的操作：

# GitHub Actions 範例
- name: Claude Code Review
  run: |
    claude -p \
      --permission-mode dontAsk \
      --allowedTools "Read,Grep,Glob,Bash(npm test),Bash(npm run lint)" \
      "請檢查這個 PR 的程式碼品質，執行測試和 Lint 檢查，並提供改善建議"

範例三：結合 Hooks 的安全稽核

結合 Hooks 事件掛鉤，你可以建立更完善的安全機制。例如，使用 PreToolUse Hook 封鎖危險指令，同時使用 PostToolUse Hook 記錄所有操作日誌：

{
  "permissions": {
    "allow": [
      "Bash(npm *)",
      "Bash(git *)"
    ],
    "deny": [
      "Bash(git push origin main)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-dangerous.sh",
            "timeout": 10
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/audit-log.sh",
            "async": true
          }
        ]
      }
    ]
  }
}

常見問題與疑難排解

安全最佳實踐

• 從嚴格開始，逐步放寬：先使用 default 模式，確認你的工作流程後再切換到 acceptEdits 或 auto 模式
• 善用 deny 規則：明確封鎖已知的危險操作（如 rm -rf /、curl | bash），即使你使用的是較寬鬆的權限模式
• 啟用沙箱：對於涉及第三方套件或不信任程式碼的專案，啟用沙箱可以在作業系統層級提供額外的安全保障
• 保護敏感檔案：在 deny 規則中加入 .env、secrets 等敏感檔案的路徑
• 使用專案設定共享安全規則：將 .claude/settings.json 提交到版本控制，確保團隊成員使用一致的安全策略
• 定期審查權限：使用 /permissions 指令定期檢查已授予的權限，移除不再需要的規則
• 企業環境啟用管理設定：在團隊或企業環境中，使用 Server-Managed Settings 來集中管理安全策略，防止個別開發者繞過安全限制
• 結合 Hooks 進行安全稽核：使用 PostToolUse Hook 記錄所有操作日誌，方便事後追蹤和合規審計

總結

Claude Code 的安全性與權限管理是一個多層次的體系，從基礎的工具權限分類、靈活的 Allow/Deny/Ask 規則系統、六種權限模式，到作業系統層級的沙箱機制和企業級的集中管理設定，每一層都為你提供了精確的安全控制能力。

對於個人開發者，建議從 default 模式開始，透過 .claude/settings.json 設定常用指令的白名單，並啟用沙箱保護。隨著對 Claude Code 的熟悉程度提升，可以逐步切換到 acceptEdits 或 auto 模式來提升效率。對於團隊和企業，建議利用 Server-Managed Settings 建立統一的安全策略，搭配 Hooks 進行安全稽核，確保合規性的同時不犧牲開發效率。

延伸閱讀

• Claude Code 是什麼？完整介紹與安裝教學
• Claude Code 新手上路：第一次使用就上手
• CLAUDE.md 專案記憶：讓 Claude 記住你的專案規範
• Claude Code CLI 指令完整參考
• Hooks 事件掛鉤：自動化你的 Claude Code 工作流程
• Custom Skills：打造你的專屬自訂技能
• Plugins 外掛系統：擴展 Claude Code 的能力
• Claude Code Security 官方文件

ㄚ槌

blog.che-ya.com