把 Claude Code 從互動式終端機改成背景或腳本任務後,最容易被忽略的不是 prompt,而是權限邊界。它能讀哪些資料夾、哪些工具不需要詢問、哪些 shell 指令一定要擋下來,會直接決定自動化的風險範圍。
官方 CLI 文件提供了 --allowedTools、--disallowedTools、--permission-mode 與 --max-turns 等控制項。下面用「先讀、再改、最後才執行」的方式整理成一份實作前檢查表。
先決定這次任務應有哪種能力
先把任務切成三類,才不會一開始就給過大的權限。
| 任務 | 合理的最小能力 | 不該預設給的能力 |
|---|---|---|
| 程式碼導覽、報告 | 讀檔、git diff、git log | 編輯、安裝套件、寫入設定 |
| 小型修正 | 讀檔、編輯指定區域、相關測試 | 任意 shell 指令、刪除檔案 |
| 受控驗證 | 讀檔、編輯、明確列出的測試指令 | 跳過所有 permission prompt |
這個分類不是產品保證,而是實務上的權限設計:先從最小集合開始,缺什麼再補,而不是讓 agent 先拿到完整終端機再希望它永遠不會誤用。
用白名單允許可預期的讀取工作
Anthropic 文件說明,--allowedTools 可讓指定工具在不另外詢問的情況下執行;規則可對 Bash 指令使用 pattern。對只讀的工作,我會讓允許清單保持小而明確。
claude -p \ --allowedTools "Read" "Bash(git status *)" "Bash(git diff *)" "Bash(git log *)" \ "請檢查這個 PR 的變更,只列出風險,不要修改檔案。"注意 pattern 是權限規則,不是安全審查的替代品。若命令需要網路、憑證或會改寫資料,就不應因為「看起來常用」而放進白名單。
用拒絕規則封住不能碰的操作
--disallowedTools 可以移除整個工具,或拒絕特定 pattern。官方文件舉例指出,裸工具名稱會從模型可用工具中移除,而像 Bash(rm *) 的 scoped rule 只會拒絕符合的呼叫。
claude -p \ --disallowedTools "Bash(rm *)" "Bash(git push *)" "Bash(curl *)" \ "修正型別錯誤;只修改 src/,完成後執行 pnpm check。"這裡的重點不是列出所有危險命令,而是先列出此任務不需要卻可能造成外部影響的類別,例如刪除、推送、下載或部署。真正需要這些動作時,改成單獨一步並交由人確認。
不要把跳過確認當作預設值
--dangerously-skip-permissions 等同以 bypassPermissions 權限模式啟動。官方文件明確把它標成跳過 permission prompt 的選項;它適合隔離環境中的受控任務,不適合作為日常本機開發的預設。
如果只是要先釐清方案,可從 plan mode 開始:
claude --permission-mode plan \ "先分析目前測試為何失敗,列出根因與預計修改檔案;不要修改。"先拿到計畫,再以較窄的允許工具重新啟動實作,通常比在同一個 session 內逐步放寬權限更容易稽核。
非互動任務要限制 agent 回合數
自動化最怕的不是一次失敗,而是無限制重試。Claude Code 的 --max-turns 可限制非互動模式的 agentic turns;為每種任務設定合理上限,並把到達上限視為「需要檢查」而非「再跑一次」。
claude -p \ --max-turns 8 \ --allowedTools "Read" "Edit" "Bash(pnpm check)" \ "修正這個型別錯誤。完成標準:pnpm check 成功;若第 8 回合前無法完成,回報阻礙與目前 diff。"回合上限要搭配完成條件才有意義。沒有驗證標準時,agent 可能很快停下卻沒有解決問題;沒有上限時,失敗的方向又可能被反覆嘗試。
額外資料夾要當成新的存取面
--add-dir 會讓 Claude Code 能讀寫額外資料夾。官方文件也提醒,這些資料夾多數 .claude/ 設定不會被自動發現。實務上應把每個額外路徑當作一次新的權限審查:它是否包含 secrets、production 設定檔、客戶資料或其他 repository?
不確定時,先不要用 --add-dir。把需要的檔案複製到明確的工作區,或先以只讀報告確認必要性,再最小化新增路徑。
一個可拿來改的安全起點
claude -p \ --permission-mode plan \ --max-turns 4 \ --allowedTools "Read" "Bash(git status *)" "Bash(git diff *)" \ --disallowedTools "Bash(rm *)" "Bash(git push *)" "Bash(curl *)" \ "分析登入測試失敗的根因。不要修改檔案。輸出: 1. 涉及檔案;2. 根因證據;3. 最小修正方案;4. 需要的人為決策。"它的目標不是一次解完問題,而是先取得足以授權下一步的證據。確定修正範圍後,再另開一個只允許必要編輯與測試指令的 session。
這次要記住的事
自動化的安全性不在於某一個神奇旗標,而在於任務是否分段、每段是否只取得必要權限,以及是否能在回合耗盡時留下可讀的失敗證據。把讀取、修改與外部動作拆開,日後回頭查問題也會容易得多。
常見問題
Q: --allowedTools 和 --disallowedTools 可以一起用嗎?
A: 可以。前者用來讓特定工具或 pattern 免於詢問,後者用來移除工具或拒絕特定呼叫。實作前仍要檢查實際 pattern 是否只涵蓋這次任務需要的命令。
Q: 什麼時候可以用 --dangerously-skip-permissions?
A: 只在你已經隔離工作區、清楚限制可接觸資料,且任務本身經過審核時考慮。它會跳過 permission prompt,不應作為一般本機 repository 的預設設定。
Q: --max-turns 設多少才對?
A: 沒有通用數字。把它設成足以完成一輪定位、修改與驗證的範圍;若經常撞到上限,先檢查任務是否太大或完成條件不清楚,而不是直接無限加大。
參考資料:
回報錯字、失效連結,或告訴我你想看的延伸主題。