Claude Code 權限怎麼設？permission modes、allowlist 與安全設定完整整理（2026）

最後更新：2026-05-19

如果你只是想知道 Claude Code 權限怎麼設，我會先給這個版本：

使用情境	建議模式	為什麼
第一次打開陌生 repo	plan	先讀懂，不先改檔
日常小改、修 bug	acceptEdits	編輯比較順，但仍保留權限邊界
重要專案、敏感資料多	default	重要動作多一層人工確認
長任務、想少按確認	auto	背景 classifier 會判斷風險，但仍不是完全安全

這篇的重點不是教你「怎麼讓 Claude Code 都不要問」，而是幫你決定：哪些動作可以放行，哪些動作一定要停下來。

如果你還沒看過主文，可以先讀 Claude Code 教學與實戰指南。這篇會專心處理 permissions、permission modes、allowlist 和 settings.json。

為什麼 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 在沒有額外規則時，哪些工具可以直接跑，哪些要問你。

以 2026-05-19 的 Claude Code 介面來看，模式選單裡主要會看到 4 個：

模式	不詢問時可做什麼	適合誰
Ask permissions / default	重要動作先問	剛開始、重要專案、敏感工作
Accept edits / acceptEdits	改檔更順，但仍保留權限邊界	已理解範圍的小改動
Plan mode / plan	只讀與規劃，不先改原始碼	陌生 repo、大改動前
Auto mode / auto	透過背景安全檢查減少提示	長任務、想降低打斷

你可能也會在選單底部看到灰色的 Bypass permissions。
它不是一般情況下直接切換的日常模式，而是要另外到 Claude Code settings 裡啟用。這個模式會跳過權限檢查，只適合隔離容器、VM 或可丟棄的測試環境。

要注意一件事：
除了 bypass 這種高風險設定之外，permission rules 仍然會疊在模式上。

也就是說，你可以用 acceptEdits 當日常模式，再用 deny 擋 .env、secrets、危險 shell 指令。這比直接全開健康很多。

這 4 個模式怎麼選？

這 4 個就是你日常最常碰到的模式。

在 Claude Code 裡，你可以透過模式選單或快捷鍵切換。畫面上的名稱比較口語，例如 Ask permissions、Accept edits；設定檔或 CLI 裡則常看到 default、acceptEdits 這種寫法。

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。這代表它不是目前選單裡的 4 個日常模式之一，而是需要另外到 settings 開啟的高風險選項。

我會把它理解成：

選項	白話理解	適合情境
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，而不是讓它直接在主專案裡全權操作。

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。

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-05-19

• 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）

想看更多

我每週寄兩封電子報：

• 週二《用減法瘦生活》：聊焦慮、節奏、選擇、減少內耗
• 週六《用瘦系統經營個人品牌》：聊寫作、Threads、AI 自動化、一人事業

如果這篇對你有幫助，這兩封信可能也會。直接在文末訂閱表單填 email 即可（page_url 自動歸因到本文）。

---