Claude Code 一定要先做好的 10 個安全設定

前言

最近有在玩 Claude Code 的人應該越來越多了吧？老實說，它真的超強，寫 code、跑 terminal command、讀寫檔案幾乎都可以幫你處理，工作效率會直接拉起來。但也正因為它能力很大，如果安全設定沒先弄好，其實也很容易踩到風險。

所以這篇我想幫大家整理一下：到 2026 年 3 月為止，根據 Claude Code 官方文件，最值得立刻先設好的 10 個安全項目。如果你現在正開始用 Claude Code，這篇可以直接當成你的安全設定 checklist。

① 先把 sandbox 打開

這個真的是最重要的一個，沒有之一。

只要把 sandbox 啟用，Claude Code 執行的 Bash 指令就會被隔離在 OS 層級的安全環境裡，像是檔案系統存取、網路連線這些能力都會受到限制。

// .claude/settings.json{ "sandbox": { "enabled": true }}

在 macOS 上，Claude Code 會用 Seatbelt；在 Linux 上則是用 Bubble Wrap 來做 sandbox。

開啟之後，也可以用 /sandbox 指令確認目前狀態。

這個功能是在 2025 年下半年才加入的，算是相對新的安全能力。如果你還沒開，真的建議第一優先先補上。

② 把 sandbox 的「逃生門」也關掉

雖然開啟 sandbox 很重要，但它預設還是留了一個「脫出口」，也就是某些情況下，特定指令可能會跳出 sandbox 外面執行。

如果你想更完整地封住這個風險，可以這樣設：

{ "sandbox": { "enabled": true, "allowUnsandboxedCommands": false }}

把 allowUnsandboxedCommands 設成 false 之後，就能完全禁止透過 dangerouslyDisableSandbox 這類方式繞過 sandbox。

簡單講就是：不只要有圍牆，連後門也要鎖起來。

③ 用 deny 規則直接擋掉危險指令

你可以透過 permissions.deny 明確告訴 Claude Code：哪些指令絕對不能跑。

像下面這樣：

{  "permissions": {    "deny": [      "Bash(rm -rf *)",      "Bash(curl *)",      "Bash(wget *)",      "Bash(git push *)",      "Bash(chmod 777 *)"    ]  }}

雖然像 curl 和 wget 這種，預設就常常會被擋，但我還是很推薦你自己再明確寫進 deny 清單，因為這樣比較不容易被其他寬鬆設定覆蓋掉。

權限規則的判斷順序是：

deny → ask → allow

也就是說，deny 永遠優先。

所以真的不想讓它碰的東西，就直接丟進 deny，最乾脆。

④ 把機密檔案讀取權限關掉

像 .env、金鑰、憑證、credentials 這類檔案，真的拜託不要讓 Claude Code 隨便讀。

你可以這樣設定：

{  "permissions": {    "deny": [      "Read(./.env)",      "Read(./.env.*)",      "Read(./secrets/**)",      "Read(./config/credentials.json)",      "Read(**/*.pem)",      "Read(**/*.key)"    ]  }}

如果想更完整一點，也可以搭配 sandbox 的 denyRead，連透過 Bash 指令去讀取都一起擋下來：

{  "sandbox": {    "filesystem": {      "denyRead": ["~/.aws/credentials", "~/.ssh"]    }  }}

這樣就不只是 Claude Code 的檔案工具不能讀，連 shell 方式偷看也會被攔住。

⑤ 網路存取要改成白名單模式

另一個非常重要的點是：不要讓 Claude Code 想連哪就連哪。

你可以在 sandbox 的網路設定裡，明確指定只允許哪些 domain：

{  "sandbox": {    "network": {      "allowedDomains": [        "github.com",        "*.githubusercontent.com",        "*.npmjs.org",        "registry.yarnpkg.com",        "pypi.org"      ]    }  }}

這樣的好處是，Claude Code 就不能隨便把資料送到你沒授權的外部伺服器。

尤其在面對 prompt injection 或資料外洩（exfiltration）風險時，這種白名單做法真的很有幫助。

⑥ 關掉 bypass permissions 模式

--dangerously-skip-permissions 這個 flag，顧名思義就是很危險。

它會直接跳過所有權限檢查。

如果你是團隊環境，這個真的不太能放著不管。建議直接禁用：

{  "permissions": {    "disableBypassPermissionsMode": "disable"  }}

如果把這個設定放進 Managed Settings，使用者端就不能自己偷偷改掉，對團隊治理會更穩。

⑦ 用 PreToolUse hook 加你自己的安全檢查

Claude Code 的 hooks 很強，能在工具執行生命週期的不同節點插入自訂邏輯。

如果你想在每次跑工具前先做一道安全檢查，PreToolUse 很適合。

設定範例如下：

// .claude/settings.json{  "hooks": {    "PreToolUse": [      {        "matcher": "Bash",        "hooks": [          {            "type": "command",            "command": ".claude/hooks/validate-command.sh"          }        ]      }    ]  }}

例如你可以寫一個 shell script，在 Claude Code 執行 Bash 指令前先檢查內容：

#!/bin/bash# .claude/hooks/validate-command.shCOMMAND=$(jq -r '.tool_input.command' < /dev/stdin)# 擋掉 rm -rfif echo "$COMMAND" | grep -q 'rm -rf'; then  echo "Blocked: rm -rf commands are not allowed" >&2  exit 2fi# 擋掉連到 productionif echo "$COMMAND" | grep -q 'prod'; then  echo "Blocked: production access is not allowed" >&2  exit 2fiexit 0

這裡的 exit 2 代表直接阻止工具執行。

除了 command 型 hook 之外，Claude Code 也支援像 HTTP webhook、LLM prompt evaluation、agent 型 hook 等不同形式，可以依照你的安全需求慢慢擴充。

⑧ 定期用 /permissions 做權限盤點

Claude Code 裡有個很好用的 /permissions 指令，可以讓你檢查目前的權限設定狀態。

建議你偶爾檢查一下：

• 有沒有累積太多 session 中按過的 Always allow
• 有沒有留下其實已經不需要的 allow 規則
• deny 規則是不是有照你預期生效

另外也可以搭配 /status 一起看，確認目前到底載入了哪些設定檔。

如果設定檔格式有錯，這裡通常也看得出來。

⑨ 最安全的做法：直接放進 devcontainer

如果你想要更完整的隔離環境，那最推薦的方法其實是：把 Claude Code 跑在 container 裡。

Anthropic 官方已經有提供 devcontainer 的 reference implementation。

它的幾個重點優勢包括：

• 有防火牆控管的網路限制，預設是 deny
• 和 host machine 做更完整隔離
• 可透過 VS Code Remote Containers 很快啟動

例如：

# 方法 1：使用 Claude Code 官方 repo 的 devcontainer 參考實作git clone https://github.com/anthropics/claude-code.git# 然後在 VS Code 裡選「Reopen in Container」

或者也可以把 devcontainer feature 加進你原本的專案：

# 方法 2：透過 devcontainer features 加到既有專案# 可參考 https://github.com/anthropics/devcontainer-features

如果你真的需要某些高自動化流程，甚至得用到 --dangerously-skip-permissions，那至少放在 devcontainer 這種隔離環境裡，風險會比直接在 host 上小很多。

但前提還是：只對你信任的 repo 這樣做。

⑩ 團隊場景一定要用 Managed Settings 管政策

如果你們是團隊或組織在用 Claude Code，那強烈建議直接上 Managed Settings。

因為這套設定的優先權最高，使用者和專案層都不能覆蓋。

目前大概有兩種方式：

方式說明適合情境Server-managed settings（public beta）從 Claude.ai 管理後台發送設定，不需要 MDM遠端工作、BYOD 環境Endpoint-managed settings用 Jamf、Intune 等 MDM 直接下發到裝置更重視裝置控管的組織

如果你用的是 Claude for Teams / Enterprise，Server-managed settings 會方便很多，因為使用者登入後就能自動收到政策設定，不一定需要先建完整的 MDM 架構。

Endpoint-managed settings 常見放置路徑如下：

OS路徑macOS/Library/Application Support/ClaudeCode/managed-settings.jsonLinux/etc/claude-code/managed-settings.jsonWindowsC:\Program Files\ClaudeCode\managed-settings.json

例如組織管理者可以考慮這樣配置：

{  "permissions": {    "disableBypassPermissionsMode": "disable"  },  "allowManagedPermissionRulesOnly": true,  "allowManagedHooksOnly": true,  "allowManagedMcpServersOnly": true,  "sandbox": {    "enabled": true,    "allowUnsandboxedCommands": false,    "network": {      "allowManagedDomainsOnly": true,      "allowedDomains": ["github.com", "*.npmjs.org"]    }  }}

幾個關鍵設定的效果大概是這樣：

設定鍵作用disableBypassPermissionsMode禁止使用 --dangerously-skip-permissionsallowManagedPermissionRulesOnly只允許管理者下發的 allow / deny / ask 規則allowManagedHooksOnly只允許管理者設定的 hooksallowManagedMcpServersOnly限制只能用管理者核准的 MCP serversallowManagedDomainsOnly只允許管理者定義的 domain 出網

對團隊來說，這些設定真的很重要，因為你不能只靠每個工程師自己「應該會小心吧」來賭。

結語

Claude Code 真的非常方便，但它越方便，越要記得安全不能佛系。

我自己的建議是這樣：

• 個人使用者：先把 ①～④ 做好
• 有接外網、跑套件、拉 repo 的情境：再補上 ⑤～⑧
• 團隊或企業環境：直接把 ⑨、⑩ 一起納入

這樣你會比較像是在「有防護地用強工具」，而不是把一個超有能力的 agent 放進你的開發環境裡自由奔跑。

希望這篇整理有幫助到你。