前言
最近有在玩 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 放進你的開發環境裡自由奔跑。
希望這篇整理有幫助到你。
