Claude Code allowTools 與 disallowedTools 怎麼設？常用權限規則範例

Claude Code allowTools 怎麼設？先看這個版本

如果你只是想讓 Claude Code 少問一點，我會先這樣設：

這篇是 [[2026-05-19 Claude Code 權限怎麼設？permission modes、allowlist 與安全設定完整整理（2026）|Claude Code 權限母文]] 的子文。
如果你還不知道 settings.json 放哪裡，先看 [[2026-05-24 Claude Code settings.json 在哪？專案、使用者與權限設定路徑整理|Claude Code settings.json 路徑整理]]。

重點只有一句：

allowTools 不是讓 Claude Code 什麼都能做，而是讓它只在你信任的範圍內少問一點。

本文含 Claude 推薦連結：Claude。權限設定與 CLI 參數會隨版本調整，本文查詢日期為 2026-05-24，實際仍以官方文件為準。

allowTools 和 disallowedTools 差在哪？

你可以把它想成公司門禁。

allowTools 像是「這些門平常可以刷卡進去」。
disallowedTools 像是「這些門就算你有卡，也不能進去」。

官方文件也有提醒一個很重要的觀念：
allow 規則只影響「自動批准」，不是讓工具從不存在變成存在。deny 規則才是明確封鎖。

所以不要以為「我只 allow Read，Claude Code 就永遠不會嘗試其他工具」。
比較精準的理解是：

• allow：這些動作通過時少問你
• deny：這些動作不要做
• permission mode：剩下沒有命中的動作怎麼處理

最小安全版 settings.json

如果你不知道怎麼開始，可以先用這個版本。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck:*)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(**/.env*)",
      "Read(**/*secret*)",
      "Read(**/*credential*)",
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

這不是萬用設定，但很適合當起點。

它的邏輯是：

① 讓 Claude Code 可以順利讀專案
② 讓它可以跑常見檢查
③ 擋掉 secrets
④ 擋掉刪檔、強制改 git 狀態、網路下載執行

如果你是在客戶專案或公司 repo，我會再更保守一點，把 Edit、Write 都留給人工確認，不要一開始就放進 allow。

哪些 Bash 指令可以放行？

我的判斷方式很簡單：

失敗也不會造成破壞，而且你每天都會重複跑的指令，才適合放進 allowlist。

如果你真的需要讓 Claude Code 自動跑 build，可以把 scope 寫窄一點。

{
  "permissions": {
    "allow": [
      "Bash(npm run build:*)"
    ]
  }
}

但我不會把整個 Bash(*) 放進 allow。
那已經不是「少問」，而是把門拆掉。

settings.json 應該放全域還是專案？

看這張表就好。

我自己的習慣是：

• 全域只放非常保守的讀取和檢查指令
• 專案共享只放團隊真的同意的規則
• 個人 local 才放自己常用但不適合強迫別人的指令

例如你可以把 npm test 放專案共享。
但你自己常用的 pnpm dev、node tmp/debug.mjs，就比較適合放 local。

3 種常見情境範例

① 內容網站：Markdown 編輯 + build 檢查

適合寫文章、改 frontmatter、跑靜態網站檢查。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm run build:*)"
    ],
    "deny": [
      "Read(.env*)",
      "Bash(git push:*)",
      "Bash(rm:*)"
    ]
  }
}

這種設定適合內容網站，因為工作多半是讀文章、改 Markdown、跑 build。

② 前端專案：測試與型別檢查優先

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck:*)"
    ],
    "deny": [
      "Read(**/.env*)",
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Bash(rm:*)"
    ]
  }
}

前端專案的重點是讓 Claude Code 能快點驗證，但不要讓它自動推送或重置 git。

③ 客戶專案：保守版

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(git status:*)"
    ],
    "deny": [
      "Read(**/.env*)",
      "Read(**/*secret*)",
      "Read(**/*credential*)",
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Bash(rm:*)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

客戶專案先保守是正常的。
你可以等 Claude Code 跑過幾輪、你看懂它的行為，再逐步加 allow。

最常見錯誤

我會建議每次新增 allow 規則前，都問自己一句：

這個動作如果在半夜自動跑，我明天早上會不會後悔？

如果答案是會，就不要放進 allow。

我的建議設定順序

不要一次把權限打開。

比較好的順序是：

1. 先用 default 或 plan 觀察 Claude Code 會做什麼。
2. 把每天重複允許的安全指令記下來。
3. 只把這些指令加進 permissions.allow。
4. 先補 .env、secrets、刪檔、推送的 deny 規則。
5. 跑一週後再調整。

這樣你會得到一個比較健康的工作流：

日常低風險動作不打斷，高風險動作仍停下來問你。

常見問題 FAQ

allowTools 是不是等於 allow all？

不是。allow 規則只是讓符合條件的工具或指令少問你，不是把整個 Claude Code 權限系統關掉。真正高風險的是 bypassPermissions 或把 Bash(*) 這類過寬規則放進 allow。

disallowedTools 和 deny 規則哪個比較重要？

日常設定我會優先寫在 settings.json 的 permissions.deny，因為它會跟專案設定一起保存。CLI 的 --disallowedTools 適合臨時 session 加限制。

可以把 npm run build 放進 allow 嗎？

可以，但要看專案。若 build 只產生可重建的輸出，通常可以；若 build 會部署、改資料庫或產生不可逆結果，就不應該放行。

為什麼我設定 allow 後還是會問？

常見原因是規則沒有精準命中、工具名稱或 Bash pattern 寫法不對、被更高層的 deny 規則擋住，或該動作不屬於 allow 規則能自動批准的範圍。

參考資料

• Claude Code Docs：Configure permissions
• Claude Code Docs：Settings
• Claude Code Docs：CLI reference