Claude Code 作為一款強大的 AI 程式開發助手,擁有讀取檔案、執行指令、修改程式碼等廣泛的系統存取能力。這些能力在提升開發效率的同時,也帶來了安全風險——如果沒有適當的權限管理,AI 可能會執行具有破壞性的操作。Claude Code 設計了一套多層次的安全架構,包括權限模型、沙箱機制、企業管理設定等,確保你可以在享受 AI 高效開發的同時,完全掌控安全邊界。本文將深入解析 Claude Code 的安全性與權限管理機制,從基礎的權限模型到進階的企業安全設定,幫助你打造安全可靠的 AI 開發環境。
權限模型概覽:多層次的安全防護
Claude Code 的權限模型採用分層設計,不同類型的工具有不同的安全等級。核心原則是「最小權限」——預設情況下,只有唯讀操作可以自動執行,任何可能修改系統狀態的操作都需要使用者明確授權。
| 工具類型 | 範例 | 是否需要授權 | 「不再詢問」行為 |
|---|---|---|---|
| 唯讀工具 | Read、Grep、Glob、WebFetch | 否 | 不適用 |
| Bash 指令 | Shell 指令執行 | 是 | 依專案目錄永久記憶 |
| 檔案修改 | Edit、Write | 是 | 僅限當前 Session |
| MCP 工具 | 外部 MCP Server 工具 | 是 | 依工具與 Server 而定 |
當你在 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 規則中的萬用字元 * 有一個重要的細節——空格的位置會影響匹配行為:
| 規則 | 匹配 | 不匹配 | 說明 |
|---|---|---|---|
Bash(ls *) | ls -la | lsof | 空格強制詞邊界 |
Bash(ls*) | ls -la、lsof | 無空格不限制邊界 | |
Bash(git commit *) | git commit -m "fix" | git commits | 匹配 git commit 加任意參數 |
Bash(* --version) | node --version | 任何指令加 –version |
檔案路徑模式
檔案相關的權限規則支援四種路徑格式,遵循 gitignore 規範:
| 格式 | 範例 | 說明 |
|---|---|---|
//path | Read(//Users/alice/secrets/**) | 從檔案系統根目錄開始的絕對路徑 |
~/path | Read(~/Documents/*.pdf) | 從家目錄開始的路徑 |
/path | Edit(/src/**/*.ts) | 從專案根目錄開始的相對路徑 |
path 或 ./path | Read(./.env) | 從目前工作目錄開始的相對路徑 |
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 | 僅唯讀操作 | 一般開發、敏感專案 |
| acceptEdits | 唯讀 + 檔案編輯 | 快速迭代程式碼 |
| plan | 僅唯讀(不修改) | 探索程式碼庫、規劃變更 |
| auto | 所有操作(含安全檢查) | 長時間任務、減少中斷 |
| dontAsk | 僅預先核准的工具 | CI/CD 管道、腳本執行 |
| bypassPermissions | 幾乎所有操作 | 隔離容器/VM(危險) |
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 的安全設定遵循嚴格的層級結構,高層級的設定永遠優先於低層級。這個設計確保了企業管理員可以強制執行安全策略,而使用者和專案只能在允許的範圍內進行自訂。
| 層級 | 位置 | 適用範圍 | 可否覆蓋 |
|---|---|---|---|
| 企業管理設定 | Server-managed / MDM 政策 | 整個組織 | 不可被任何層級覆蓋 |
| 命令列參數 | --permission-mode 等 | 當前 Session | 受企業設定限制 |
| 專案本機設定 | .claude/settings.local.json | 此專案(僅本機) | 受上層限制 |
| 專案共享設定 | .claude/settings.json | 此專案(版本控制) | 受上層限制 |
| 使用者設定 | ~/.claude/settings.json | 所有專案(僅本機) | 受上層限制 |
重要原則:如果某個操作在任何層級被 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)以上版本。
企業專屬的管理設定
以下設定只能在企業管理層級使用,提供最嚴格的安全控制:
| 設定 | 說明 |
|---|---|
allowManagedPermissionRulesOnly | 停用使用者和專案的權限規則,只使用企業管理的規則 |
allowManagedHooksOnly | 阻止載入使用者/專案/Plugin 的 Hooks |
allowManagedMcpServersOnly | 只允許企業管理的 MCP Server |
disableBypassPermissionsMode | 停用危險的 Bypass Permissions 模式 |
forceRemoteSettingsRefresh | 啟動時強制載入最新的遠端設定,載入失敗則拒絕啟動 |
sandbox.network.allowManagedDomainsOnly | 只允許企業管理的網域 |
完整的企業安全設定範例
以下是一個企業組織的完整安全設定範例,涵蓋了權限控制、沙箱配置和安全稽核:
{
"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 與永久記憶
了解權限的持久化行為,有助於你更有效率地管理日常開發流程。不同類型的操作有不同的記憶方式:
| 操作類型 | 「允許」行為 | 「不再詢問」行為 | 儲存位置 |
|---|---|---|---|
| 檔案編輯(Edit/Write) | 允許一次 | 本次 Session 有效 | 記憶體(Session 結束後清除) |
| Bash 指令 | 允許一次 | 永久有效(依專案目錄) | .claude/settings.json |
| MCP 工具 | 允許一次 | 依工具定義而定 | 設定檔 |
當你在權限提示中選擇「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
}
]
}
]
}
}
常見問題與疑難排解
| 問題 | 解決方案 |
|---|---|
| 權限規則沒有生效 | 使用 /permissions 確認規則已載入,檢查是否有更高層級的 deny 規則覆蓋了你的 allow 規則 |
| 沙箱無法啟動 | 確認已安裝 bubblewrap 和 socat(Linux),或確認 macOS 版本支援 Seatbelt |
| 企業設定沒有同步 | 確認 Claude Code 版本符合要求,且網路可以存取 api.anthropic.com |
| Auto 模式頻繁封鎖操作 | 調整 autoMode.environment 和 autoMode.allow 設定,提供更多環境資訊 |
| 萬用字元匹配不如預期 | 注意空格與 * 的位置關係,使用 /permissions 測試規則匹配 |
| 每次 Session 都要重新授權 | 檔案編輯的授權僅限 Session,使用 acceptEdits 模式可以避免重複授權 |
安全最佳實踐
- 從嚴格開始,逐步放寬:先使用
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 官方文件