Claude Code 無人值守模式的權限管理最佳實踐

最初發布於 Unattended。對於無人值守的 Claude Code 執行，最佳實踐的原則很簡單：工作可以觸及的每個工具呼叫，都應在 settings.json 中明確設定為允許或拒絕。

不應將任何操作留給提示詞處理。請在 dontAsk 或 auto 模式下執行 claude -p，並添加 --permission-prompts none 旗標，官方文件建議「當無人可回應權限提示時，例如在排程工作中」使用此旗標。同時，為破壞性與對外連線指令保留一份拒絕清單，並將 --dangerously-skip-permissions 僅用於拋棄式容器。

哪種選項適合你？如果這是你首次的夜間工作，請從 dontAsk 模式下，使用範圍受限的允許清單開始。一旦你信任此設定，即可轉為 auto 模式。僅在一次性沙盒中使用 bypass 模式。

你的情況：初學者，首次排程工作，請選擇 --permission-mode dontAsk 並在 .claude/settings.json 中加入簡短的允許清單，然後設定權限。對於專業版、Max 版或團隊版每日重複性工作，請選擇 --permission-mode auto --permission-prompts none 並加入拒絕清單，然後選擇權限模式。

如果預算有限或使用按用量計費的 API 金鑰，請選擇 dontAsk 搭配 --bare，這樣工作只會執行你列出的內容，不會載入額外項目，以程式化方式執行 Claude Code。如果工作在沒有機密資訊的拋棄式容器或虛擬機器中執行，請選擇 bypassPermissions 並限制網路。

對於開發容器，如果你需要 glob 無法表達的規則（例如「僅推送到 bot/* 分支」），請使用 PreToolUse 鉤子腳本。

為什麼初學者要用 dontAsk 模式：它會拒絕所有原本會觸發提示的呼叫，因此規則遺漏最糟的結果就是跳過某個步驟。你永遠不會遇到意外的動作。為什麼日常工作要用 auto 模式：分類器會判斷你未預料到的長尾指令。其權衡是可預測性較低。

Claude Code 的權限模式（允許、詢問、拒絕）是什麼？Claude Code 權限規則有三種結果：允許、詢問和拒絕，它們的評估順序是先拒絕、再詢問、然後允許。第一個符合的規則勝出。除了規則之外，權限模式決定了沒有規則涵蓋的呼叫會如何處理。這個順序是無人值守設計的關鍵事實，特異性並不重要。

廣泛的 Bash(aws *) 拒絕規則會阻擋 aws s3 ls，即使你明確允許該指令。詢問規則以同樣方式優先於允許規則：即使有更精確的允許規則符合，符合的詢問規則仍會觸發提示（權限文件）。有些呼叫根本不需要任何規則。在手動模式（設定值 default）下，工作目錄內的檔案讀取和 Grep 操作無需批准。

內建的唯讀 Bash 指令集也是如此。編輯、其他 shell 指令、WebFetch 和 WebSearch 則需要批准（權限文件）。

截至 2026 年 10 月的模式（權限模式，無人值守文件）：default（手動）模式僅讀取，在 -p 模式下，未經批准的呼叫會被拒絕。這沒問題，但你的允許清單涵蓋所有內容。acceptEdits 模式允許讀取、檔案編輯、常見檔案系統指令（mkdir、touch、mv、cp），適用於程式碼檢查/格式化工作。

其他 shell 和網路呼叫仍需要允許規則。plan 模式不執行任何操作；Claude 僅提出建議，適用於夜間「僅報告」工作。auto 模式執行大部分操作，由分類器模型審核，適用於多樣化的日常任務。dontAsk 模式僅執行無需批准的操作，加上你的允許規則，是 CI 和 cron 最可預測的選擇。

bypassPermissions 模式執行所有操作，包括寫入 .git 和 .claude 等受保護路徑，僅限於隔離的容器/虛擬機器。

對於排程工作，有兩個版本注意事項很重要。從 v2.1.302 開始，當未設定權限模式時，claude -p 執行會以手動模式啟動。從 v2.1.283 開始，auto 模式成為互動式終端機和 VS Code 會話的內建啟動模式。結果是，你在互動模式下測試的工作可能與 cron 工作以不同模式執行。務必明確設定模式。

如何為權限規則設定 settings.json？將權限規則放在 settings.json 的 permissions 鍵下。將它們列在 Tool 或 Tool(pattern) 字串的 allow、ask 和 deny 陣列中。根據規則適用對象選擇檔案（設定文件）：~/.claude/settings.json 適用於你，在每個專案中；.claude/settings.json 適用於此儲存庫中的所有人（提交它）；.claude/settings.local.json 僅適用於你，在此儲存庫中；managed-settings.json 適用於你的組織，它會覆寫所有其他設定。

對於排程工作，請使用已提交的專案檔案。這樣，規則會隨儲存庫傳輸到執行工作的任何機器。步驟：在你的儲存庫根目錄中，如果 .claude/settings.json 不存在則建立它。添加一個包含 defaultMode、allow 和 deny 陣列的 permissions 物件。

對於無人值守的儲存庫，將 ask 留空。儲存檔案。在互動式會話中，輸入 /permissions 查看 Claude Code 載入的規則。提交檔案，以便你的 cron 主機獲得相同的規則。

範例：夜間「修復失敗測試並提交」工作。這是一個可供調整的範例。將 npm 替換為你自己的工具鏈。

{

"permissions": {

"defaultMode": "dontAsk",

"allow": [

"Edit",

"Bash(npm test)",

"Bash(npm test *)",

"Bash(npm run lint)",

"Bash(npm run lint *)",

"Bash(git status)",

"Bash(git diff *)",

"Bash(git log *)",

"Bash(git add *)",

"Bash(git commit *)"

],

"ask": [],

"deny": [

"Bash(git push *)",

"Bash(rm *)",

"Bash(curl *)",

"Bash(wget *)",

"Bash(sudo *)",

"Read(./.env)",

"Read(./.env.*)",

"Read(./secrets/**)",

"WebFetch"

]

}

}

Read 和 Edit 的路徑語法遵循 gitignore 規則。每個前綴都有不同的含義（權限文件）：Pattern //Users/alice/secrets/** 匹配從檔案系統根目錄的絕對路徑。~/Documents/*.pdf 匹配從你的家目錄的路徑。

/src/**/*.ts 匹配相對於設定檔的專案。./.env 或 *.env 匹配相對於目前目錄。一個常見錯誤是寫 Read(/etc/passwd) 並期望它是絕對路徑。單一前導斜線表示「相對於設定來源」。對於絕對路徑，你需要 //。

如何讓 Claude Code 無人值守執行而不被權限提示停止？要讓 Claude Code 無人值守執行，請使用 claude -p，明確設定模式，並添加 --permission-prompts none。然後確保工作所需的所有呼叫都由允許規則涵蓋。

「停止」以三種不同方式發生，每種都有其解決方案：工作執行互動式 claude 而非 claude -p。互動式會話等待按鍵，但從未發生。解決方案：在 cron、CI 和 launchd 中務必使用 -p。

工作有一個權限主機，但無人回應。這可能是一個帶有 canUseTool 回呼的 Agent SDK 應用程式，或透過 --permission-prompt-tool 傳遞的 MCP 工具。如果沒有 --permission-prompts none，文件指出你的執行會等待該主機回應每個權限請求。

解決方案：添加該旗標（v2.1.259 或更高版本）。工作「完成」但跳過了工作。在手動模式的 -p 執行中，「需要批准的呼叫會被拒絕，除非有東西批准它」（無人值守文件）。不會卡住。Claude 無法執行 npm test，因此它會寫一份禮貌的摘要並以 0 退出。這是最常見的靜默失敗，解決方案是提供完整的允許清單（參見下面的預檢部分）。

排程工作的指令：cd /path/to/repo && claude --bare -p "Run the test suite, fix failures, and commit the fix" --permission-mode dontAsk --permission-prompts none --settings .claude/settings.json --output-format json > /var/log/claude-nightly.json。

每個旗標的用途：--bare 會跳過 hooks、skills、plugins、MCP 伺服器、自動記憶體和 CLAUDE.md 的自動探索。文件稱其為「腳本和 SDK 呼叫的推薦模式」。因為 bare 模式不會自動讀取你的專案檔案，所以要使用 --settings 明確傳遞設定檔。

另請注意，bare 模式需要 ANTHROPIC_API_KEY（或 apiKeyHelper），因為它從不讀取 OAuth 憑證或系統金鑰鏈。如果你使用 Pro/Max 訂閱登入，請移除 --bare 並接受專案 hooks 和 .mcp.json 伺服器將會載入。

--permission-prompts none 會移除需要人工介入的工具，例如 AskUserQuestion。它還會告訴 Claude 不要重試被拒絕的請求，這樣執行就不會浪費回合（無人值守文件）。--output-format json 會提供 permission_denials 供你早上審查。

有關排程方面（crontab 條目、環境變數、日誌記錄），請參閱 Claude Code Cron Job Setup: Run Automations Overnight。對於因權限以外的原因而停止的工作，Why Claude Code Stops Mid-Automation (and How to Fix It) 涵蓋了其餘部分。

夜間工作選擇 dontAsk 還是 auto？當任務每晚都相同，例如執行測試或重新生成文件時，請選擇 dontAsk。當任務多變且你無法預先列出所有指令時，請選擇 auto。Auto 模式有一些值得了解的限制。它需要最新模型：根據功能可用性頁面，這表示 Opus 4.6+、Sonnet 4.6+、Haiku 5.5 或 Fable 模型。

在互動式會話中，auto 模式在分類器連續阻擋 3 次或總共 20 次操作後會暫停並返回提示。在 -p 執行中，Claude Code 不會在這些閾值處停止執行。

計費取決於設定。在 Pro、Max 和團隊版計畫中，分類器呼叫不再計入使用限制，但在 LLM 閘道或代理後方，Claude Code 可能會發出自己的計費分類器請求。如果你透過其中一個路由，請檢查該頁面。如果你需要精確的可重現性或「模型決定」無法接受的稽核軌跡，auto 模式就不適合。

Claude Code 權限：專案設定 vs 使用者設定 vs CLI 旗標，哪個優先？對於像 defaultMode 這樣的單值鍵，Claude Code 使用以下優先順序：受管理設定、然後命令列、然後專案本地、然後共享專案、然後使用者。權限陣列不會互相覆蓋。它們會合併。根據設定文件：「較高層級設定的鍵會覆蓋較低層級設定的相同鍵」。

排名 來源 檔案/旗標 設定者：1 受管理 managed-settings.json、MDM 或 claude.ai console 組織；2 命令列 claude --settings、--permission-mode、--allowedTools 你，本次執行；3 專案本地 .claude/settings.local.json 你，此儲存庫；4 共享專案 .claude/settings.json 此儲存庫中的所有人；5 使用者 ~/.claude/settings.json 你，所有地方。

讓人困惑的部分是陣列。當 permissions.allow 或 permissions.deny 出現在多個檔案中時，Claude Code 會合併清單。因此，你使用者檔案中的拒絕規則會阻擋專案檔案中的允許規則，反之亦然。來自每個範圍的拒絕規則都會在任何允許規則之前檢查。

這對無人值守執行意味著：你的筆記型電腦和伺服器不同。你筆記型電腦 ~/.claude/settings.json 中的 Bash(npm *) 允許規則讓工作在本地執行。然後它會在沒有該檔案的 cron 主機上被拒絕。將工作所需的所有規則放入已提交的專案檔案中。

settings.local.json 通常被 gitignore。「不再詢問」批准你測試期間點擊的可能只存在於你的機器上。Bash 批准會依儲存庫和指令持續存在。將工作依賴的任何內容複製到 .claude/settings.json。

--allowedTools 是新增；它不會替換。命令列的允許無法撤銷任何檔案中的拒絕。本地檔案只能新增，不能移除。這是設計使然，這樣隊友就不能悄悄地移除共享的拒絕規則。如何為 bash/git 指令編寫安全的允許規則？為特定的指令和子指令編寫 Claude Code Bash 允許規則，例如 Bash(git commit *)，絕不是單純的 Bash 或 Bash(git *)。

匹配機制（權限文件，無人值守文件）：沒有 * 的規則匹配一個精確的指令。Bash(npm test) 僅允許 npm test，別無其他。* 匹配任何文字，包括空格。第一個 * 之前的所有內容限制了規則。空格的位置很重要：「* 之前的空格很重要」。

Bash(git diff ) 匹配 git diff --stat。Bash(git diff) 也匹配 git diff-index。Shell 運算符號會被理解。Bash(safe-cmd *) 不允許 safe-cmd && other-cmd。

每個依 &&、||、;、|、|&、& 或換行符號分割的部分都必須單獨匹配一個規則。

建立 git 允許清單的步驟：列出工作必須執行的操作：讀取狀態、差異、暫存、提交。為每個子指令編寫一條規則：Bash(git status)、Bash(git diff *)、Bash(git commit *)。