你叫 Claude 跑個測試，它跳出來問「可以執行 npm test 嗎？」你按 yes。它要讀一個檔案，又問。要寫回去，再問。十分鐘內你按了十五次 yes，手指比腦袋還忙。到後來你乾脆眼睛都不看，看到框就按 Enter——而這正是最危險的瞬間，因為總有一次它要跑的是 rm -rf，而你已經被訓練成反射性點頭了。

這就是大部分人用 Claude Code 的真實狀態：不是太囉嗦，就是太放縱。中間那條剛剛好的線，其實藏在一個很多人沒打開過的設定系統裡。

先試了兩條死路

卡在這裡的人，通常會先試兩招。

第一招是無腦開 bypassPermissions——也就是俗稱的「危險模式」，全部自動同意，再也不問。爽是很爽，但這等於把家裡大門拆掉說「反正我家沒小偷」。哪天 Claude 理解錯一個指令，或是你跑了一個來路不明的 skill，沒有任何一道關卡會攔它。

第二招是回到 default 模式乖乖每次都按。安全是安全，但你會慢慢退化成那台只會點頭的機器，安全感是假的——因為真正出事的那次，你也一樣會按下去。

兩條路都錯在同一個地方：它們把「要不要信任」當成一個全有或全無的開關。但你心裡其實很清楚，npm test 跟 rm -rf / 不該被同一個 yes 管。權限系統要做的，就是把這個開關拆成一條一條可以分別設定的規則。

把它想成一間公司的門禁

權限系統聽起來很硬，但它的結構跟一間公司的門禁一模一樣，拆成這樣你就忘不掉了。

公司門口有三種名單。白名單（allow）：這些人直接放行，警衛看都不用看。黑名單（deny）：這些人一律擋下，誰說情都沒用。待確認名單（ask）：這些人來了，警衛打個電話問主管要不要放。

然後警衛本人有幾種值班模式。有時候他「照規矩辦」（default），名單上沒寫的就打電話問你；有時候是「裝修日」（acceptEdits），搬東西進出的工人不用問直接放，但其他人照舊；最猛的是「老闆說今天全放」（bypassPermissions），誰來都不擋。

這兩層——名單跟值班模式——合起來決定每一個動作的命運。搞懂它們怎麼互動，你就拿回了那條剛剛好的線。

三種名單寫在哪、怎麼寫

這些規則放在 settings.json 裡。它有三個層級，由廣到窄：

  • ~/.claude/settings.json：你個人全域的設定，所有專案都吃得到
  • .claude/settings.json：跟著專案走、會進 git 給整個團隊共用的設定
  • .claude/settings.local.json：只屬於你、不進版控的個人微調

規則的寫法是 工具名(模式)，工具名第一個字母大寫。幾個例子你一看就懂：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Read",
      "Edit"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(./.env)",
      "Bash(curl:*)"
    ],
    "ask": [
      "Bash(git push:*)"
    ]
  }
}

Bash(npm run test:*) 那個星號是前綴萬用字元，意思是「只要是 npm run test 開頭的指令都放行」，所以 npm run test:unit、npm run test:e2e 都不用再問。Read(./.env) 則是把你的密鑰檔關進黑名單——就算你哪天手滑開了危險模式，這條 deny 依然擋得住。MCP 工具也能管，格式是 mcp__伺服器名__工具名，想整包放行就寫 mcp__那個server__*。

這裡有個設計上很漂亮的細節：deny 規則沒辦法用 &&、||、|、; 串指令繞過去。你不能把 rm -rf 藏在一串看似無害的指令後面偷渡，系統會拆開來檢查。這代表你的黑名單是真的黑名單，不是裝飾品。

規則跟模式打架時，誰說了算

這是整個系統最關鍵、也最少人搞懂的一段：當一個動作進來，Claude 是照什麼順序判斷的。

順序是固定的三步：

  1. 先查黑名單（deny）。中了，直接擋，後面什麼都不用看。
  2. 再看現在的值班模式。如果是 bypassPermissions，走到這步的全放；如果是 acceptEdits，檔案編輯類的放行；其他模式就繼續往下。
  3. 最後查白名單（allow）。中了就放行；都沒中，才跳出來問你。

順序為什麼重要？因為 deny 永遠贏。哪怕你開了全放模式、哪怕同一個東西也寫在 allow 裡，只要它中了 deny，就是擋。這就是為什麼把 .env、把 rm -rf 寫進 deny 是門好生意——它是你最後、也最硬的一道防線，不受任何模式影響。

五種值班模式快速記一下：default（照規矩問）、acceptEdits（放行檔案操作，連 mkdir、mv、cp 這些都算）、plan（只規劃不動手）、dontAsk（任何要問的一律當成拒絕，只跑事先核准的）、bypassPermissions（全放，但 Hooks 還是會跑、還是能擋）。注意最後那句——就算全放，Hooks 仍然是你能插進去的最後一個攔截點。

不想手寫？讓它自己幫你產

講到這你可能想：道理懂了，但要我一條條回想平常按過哪些 yes、再手寫進 json，也太累。

剛好有個現成的做法：/fewer-permission-prompts。它會去翻你過去的對話紀錄，統計出那些你每次都按 yes、又明顯是唯讀或安全的指令（像各種 git status、ls、查詢類的 MCP 呼叫），然後幫你整理成一份排好優先序的 allow 清單，直接寫進專案的 settings.json。等於把你過去的點頭習慣，一次固化成規則。跑一次，之後那些重複的詢問就消失了。

想隨時看現在到底生效了哪些規則，用 /permissions 就能叫出來檢視跟編輯，不用自己去翻三層設定檔猜哪條蓋過哪條。

回到那十五次 yes

現在再回到開頭那個畫面。正確的姿勢不是去調「要不要每次問」這個總開關，而是花十分鐘把你的信任拆細：把每天都在跑、零風險的測試跟讀檔丟進 allow，把碰得到密鑰跟會刪東西的丟進 deny，剩下真正該你拍板的——git push、改設定檔、裝新套件——留在 ask。設好之後，那十五次點頭會縮到剩兩三次，而且每一次都落在真正需要你判斷的地方。

這背後其實是一個更通用的心法：自動化的價值不在「全自動」，而在於你把判斷力精準地放在哪幾個點上。 把所有事都交出去跟什麼都自己扛，是同一種懶——前者懶得設規則，後者懶得想。值得花力氣的，永遠是中間那層分類。把這套想清楚了，下一步可以接著看 Plan Mode——讓 AI 在動手前先把計畫攤給你看，跟權限系統剛好是一前一後的兩道閘。

參考來源：Configure permissions - Claude Code Docs