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

最後更新：2026-04-04

先說結論：Claude Code 權限怎麼設最穩？

如果你是第一次用 Claude Code，我會直接建議你這樣開：

讀陌生 repo：plan
開始小範圍修改：acceptEdits
重要專案或敏感任務：default 或 plan
想減少一直按允許，但還是保留安全檢查：auto
受控環境、只允許預先批准工具：dontAsk
隔離容器、你非常清楚風險時：才考慮 bypassPermissions

這題最常見的誤解是：

「Claude Code 一直跳權限，好煩，我是不是應該直接全開？」

我的答案通常是：不要。

因為權限提示本身不是 bug，而是 Claude Code 作為 agent 必然要有的安全層。它不是單純聊天工具，它真的會：

執行 shell 指令
修改檔案
呼叫網路
存取 MCP 工具

所以權限模型不是額外麻煩，而是你要不要讓它真正進工作流的前提。

如果你還沒看過主文，先讀 Claude Code 教學與實戰指南：從安裝、指令到專案工作流（2026）會比較有全局感。
如果你卡的是 Telegram 或 Remote Control 裡的權限行為，也可以對照：

Claude Code 的 permission modes 到底有哪些？

依目前官方文件，最常見的模式有這幾個：

default
acceptEdits
plan
auto
dontAsk
bypassPermissions

先講白話版差異：

模式	核心感覺	最適合的時候
`default`	保守、逐步確認	剛開始、敏感工作
`acceptEdits`	改檔更順，但還是有邊界	小範圍修補
`plan`	先想，不先改	讀 repo、陌生專案、重要改動前
`auto`	盡量少問，用 classifier 擋危險動作	長任務、想減少 prompt fatigue
`dontAsk`	只允許你先批准過的工具	鎖很緊的環境
`bypassPermissions`	幾乎不擋	隔離環境、你完全知道在做什麼

這裡最重要的一個觀念是：

permission modes 不是效率模式，而是風險模式。

很多人會把它當成：

保守 = 慢
全開 = 快

但真正的差別比較像：

你現在想要多大程度的人工驗收
你現在的任務值不值得放更大的自主權

default 和 acceptEdits 差在哪？

這是新手最常卡的第一題。

`default`

可以把它理解成比較標準、比較保守的互動模式。

你會比較常看到它在重要動作前停下來，等你確認。

適合：

你第一次進陌生 repo
你還在摸 Claude Code 的節奏
專案比較敏感

`acceptEdits`

這個模式的好處是，改檔流程會順很多。

它不是完全不問，但它比 default 更像是在說：

「如果只是工作目錄裡合理的編輯，我先幫你做，其他再問。」

適合：

你已經看過分析
修改範圍不大
你準備好看 diff 和跑測試

如果你現在最常做的是：

小 bug 修補
文案小改
局部 refactor

那 acceptEdits 通常是很實用的日常模式。

plan mode 為什麼特別值得先學？

我自己很推薦新手先學 plan。

因為它直接把一個很重要的工程習慣內建進去：先理解，再動手。

官方文件對 plan mode 的描述也很清楚：

讀專案
分析可能做法
提出方案
你再決定怎麼進下一步

也就是說，這個模式不是來幫你省時間，而是來幫你避免一開始就走歪。

什麼時候最適合用 plan mode？

陌生 repo
多檔案修改
牽涉 migration、backward compatibility、架構調整
你自己都還不確定該怎麼改

為什麼它很適合台灣接案者？

因為很多接案場景不是你熟悉的專案，而是別人交來一包有點亂的東西。

這種情況如果一開始就讓 Claude Code 改，很像你剛走進一間陌生租屋處，連總開關在哪都還沒摸清楚，就直接開始拆牆。

比較穩的做法當然是先看電箱、先看水管、先看哪裡漏水。

plan mode 的價值就在這裡。

auto mode 值得開嗎？

值得，但不要把它想成「安全的全自動」。

官方文件對 auto mode 的定位很清楚：

用背景 classifier 取代手動 permission prompts
讓 Claude 盡量自己往下做
降低一直被打斷的 prompt fatigue

auto mode 有哪些前提？

官方文件目前列得很明確：

要先用 --enable-auto-mode
Shift+Tab 切換模式時，auto 不會直接出現在循環裡，除非你先開這個 flag
Team plan 可用，Enterprise / API support 正在 rollout
admin 也可能要先在組織層打開
需要 Claude Sonnet 4.6 或 Opus 4.6
不支援 Haiku、claude-3 系列、Bedrock、Vertex、Foundry

如果你想看這些模式在 GitHub 協作流程裡怎麼影響任務設計，也可以接著讀 Claude Code GitHub Actions 教學：怎麼讓 @claude 幫你處理 issue 和 PR（2026）。

它怎麼判斷要不要擋？

這是 auto mode 最值得理解的地方。

官方文件說得很清楚，每次動作前都會有一個獨立 classifier 看：

這個動作有沒有超出你要求的範圍
這個目標是不是不在信任環境裡
它是不是被檔案或網頁裡的惡意內容帶歪

它不是只看指令字串，也會讀：

你的對話上下文
CLAUDE.md
pending action

這代表 auto mode 不是靠死板的 regex 在擋，而是做一層語意判斷。

auto mode 什麼會被擋？

官方文件目前列的預設 block 類型包括：

curl | bash
把敏感資料送到外部 endpoint
production deploy / migrations
mass delete
改 shared infrastructure
force push / 直接推 main

這些規則很合理。
因為這些就是「萬一放過一次，代價可能很大」的動作。

auto mode 不是萬靈丹

官方文件也講得很老實：

它是 research preview
不能保證安全
只是比 bypassPermissions 更有保護
還是不能取代人工 review

所以如果你現在把 auto mode 想成：

「太好了，從今天起我都不用看了。」

那這個期待本身就錯了。

比較好的理解是：

它幫你減少那些低價值的重複確認，不是幫你取消驗收。

dontAsk 和 bypassPermissions，差在哪裡？

這兩個很容易一起被提，但風險感完全不同。

`dontAsk`

官方文件給它的定位是：

只允許 pre-approved tools。

也就是說，只有你事先 allow 過的工具能走，其他不走。

這很適合：

公司內部鎖很緊的環境
你只允許某幾種動作
你不要每次都被問，但也不想整個放開

`bypassPermissions`

這個就完全不一樣了。

官方文件直接把它叫做：

dangerously-skip-permissions

它的意思不是「方便模式」，而是：

跳過所有 permission checks。

官方文件也講得很直白：

這個模式對 prompt injection 或 unintended actions 沒有保護。

所以你如果不是在：

隔離容器
沙盒環境
很清楚自己在做什麼

我不建議你碰這個模式。

allowlist 是什麼？要怎麼想比較對？

allowlist 很多人會把它想成「省提示工具」，但我覺得更準確的理解是：

把重複、低風險、可預期的動作先列成白名單。

例如像：

npm test
某個固定 lint 指令
某個固定讀檔工具

這種你每天都在做、風險也清楚的，就很適合先 allow。

但如果你一口氣把：

Bash(*)
各種 wildcard interpreter
package manager run commands

這種高權限入口一起放進 allowlist，就很容易把原本的安全設計整個打穿。

官方文件在 auto mode 也特別提到：一進 auto mode，這類「等於直接給任意執行能力」的 allow rule 會被先拿掉，因為不這樣做的話 classifier 根本來不及看。

這其實也提醒了一件事：

你的 allowlist 不只是方便，也是邊界。

Claude permissions config 要怎麼寫？從 settings.json 開始

如果你最近搜的是 claude permissions config、claude allowlist、claude code permission mode，真正要找的通常不是 mode 名字而已，而是：

設定檔要放哪裡
allow / ask / deny 到底怎麼寫
defaultMode 要放在哪一層

依目前官方文件，Claude Code 的正式設定檔是 settings.json，最常見有三層：

檔案位置	用途	什麼時候用
`~/.claude/settings.json`	你的全域設定	每個專案都想套用
`.claude/settings.json`	專案共享設定	想跟團隊一起版本控制
`.claude/settings.local.json`	個人專案設定	想自己實驗，不想 commit

你也可以直接在互動模式用 /config 管理，但底層還是會寫回這套設定系統。

如果你問我新手第一份 permissions config 怎麼寫，我會先從這種版本開始：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)"
    ],
    "ask": [
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

這份設定背後的邏輯很簡單：

defaultMode 決定你開場要用哪個 permission mode
allow 放固定、低風險、可預期的動作
ask 放你每次都想再確認一次的動作
deny 直接擋掉敏感檔案或高風險命令

這裡有兩個實務重點很容易漏掉：

1. `ask` 和 `deny` 的優先級，比 `allow` 高

也就是說，你不能只想著怎麼放行，還要想著哪一些一定要卡住。

像 git push、讀 .env、碰 secrets/ 這種，我會建議你明講，而不是假設自己之後會記得。

2. `settings.json` 是制度層，allowlist 只是其中一部分

很多人把 permissions config 理解成「把 allowlist 寫進去」。

但更完整的理解應該是：

defaultMode 決定開場風險層級
allow / ask / deny 決定工具邊界
additionalDirectories 決定額外可讀寫範圍

也就是說，config 不是只在省 prompt，而是在定義 Claude Code 能走到哪裡。

如果你現在剛好也要把 @claude 接進 GitHub repo，那最值得一起對照的是 Claude GitHub App 怎麼裝？從 /install-github-app、權限到 @claude 排查完整指南（2026）。因為 repo 權限和本機權限，本質上是在解同一題：你願意先放多少權，哪些地方一定要留人工驗收。

Claude Code 為什麼會一直跳 permissions？

這大概是中文世界最容易出現的抱怨。

先講結論：如果你覺得「怎麼什麼都在問」，通常不是它壞了，而是下面幾個原因其中一個：

1. 你現在就在 `default`

那本來就會比 acceptEdits 更常被打斷。

2. 你沒有整理 allowlist

所以每次常見工具都得重新確認。

3. 你做的是高風險動作

像 shell、網路、外部工具，這些天生就比較容易被攔。

4. 你根本還沒搞清楚任務範圍

如果 prompt 很散，Claude 也比較容易做出看起來像「超出範圍」的動作，結果就被擋。

5. 你在 auto mode 裡被 classifier 連擋

官方文件也提到，如果 classifier 連續擋太多次，auto mode 會 fallback，重新回到提示模式。

所以如果你一直被問，不一定是沒開 auto，也可能是 auto 已經自己退回來了。

我會怎麼設 Claude Code 權限？

如果是我自己，我通常會這樣分。

情境 1：陌生 repo

plan

因為我現在最需要的是先看懂，而不是先改。

情境 2：小 bug 修補

acceptEdits

因為我要的是流暢，不是一直按允許。

情境 3：重要專案、敏感改動

default 或 plan

我會寧可慢一點，也不要太早給自主權。

情境 4：長時間 refactor，但方向已經很清楚

auto

前提是我知道這個任務範圍夠清楚，也知道自己等等還是會回來看結果。

情境 5：公司內部鎖很緊

dontAsk + 嚴格 allowlist

這比較像在做制度設計，不只是個人習慣。

Claude Code 權限設定最常見的 5 個錯誤

1. 一開始就想全開

這是最典型的錯。

很多人只是覺得提示很煩，就直接往 bypassPermissions 靠。
但那通常不是省事，是把未來的問題往前借。

2. 還沒看懂 repo，就切 `acceptEdits`

模式本身沒錯，順序錯。

如果你還沒理解上下文，改得再順也只是更快走歪。

3. 把 auto mode 當成安全保證

官方文件已經講了，它是 classifier 保護，不是絕對安全。

4. allowlist 放太寬

你以為自己在省時間，其實是在默默拿掉安全邊界。

5. 沒把 `CLAUDE.md` 寫好

這點很多人會忽略。

因為 classifier 也會吃 CLAUDE.md。
你的專案規則寫得越清楚，auto mode 的判斷就越有上下文。

如果你想看 CLAUDE.md 在 CI / issue / PR 層怎麼發揮作用，最適合對照 Claude Code GitHub Actions 教學：怎麼讓 @claude 幫你處理 issue 和 PR（2026）。

Claude Code 權限常見問題 FAQ

Claude Code 哪個 permission mode 最適合新手？

我會先推 plan 和 default。等你開始做小範圍修改，再慢慢過渡到 acceptEdits。

Claude Code auto mode 安全嗎？

比 bypassPermissions 安全很多，但不能取代人工 review。官方文件也明講它是 research preview。

Claude Code 為什麼一進 auto mode，某些 allow rule 會消失？

因為官方會先移除那些等於直接給任意執行能力的高風險 allow rule，避免 classifier 完全看不到真正危險的動作。

Claude Code 可以完全不要問我權限嗎？

可以，但你要分清楚你想要的是 dontAsk 還是 bypassPermissions。前者是只允許預先批准工具，後者是危險地跳過檢查，風險完全不同。

Claude Code 一直跳 permissions，最先該檢查什麼？

先看你目前 mode 是什麼，再看 allowlist 有沒有整理，最後再看你現在做的是不是本來就高風險的工具動作。

Claude permissions config 要寫在哪裡？

最常見有三層：~/.claude/settings.json、.claude/settings.json、.claude/settings.local.json。如果你想做團隊共享規則，就放專案裡的 .claude/settings.json；如果只是你自己想調整，放 settings.local.json 會比較穩。

結語：權限不是阻力，是你和 agent 之間的契約

很多人把 permission prompts 當成阻力，但我覺得更準確的理解是：

它是你跟 Claude Code 之間的契約。

你願意讓它做到哪裡、在哪裡停下來問你、什麼是可重複的低風險動作、什麼是一定要人類最後驗收的高風險動作，這些都不是多餘設計，而是 agent 真正進工作流之前必須先講清楚的事。

所以如果你問我 Claude Code 權限怎麼設最穩，我的答案不會是「哪個模式最強」，而是：

先用你現在驗收得了的模式。

你能穩定驗收，Claude Code 才真的會變成助理；不然它只會變成讓你更焦慮的自動化來源。

參考來源

資料最後查核日期：2026-04-04