Claude Code Auto Mode 完整解析：取代 dangerously-skip-permissions 的智慧權限管理
Claude Code Auto Mode 在 2026 年 3 月 24 日正式推出研究預覽版，讓開發者不再需要在「逐一核准每個操作」和「跳過所有權限檢查」之間二選一。 Auto Mode 採用獨立的分類器模型，在每個工具呼叫執行前進行安全評估——低風險操作自動放行，高風險操作直接阻擋。目前支援 Claude Sonnet 4.6 和 Opus 4.6，Team 方案使用者即日可用，Enterprise 和 API 使用者近日開放。
這個功能解決的是 AI 編碼工具的老問題：權限提示疲勞。用 Claude Code 跑一個涉及 20 個步驟的重構任務，你得核准 30 次以上的權限請求。走開泡個咖啡回來，可能發現 Claude 還卡在第二步等你按確認。但如果改用 --dangerously-skip-permissions 旗標跳過所有檢查，2025 年底的社群災情已經證明了後果可以多嚴重。
Ewan Mak
為什麼需要 Auto Mode：從社群災情說起
2025 年 10 月，開發者 Mike Wolak 在 Ubuntu/WSL2 上用 --dangerously-skip-permissions 處理韌體專案。Claude Code 執行了一個從根目錄開始的 rm -rf 指令，錯誤日誌顯示數千筆「Permission denied」訊息橫跨 /bin、/boot、/etc 等系統路徑。所有使用者擁有的檔案全部消失。GitHub Issue #10077 有完整記錄。
2025 年 12 月，r/ClaudeAI 上出現了更廣為人知的事件：使用者請 Claude 清理舊版本庫裡的套件，Claude 生成了 rm -rf tests/ patches/ plan/ ~/，結尾的 ~/ 被 shell 展開為使用者的整個家目錄。桌面檔案、Keychain 密碼、應用程式資料全部消失。Simon Willison 在 X 上轉發後，這件事在 Hacker News 上拿到 197 點和超過 156 則留言。
LessWrong 上一位叫 avturchin 的評論者點出了核心矛盾：Claude 每小時大約產生 100 次權限請求，開發者根本不可能每次都認真讀完內容來判斷是否危險。結果就是無腦按確認，這種「權限噪音」製造的假安全感搞不好比沒有權限檢查更糟。
Auto Mode 的運作機制
Auto Mode 的核心是一個獨立的分類器模型，跑在 Claude Sonnet 4.6 上（即使你的主要工作階段用的是其他模型）。每個工具呼叫執行前，分類器會檢查三件事：
第一，操作是否超出任務範圍。你請 Claude 重構認證模組，它突然要去改資料庫 schema，分類器會擋下來。
第二，操作是否針對分類器不認識的基礎設施。預設情況下，分類器只信任工作目錄和目前 repo 的 remote。
第三，操作是否像是被惡意內容驅動。如果檔案裡藏了 prompt injection 指令試圖讓 Claude 批准不該批准的操作，分類器會偵測並阻擋。
安全的操作自動執行，不會跳出權限提示。有風險的操作被阻擋後，Claude 會嘗試用其他方式完成任務。如果 Claude 反覆嘗試被阻擋的操作，最終會跳出權限提示讓使用者介入。
Claude Code 四種權限模式比較
| 模式 | 行為 | 適用場景 | 風險等級 |
|---|---|---|---|
| Normal（預設） | 每個檔案寫入和 bash 指令都要核准 | 處理敏感程式碼、初次使用 | 最低 |
| Auto-Accept Edits | 自動接受檔案編輯，bash 指令仍需核准 | 原型開發、信任 Claude 的編輯判斷 | 低 |
| Plan | 唯讀模式，Claude 只做研究和規劃 | 需要先看全貌再動手的複雜任務 | 無（不執行操作） |
| Auto Mode（新） | 分類器自動判斷安全性，安全的放行、危險的阻擋 | 長時間重構、多步驟自動化 | 中——比 bypass 低，比 normal 高 |
| bypassPermissions | 跳過所有權限提示 | 只在容器或 VM 內使用 | 最高 |
怎麼啟用 Auto Mode
CLI 使用者：先用 claude --enable-auto-mode 啟用功能，然後在工作階段中按 Shift+Tab 循環切換到 auto 模式。狀態列會顯示目前使用的模式。
VS Code 使用者：進入 Settings → Claude Code，開啟 auto mode，然後在工作階段中從權限模式下拉選單選擇。
Desktop 使用者：同樣在 Settings → Claude Code 中開啟，再從權限模式選擇器切換。
管理員控制：Team 和 Enterprise 方案的管理員需要先在 Claude Code admin settings 中啟用 auto mode，使用者才能開啟。要停用的話，在 managed settings 中設定 "disableAutoMode": "disable"。
Auto Mode 的分類規則也可以自訂。執行 claude auto-mode defaults 可以看到預設的 environment、allow 和 soft_deny 清單。注意：設定 allow 或 soft_deny 會取代整個預設清單，所以一定要先複製完整的預設清單再修改，不要從空清單開始。
已知限制和注意事項
Anthropic 很直白地指出 Auto Mode 並不完美。分類器可能在以下情況放行有風險的操作：
使用者意圖不明確時。你說「清理一下 repo」，分類器不會把這解讀為授權 force-push。但如果你說「force-push 這個 branch」，分類器會允許。
Claude 對環境缺乏足夠脈絡時。如果 Claude 不知道某個目錄是生產環境的設定檔，它可能不會對修改操作特別警覺。
預設 allow list 包含 pip install -r requirements.txt，這意味著如果 requirements.txt 裡有未鎖定版本的惡意套件（供應鏈攻擊），auto mode 不會擋下來。Simon Willison 在 2026 年 3 月 24 日的評論中特別指出了這點。
另外，Auto Mode 會略微增加 token 消耗、API 費用和工具呼叫的延遲。對互動式開發來說影響不大，但用在自動化 pipeline 或整夜批次作業時，成本會累積。
Auto Mode 和 Claude Code Sandbox 的關係是什麼？
Claude Code 的 Sandbox 功能透過作業系統層級的隔離來限制檔案系統和網路存取，Auto Mode 則是在權限判斷層面加入 AI 分類器。兩者可以疊加使用——Sandbox 提供確定性的存取邊界，Auto Mode 減少邊界內的權限提示頻率。Anthropic 的 sandboxing 在內部測試中減少了 84% 的權限提示。
Auto Mode 支援哪些模型？
目前只支援 Claude Sonnet 4.6 和 Claude Opus 4.6。Haiku、claude-3 系列模型，以及第三方供應商（Bedrock、Vertex、Foundry）都不支援。分類器本身固定跑在 Sonnet 4.6 上。
Auto Mode 和 dangerously-skip-permissions 有什麼不同？
--dangerously-skip-permissions 跳過所有權限檢查，包括可能具破壞性的操作。Auto Mode 在每個操作前都跑一次安全分類，阻擋明顯危險的行為。但 Anthropic 仍然建議在隔離環境中使用 Auto Mode，因為分類器不是 100% 可靠。
子代理程式（Sub-agents）會繼承 Auto Mode 嗎？
會。如果父工作階段使用 auto mode，子代理程式會繼承 auto mode，子代理程式 frontmatter 中設定的 permissionMode 會被忽略。分類器使用與父工作階段相同的 block 和 allow 規則來評估子代理程式的工具呼叫。
Enterprise 環境下怎麼管理 Auto Mode？
Enterprise 管理員可以透過 managed settings 完全停用 Auto Mode（設定 "disableAutoMode": "disable"）。也可以用 MDM（如 Jamf、Intune）或設定檔來集中管控。分類規則可以在 managed settings 中統一設定，個別使用者無法覆蓋。
社群怎麼看：Reddit 和開發者圈的反應
Auto Mode 在 2026 年 3 月 24 日才正式推出，Reddit 上針對這個功能的討論還在形成中。但圍繞它要解決的問題——權限提示疲勞——r/ClaudeAI 已經累積了大量討論。
社群共識可以歸納為幾個方向：
多數開發者歡迎這個中間路線。 長期以來，r/ClaudeAI 上最常見的 Claude Code 抱怨就是權限提示太多。有人建立了 clauded="claude --dangerously-skip-permissions" 的 alias，有人用 Docker 容器搭配完全跳過權限的方式工作。Auto Mode 填補了「頻繁中斷」和「零防護」之間的空白。
安全社群持保留態度。 Simon Willison（prompt injection 這個詞的創造者）在 Auto Mode 發布當天表示，他對依賴 AI 做安全判斷的非確定性防護仍然存疑。他指出預設 allow list 包含 pip install -r requirements.txt 的供應鏈攻擊風險，並表示他更信任確定性的沙箱（限制檔案存取和網路連線）。安全研究公司 grith.ai 的分析更直接：Auto Mode 的風險評估和它評估的操作跑在同一個 context window 裡，prompt injection 如果污染了 Claude 的推理，權限判斷也會被一起污染。
GitHub Issues 顯示早期採用者遇到了可用性問題。 Issue #33587 記錄了 auto mode 在 macOS 上持續顯示「temporarily unavailable」，即使在設定檔中指定 "defaultMode": "auto" 也無法進入 auto mode。這是典型的研究預覽期初期問題。
「永遠在容器裡跑」仍然是共識。 不管是 Auto Mode 還是 --dangerously-skip-permissions，社群一致的建議是：不要在有真實 credentials、生產 API 或完整檔案系統存取的機器上跑自主模式。Anthropic 自己的工程師在用並行 Claude 建構 C 編譯器的 blog post 中，也是在容器裡跑 --dangerously-skip-permissions。
Auto Mode 在更大圖景中的位置
Auto Mode 跟 Claude Code 最近的幾個功能一起看比較清楚。Claude Code Review 在程式碼合併前自動抓 bug；Dispatch for Cowork 讓使用者把任務派給 AI 代理程式處理。三者勾勒出 Anthropic 的 agentic coding 藍圖：讓模型在例行的、邊界清楚的工作上主動執行，保留決策日誌，在風險升高時停下來或升級處理。
GitHub 的 2023 年研究顯示 AI 輔助可以把任務完成速度提高 55%。加州大學爾灣分校的研究則發現，知識工作者被中斷後平均要花超過 20 分鐘才能恢復專注。Auto Mode 試圖在這兩個數字之間找到平衡——保留 AI 輔助的速度優勢，用分類器過濾掉可能一秒鐘就抵消所有生產力收益的破壞性操作。
對團隊來說，評估 Auto Mode 的核心問題是：減少權限中斷帶來的生產力提升，是否值得承擔分類器偶爾判斷失誤的殘餘風險。答案取決於你的環境隔離程度和風險承受能力。
引用來源
- Anthropic — Auto mode for Claude Code（官方公告）
- Claude Code Docs — Permission Modes
- TechCrunch — Anthropic hands Claude Code more control, but keeps it on a leash
- Simon Willison — Auto mode for Claude Code
關於作者
Erik (EKC) ｜ Digital Strategy Director @ Tenten.co
我們團隊從 2025 年中開始把 Claude Code 導入日常開發流程，經歷了從 Cursor 到 Claude Code 再到全面 Agentic Coding 的轉型。在這個過程中，權限管理是我們花最多時間摸索的環節之一。早期我們也用過 --dangerously-skip-permissions 搭配 Docker 容器的組合，但在跨部門推廣時，這個方案的教育成本太高——非技術背景的同事很難理解為什麼需要 Docker。Auto Mode 讓「安全的自主運作」變得更平易近人，我認為這對 AI coding 工具的普及有實質意義。
如果你的團隊正在評估 Claude Code 的導入策略，或者想了解怎麼在 Enterprise 環境下設定合理的權限政策，歡迎跟 Tenten 團隊預約諮詢。
