Claude Code 權限怎麼設?permission modes、allowlist 與安全設定完整整理(2026)
Claude Code 權限是你和 AI agent 之間的安全邊界。這篇用 Why / What / How 整理 permission modes、allowlist、settings.json 與實務設定範例。

最後更新:2026-08-13。Claude Code 官方目前列出 6 種 permission mode;不同介面只會顯示其中一部分。
如果你只是想知道 Claude Code 權限怎麼設,我會先給這個版本:
| 使用情境 | 建議模式 | 為什麼 |
|---|---|---|
| 第一次打開陌生 repo | plan | 先讀懂,不先改檔 |
| 日常小改、修 bug | acceptEdits | 編輯比較順,但仍保留權限邊界 |
| 重要專案、敏感資料多 | default | 重要動作多一層人工確認 |
| 長任務、想少按確認 | auto | 背景 classifier 會判斷風險,但仍不是完全安全 |
這篇要幫你決定哪些動作可以放行,哪些動作一定要停下來,而非單純追求「Claude Code 都不要問」。
如果你還沒看過主文,可以先讀 Claude Code 教學與實戰指南。這篇會專心處理 permissions、permission modes、allowlist 和 settings.json。
如果你是從 claude code 權限設定、claude permissions allow all、claude code permission 這些搜尋進來,可以照這個順序讀:
| 你現在遇到的問題 | 先看哪一段 |
|---|---|
想知道 settings.json 放哪裡 | Claude Code settings.json 在哪 |
| 想讓 Claude Code 少問一點 | 本文的 acceptEdits 與 allowlist 設定 |
| 想直接 allow all | 先看「為什麼不要一開始就 allow all」 |
| 想拆更細的設定範例 | Claude Code allowTools / disallowedTools 規則範例 |
Claude Code 介面常見的 4 種模式;完整 CLI 與設定另有 dontAsk、bypassPermissions
這張截圖只代表當時介面可見的常用選項,不是完整模式清單。官方文件目前列出 default、acceptEdits、plan、auto、dontAsk、bypassPermissions 共 6 種;dontAsk 不會出現在一般循環選單,auto 與 bypassPermissions 也會受到版本、方案、平台與設定限制。
為什麼 Claude Code 權限設定很重要?
Claude Code 不是一般聊天機器人。
它可以讀檔、改檔、跑 shell 指令,也可以透過 MCP 或其他工具碰到外部服務。它會真正進到你的工作目錄裡做事,不只在螢幕上回答問題。
這就是為什麼權限提示不該被當成煩人的彈窗。
它比較像你把公司鑰匙交給一個很聰明的助理前,先講清楚:
- 哪些房間可以進
- 哪些文件可以看
- 哪些動作要先問
- 哪些事情不准碰
很多人第一次用 Claude Code,最想解決的是「它怎麼一直問我可不可以」。但真正該問的是:
我現在這個任務,值得給它多大的自主權?
如果你在自己的玩具 repo 裡測試,權限可以開大一點。
如果你在客戶專案、公司 repo、含有 .env、金流、會員資料的專案裡工作,就要保守很多。
為什麼不要一開始就 allow all?
搜尋 claude allow all、claude code allow all 的人很多。
我懂那個痛點。你只是想讓任務順順跑,不想每隔幾分鐘就按一次允許。
但 allow all 最大的問題是:你省掉的不只是提示,也省掉了邊界。
| 做法 | 表面效果 | 真正風險 |
|---|---|---|
| 把所有 Bash 都放進 allowlist | 幾乎不再跳提示 | 等於給 shell 很大的自由度 |
另外啟用 Bypass permissions | 最順 | 跳過權限檢查,prompt injection 和誤操作風險最高 |
用 acceptEdits + 精準 allowlist | 比較順 | 還保留高風險動作的確認 |
用 plan 先看再改 | 比較慢 | 最適合陌生 repo 和大改動 |
我自己的做法很簡單:
不要追求完全不問,要追求只問重要的事。
例如 npm test、npm run lint 這種每天固定跑、失敗也不會傷到系統的指令,可以放進 allowlist。
但 curl | bash、git push、刪大量檔案、碰 .env,我會保留人工確認,甚至直接 deny。
Claude Code permission modes 是什麼?
permission mode 是 Claude Code 的基礎權限模式。它決定 Claude Code 在沒有額外規則時,哪些工具可以直接跑,哪些要問你。
Claude Code 官方目前列出 6 種模式,但你在 Desktop、VS Code、CLI 或 Web 看到的選項可能不同:
| 模式 | 不詢問時可做什麼 | 適合誰 |
|---|---|---|
Ask permissions / default | 重要動作先問 | 剛開始、重要專案、敏感工作 |
Accept edits / acceptEdits | 改檔更順,但仍保留權限邊界 | 已理解範圍的小改動 |
Plan mode / plan | 只讀與規劃,不先改原始碼 | 陌生 repo、大改動前 |
Auto mode / auto | 透過背景安全檢查減少提示 | 長任務、想降低打斷 |
dontAsk | 只執行已預先允許的工具,其餘直接拒絕 | CI、固定腳本、非互動流程 |
Bypass permissions / bypassPermissions | 跳過權限提示與多數安全檢查 | 只限隔離容器、VM 或可丟棄環境 |
你可能也會在選單底部看到灰色的 Bypass permissions。
它需要另外到 Claude Code settings 裡啟用,不屬於一般情況下直接切換的日常模式。這個模式會跳過權限檢查,只適合隔離容器、VM 或可丟棄的測試環境。
要注意一件事:
除了 bypass 這種高風險設定之外,permission rules 仍然會疊在模式上。
也就是說,你可以用 acceptEdits 當日常模式,再用 deny 擋 .env、secrets、危險 shell 指令。這比直接全開健康很多。
這 6 個模式怎麼選?
日常互動最常碰到的是 default、acceptEdits、plan 和符合資格時的 auto;dontAsk 偏向非互動流程,bypassPermissions 則不是一般專案的日常選項。
在 Claude Code 裡,你可以透過模式選單或快捷鍵切換。畫面上的名稱比較口語,例如 Ask permissions、Accept edits;設定檔或 CLI 裡則常看到 default、acceptEdits 這種寫法。
Claude Code permission mode 指令怎麼下?
如果你搜尋的是 claude code cli --permission-mode acceptedits、claude code permission modes 或 bypasspermissions official docs,先看這張對照表:
| 你想做的事 | CLI 指令 | 適合情境 |
|---|---|---|
| 一般詢問、每步確認 | claude --permission-mode default | 新手、敏感 repo |
| 自動接受改檔 | claude --permission-mode acceptEdits | 日常文案、小修、你會看 diff |
| 只分析不改檔 | claude --permission-mode plan | 陌生專案、先看方案 |
| 非互動、只允許預先批准工具 | claude --permission-mode dontAsk | CI、固定腳本 |
| 跳過權限檢查 | claude --permission-mode bypassPermissions | 只適合隔離容器或 VM |
這裡最容易打錯的是大小寫。官方模式名稱是 acceptEdits、bypassPermissions,不是 acceptedits 或 bypasspermissions。有些 UI 會顯示 Accept edits、Bypass permissions,但 CLI 和設定檔最好照官方寫法。
如果你只是想每次開 Claude Code 都預設成 acceptEdits,可以在 settings.json 放:
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
我不建議把 bypassPermissions 設成日常預設。它會直接跳過權限層,和單純「少問一點」的風險完全不同。
default:剛開始最穩
default 適合你還在觀察 Claude Code 行為的時候。
它會比較常問你,體感比較慢,但好處是你可以逐步建立信任感。你會看到它想做什麼、為什麼要做、哪些指令會被要求確認。
適合:
- 第一次用 Claude Code
- 專案含敏感資料
- 你還沒建立 allowlist
- 客戶專案或公司 repo
acceptEdits:日常改檔最實用
acceptEdits 通常是我覺得最適合日常工作的模式。
它允許檔案編輯和常見檔案系統操作自動通過,修改流程會順很多。你還是要看 diff、跑測試,但不會被每個小編輯打斷。
適合:
- 小 bug 修補
- 文案修改
- 局部 refactor
- 你已經看過 Claude 的計畫
不適合:
- 還沒看懂的陌生 repo
- 金流、會員、資料庫 migration
- 一次跨太多模組的大改動
plan:陌生 repo 先用這個
plan 最大的價值是把 Claude Code 鎖在「先理解」的狀態。
它可以讀檔、分析、提出方案,但不會先動你的原始碼。對接案、維護舊專案、第一次進公司 repo 來說,這個模式很重要。
我通常會在這些情況先用 plan:
- 不知道架構怎麼長
- 不確定 bug 根因
- 要改 API contract
- 要做 migration
- 想先請 Claude Code review 一輪
你可以先讓它提出改法,等你看完再切到 acceptEdits 或 default。
auto mode 值得開嗎?
auto mode 可以開,但不要把它當成「安全的全自動」。
依官方文件,auto 會用背景安全檢查來降低 prompt fatigue。它會在每次動作前判斷風險,安全的動作盡量放行,風險較高的動作再要求你確認。
這比 Bypass permissions 好很多,因為它仍然有一層判斷。
但你要記得三件事:
| 觀念 | 說明 |
|---|---|
auto 不是絕對安全 | classifier 可能誤擋,也可能漏掉風險 |
auto 仍需要 review | 長任務結束後,一定要看 diff 和跑測試 |
auto 有使用條件 | 實際可用性以官方文件與你的帳號方案為準 |
如果你現在常做的是長時間 refactor、測試修復、文件整理,auto 會有感。
如果你做的是資料庫、部署、刪檔、改 infra,我不會只靠 auto。這些任務寧可多問幾次,也不要把風險藏在效率裡。
Bypass permissions 要不要開?
一般情況不要。
你截圖裡看到的 Bypass permissions 是灰色的,下面也寫著 Enable in Claude Code settings。這代表它需要另外到 settings 開啟,屬於高風險選項,不在目前選單的 4 個日常模式裡。
我會把它理解成:
| 選項 | 白話理解 | 適合情境 |
|---|---|---|
| 4 個日常模式 | 仍保留權限邊界 | 真實專案、日常 coding、接案工作 |
Bypass permissions | 跳過權限檢查 | 隔離容器、VM、可丟棄的測試資料夾 |
Bypass 只適合:
- Docker container
- VM
- 可丟棄的測試資料夾
- 沒有 secrets 的環境
- 你能接受整個環境被弄壞再重建
它不是日常工作模式。
Claude Code allowlist 要怎麼設?
allowlist 的目的不是讓所有東西都不問。
比較好的想法是:
把低風險、可預期、常重複的動作先放行。
我會把權限分成三層:
| 類型 | 建議規則 | 例子 |
|---|---|---|
| 固定低風險 | allow | npm run lint、npm test、讀文件 |
| 需要人工看一下 | ask | git push、production migration、部署 |
| 不該碰 | deny | .env、secrets、私鑰、敏感資料夾 |
一個比較健康的新手設定可以長這樣:
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Bash(npm run lint)",
"Bash(npm run test:*)",
"Read(docs/**)"
],
"ask": [
"Bash(git push:*)",
"Bash(npm run deploy:*)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Bash(curl:*)"
]
}
}
這份設定的思路是:
- 日常測試和 lint 先放行
- 推送和部署每次都要問
.env、secrets、外部下載執行先擋掉
官方 permissions 文件也寫得很清楚:規則會依 deny → ask → allow 的順序評估。真正重要的是先擋住高風險區域,接著才決定 allow 的範圍。
settings.json 要放哪裡?
Claude Code 設定常見有幾個層級:
| 檔案 | 用途 | 適合情境 |
|---|---|---|
~/.claude/settings.json | 個人全域設定 | 每個專案都想套用 |
.claude/settings.json | 專案共享設定 | 團隊規則,可進版本控制 |
.claude/settings.local.json | 個人專案設定 | 自己實驗,不想 commit |
如果你是第一次找這個檔案,可以直接照路徑判斷:
| 你要改的範圍 | macOS / Linux 路徑 | Windows 路徑 | 說明 |
|---|---|---|---|
| 個人全域設定 | ~/.claude/settings.json | %USERPROFILE%\.claude\settings.json | 影響你自己所有專案 |
| 目前專案的團隊設定 | 你的專案/.claude/settings.json | 你的專案\.claude\settings.json | 可以 commit,適合放團隊共同規則 |
| 目前專案的個人設定 | 你的專案/.claude/settings.local.json | 你的專案\.claude\settings.local.json | 不建議 commit,適合放自己的 allowlist |
例如你在 macOS,專案放在 ~/Sites/my-app,那專案設定就是:
~/Sites/my-app/.claude/settings.json
個人 local 設定就是:
~/Sites/my-app/.claude/settings.local.json
如果 .claude 資料夾還不存在,可以自己建立。
也可以在 Claude Code 裡用 /config 調整,Claude Code 會幫你寫回對應的設定檔。
我會建議這樣分:
- 個人偏好的
defaultMode放全域 - 團隊共同的 deny 規則放專案設定
- 自己臨時測試的 allowlist 放 local
不要把所有規則都塞進專案共享設定。
原因很簡單:你不希望別人 clone repo 後,直接繼承一份過度寬鬆的權限設定。尤其是 bypass 這種高風險設定,更不應該被專案設定默默帶著走。
我自己的 Claude Code 權限 SOP
如果你想直接抄一個實務流程,我會這樣做:
| 階段 | 模式 | 做什麼 |
|---|---|---|
| ① 探索 | plan | 請 Claude Code 讀 repo、找檔案、提出改法 |
| ② 小改 | acceptEdits | 讓它改指定範圍,改完看 diff |
| ③ 驗收 | default 或保留目前模式 | 跑測試、看變更、確認沒有動到不該動的地方 |
| ④ 長任務 | auto | 只在範圍清楚、可回滾時使用 |
| ⑤ 高風險 | plan 或 default | migration、deploy、刪檔、金流都不要急著放行 |
我不會把 Bypass permissions 放進日常 SOP。
如果真的要用,我會先開一個乾淨資料夾、container 或 VM,把能丟掉的東西放進去跑。跑完再把結果搬回正式 repo,而不是讓它直接在主專案裡全權操作。
把權限設好之後,agent 能幫你做的事:如果你也在經營自己的商店, 我們寫過用 Claude Code 自動化 WooCommerce(庫存警示、 商品描述生成、批次更新),以及一人電商自動化系統:WooCommerce × Notion × n8n。 權限設定就是讓 agent 能碰這些真實資料而你還睡得著的前提。
Claude Code 一直跳 permissions,怎麼排查?
如果你一直被問,可以照這個順序查:
| 檢查項目 | 怎麼看 |
|---|---|
| 目前 mode 是什麼 | 看狀態列,或確認啟動時的 --permission-mode |
是不是在 default | default 本來就比較常問 |
| allowlist 是否太少 | 固定測試、lint、讀文件可以先放行 |
| 任務是否太模糊 | prompt 不清楚時,Claude 更容易做出超出範圍的動作 |
| 是否碰到高風險行為 | shell、網路、刪檔、部署、secrets 本來就該問 |
| 是否用錯模式 | 陌生 repo 先 plan,小改再 acceptEdits |
最常見的問題是:你想用 acceptEdits 的順暢感,卻在做應該用 plan 的任務。
如果你還沒看懂 repo,先不要急著讓它改。
先叫它列出「會動哪些檔案、為什麼、風險在哪裡」,再切模式會穩很多。
Claude Code 權限設定最常見的錯誤
1. 把 Bypass permissions 當日常模式
這是最大坑。
它很順,但順到你可能來不及攔。除非是隔離環境,不然不要把它當成工作習慣。
2. allowlist 寫得太寬
像 Bash(*) 這種規則,表面上是方便,實際上等於把 shell 的邊界打開。
如果你只是想少被問,先從固定命令開始,不要一開始就開整包。
3. 沒有寫 deny
很多人只寫 allow,沒寫 deny。
但真正保護你的通常是 deny。像 .env、私鑰、secrets、production 設定,應該明確寫出來。
4. 大改動一開始不用 plan
Claude Code 很會改,但它不一定一開始就懂你的系統。
大改動先讓它分析,再讓它動手。這樣能直接降低返工。
5. 不看 diff、不跑測試
權限模式不是替你驗收。
就算用 default,你還是要看 diff。就算用 auto,你還是要跑測試。agent 能幫你做事,但不能替你負責。
Claude Code 權限常見問題 FAQ
Claude Code 哪個 permission mode 最適合新手?
第一次用建議從 plan 和 default 開始。等你知道 Claude Code 會怎麼讀檔、改檔、跑指令,再把日常小改切到 acceptEdits。
Claude Code 可以設定成預設 acceptEdits 嗎?
可以。你可以在 settings.json 的 permissions.defaultMode 設成 "acceptEdits"。如果是在 CLI 啟動,也可以用 claude --permission-mode acceptEdits。
Claude Code acceptedits 和 acceptEdits 一樣嗎?
查資料時你可能會看到有人寫 acceptedits,但官方文件中的 mode 名稱是 acceptEdits。建議 CLI 和 settings.json 都用官方大小寫,避免版本或介面解析差異。
Claude Code bypassPermissions 要怎麼啟用?
官方文件把 bypassPermissions 定位成跳過權限檢查的高風險模式,通常需要用 --permission-mode bypassPermissions、--dangerously-skip-permissions 或相關允許旗標啟動。它只適合隔離容器、VM 或可丟棄環境,不適合真實專案日常使用。
claudeCode.initialPermissionMode 可以設成 auto 嗎?
依官方文件,claudeCode.initialPermissionMode 不接受 auto。如果你要預設用 auto,應該在 Claude Code 的 settings.json 裡設定 permissions.defaultMode,實際可用性仍要看帳號與官方條件。
Claude Code auto mode 安全嗎?
它比 Bypass permissions 更有保護,因為會經過背景安全檢查。但它不是絕對安全,也不能取代 diff review、測試和人工驗收。
Claude Code 可以完全不要問我權限嗎?
一般不要追求完全不問。日常應該先用 Accept edits 搭配精準 allowlist,讓固定低風險命令少問;如果真的要跳過權限檢查,就要另外啟用 Bypass permissions,而且只適合隔離環境。
Claude Code allowlist 要怎麼寫才不危險?
先 allow 固定、低風險、可預期的命令,例如測試和 lint。再用 ask 保留部署、push、migration 的人工確認,並用 deny 擋 .env、secrets、私鑰與高風險 shell。
結論:權限是放心使用 agent 的前提
Claude Code 權限設定的核心,不是找出最強模式。
真正的問題是:你現在這個任務,適合交給 AI 多大的自由?
我自己的簡化版本是:
- 不熟的 repo:
plan - 日常小改:
acceptEdits - 敏感專案:
default - 長任務:謹慎用
auto - 想減少提示:精準 allowlist
- 隔離環境才碰:
Bypass permissions
你能驗收,Claude Code 才是助理。
你驗收不了,它只是把焦慮自動化。
參考資料
資料最後查核日期:2026-08-13
- Claude Code Docs: Choose a permission mode
- Claude Code Docs: Configure permissions
- Claude Code Docs: Settings
- Anthropic Docs: Claude Code settings
還沒用過 Claude Code?
Claude Code 是 Anthropic 官方的 AI coding agent,可以在終端機直接操作本機檔案、跑指令、串工作流。
延伸閱讀
- Claude Code 教學與實戰指南:從安裝、指令到專案工作流(2026)
- 用 Claude Code 打造個人 AI Agent:Hooks、排程、MCP 完整教學(2026)
- Claude Code Telegram 教學:用官方 Channels 從手機操作本機專案(2026)
- Claude Code Remote Control 教學:怎麼從手機延續本機 session(2026)
- 用 Claude Code 自動化 WooCommerce:庫存警示、商品描述生成、批次更新(2026)
- WooCommerce MCP 教學:用 AI Agent 管理你的網路商店(2026)
順便看一下你自己的網站
會架自動化的人,網站通常是自己弄的,也通常沒空回頭看它現在跑得怎樣。
我們做了一支免費的網站健檢,跑速度、SEO 結構、安全標頭、SSL、網域信箱、AI 搜尋能見度六項,出一份看得懂的報告。不用留信用卡,也不會有人打電話給你。
👉 免費網站健檢
我們拿它做什麼
我們是幫小品牌做網站與電商的工作室,Claude Code 是日常在用的工具,權限模式這件事對我們的意義很實際:改客戶的正式站時,不能讓它自己決定要不要動資料庫。
所以我們的做法是開發環境放寬、正式環境收緊,跟這篇講的分層邏輯一樣。
同一套工具用在電商後台的實際流程,寫在這篇:用 Claude Code 做 WooCommerce 自動化。
想用 AI 規劃你的網站專案?
把需求講清楚,我們用 AI 規劃 + 人工審閱,給你務實的建議。
Related Reading
延伸閱讀

技術
Claude Code allowTools 與 disallowedTools 怎麼設?常用權限規則範例
Claude Code 權限設定不是把所有工具打開,而是把每天安全重複的動作放行,把會刪檔、推送、讀 secrets 的動作擋下來。

技術
Claude Code settings.json 在哪?專案、使用者與權限設定路徑整理
Claude Code 的 settings.json 不是只有一個位置。這篇用表格整理全域、專案、local 設定的差別, 以及權限設定應該放在哪裡。

技術
Claude Code GitHub Actions 教學:怎麼讓 @claude 幫你處理 issue 和 PR(2026)
Claude Code GitHub Actions 怎麼用?這篇整理 @claude 的用途、Claude GitHub app、/install-github-app、手動安裝、workflow 寫法、CLAUDE.md、成本與安全注意事項。