Claude Code auto mode 變更與權限模式比較

2026 年 8 月 14 日 auto mode 的變更

Claude Code 的 auto mode 會在不暫停等待你確認的情況下執行工具呼叫，並先將每個動作交由個別的 classifier model 審查。自 2026 年 8 月 14 日起，Pro、Max 和 Team 方案的新工作階段會以此模式啟動。你可以隨時切換模式，先前為自己設定的預設值不會被覆寫。

文件中的說明如下：

自 2026 年 8 月 14 日起，auto mode 會成為 Pro、Max 和 Team 方案中新工作階段的預設權限模式。你可以隨時切換模式。除非你接受一次性的切換提示，否則自行設定的預設值會維持不變；由組織管理的預設值也不會變更。

其中有兩個條款比日期更重要。你在自己的設定檔中設定的 defaultMode 不會因這項變更而改變。組織透過受管理設定部署的預設值也會維持不變。公告文章補充指出，在推出初期，Enterprise 方案和使用 API 的帳戶仍可選擇是否使用 auto mode。

如果你在 VPS（virtual private server）上執行 Claude Code，應在變更生效前閱讀相關說明。權限提示是需要有人操作鍵盤的檢查點。你通常不在遠端主機前，因此工作階段啟動時所使用的模式，可能會維持數小時。

Claude Code 權限模式：從監督最多到最少

共有 6 種模式。每行開頭的名稱就是您要寫入設定或傳給 --permission-mode 的值。這 6 種模式都由 Claude Code 本身強制執行，而非由模型執行，因為判斷工具呼叫可執行哪些操作，是模型周圍的 執行框架所負責的工作。

• default：Claude 每次使用新的工具前都會詢問。工作目錄內的讀取操作仍會直接執行，不會顯示提示。CLI（命令列介面）將此模式標示為 Manual；自 Claude Code v2.1.200 起，也接受 manual 作為別名。
• plan：Claude 會讀取檔案並執行命令以進行探索，但不會修改您的原始碼。您核准計畫前，編輯操作都會被阻擋。
• acceptEdits：檔案編輯會直接執行，不顯示提示；檔案系統命令 mkdir、touch、rm、rmdir、mv、cp 和 sed 也同樣適用。這只適用於工作目錄或 additionalDirectories 內的路徑。其他所有 shell 命令仍會顯示提示。
• auto：所有操作都會執行，但分類器會先檢查每個操作。明確指定的 ask 規則仍會強制顯示提示。
• dontAsk：Claude Code 會自動拒絕所有原本需要詢問您的操作。只有您的 allow 規則、內建的唯讀 Bash 命令，以及獲得 PreToolUse hook 核准的呼叫會執行。工作階段不會等待輸入。
• bypassPermissions：略過提示與安全檢查，包括寫入 .git 和 .claude 等受保護路徑的操作。

在工作階段中按下 Shift+Tab，即可依序在 default、acceptEdits 和 plan 之間切換。狀態列會顯示目前使用的模式，例如 ⏵⏵ auto mode on 或灰色的 ⏸ manual mode on。其他模式預設不會加入此循環。當您的帳戶符合 auto 的要求後，該模式才會加入循環。bypassPermissions 只有在以 --permission-mode bypassPermissions 或 --dangerously-skip-permissions 啟動工作階段時才會加入循環。dontAsk 永遠不會出現在循環中，因此請使用 claude --permission-mode dontAsk 設定它。

Auto 模式也需要較新的模型；它完全沒有出現時，通常就是這個原因。截至 August 2026，文件列出的支援項目包括 Anthropic API 上的 Claude Opus 4.6 或更新版本、Sonnet 4.6 或更新版本，以及 Fable 5。文件也指出，Sonnet 4.5 等較舊模型不受任何供應商支援。如果 Claude Code 回報 Auto 模式無法使用，表示其中一項要求未符合。這不是暫時性服務中斷，因此等待也無法解決問題。

有兩項控制在所有模式中都有效，包括 bypassPermissions：deny 規則與明確的 ask 規則。無論工作階段以哪種模式啟動，這兩項都是您始終保有的控制手段。

自動模式分類器會阻擋的內容

分類器是第二個模型，會讀取待執行的動作，判斷該動作是否符合你的要求。文件用一句話說明它的工作：

獨立的分類器模型會在動作執行前進行審查，阻擋任何超出要求、針對未識別基礎架構，或疑似受到 Claude 讀取的惡意內容驅動的動作。

以下是預設會阻擋的項目，也是伺服器操作人員最常遇到的類別：

• 下載並執行程式碼，例如 curl | bash
• Production deploy 與 migration
• Force push
• 修改共用基礎架構
• 建立 tunnel 或 reverse shell，讓本機服務可從公開網際網路連線
• 將有效的 credential 或 token 列印到文字記錄或檔案

以下是預設允許的項目：

• 在工作目錄中操作本機檔案
• 安裝 lock file 或 manifest 宣告的相依套件
• 唯讀 HTTP 請求
• 推送至目前操作之 repository 的任何 branch

不要只根據上述摘要操作。執行 claude auto-mode defaults，以 JSON 列印完整規則清單，並閱讀隨目前安裝版本提供的規則集合。

在依賴這項功能前，必須注意兩項文件記載的限制。第一，分類器會看到你的訊息、工具呼叫及 CLAUDE.md 內容，但工具結果會被移除。因此，Claude 從檔案或網頁讀取的文字，無法直接影響分類器。第二，當分類器連續 3 次阻擋動作，或在同一個工作階段阻擋 20 次時，自動模式會暫停，Claude Code 會改回要求你確認。這些閾值無法設定。在使用 -p flag 的非互動模式中，沒有人可以回應提示，因此重複遭到阻擋時，工作階段會直接中止。

第二種行為在遠端主機上尤其容易造成問題。無人值守的執行一旦達到限制就會停止，並等待沒有查看終端機的人員處理。相同主機上的第二個 Claude Code 工作階段不能取代該人員，因為 從一個工作階段傳送至另一個工作階段的文字 會暫存到接收工作階段取得為止，而暫停在權限提示的工作階段仍需要人工回應。縮小 agent 的工作範圍是另一半的解法，而 促使 agent 採用可行最小變更的 skill 能避免工作階段偏離到分類器會阻擋的大範圍動作。skill 會引導單一工作，而 output style 會直接修改 system prompt。因此，要求進行小幅、精準變更的 style，會套用於整個工作階段的每一輪，而不只套用於啟動它的單一工作。

settings.json 中的模式設定位置

以上內容都屬於設定檔中的同一個物件。

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

規則會依序評估：deny、ask，然後是 allow。依此順序比對後，第一個符合的規則會決定結果；較具體的規則不會優先於前面較寬泛的規則。針對 Bash(aws *) 的 deny 規則會封鎖 aws s3 ls，即使你也允許了該確切命令。因此，deny 規則無法包含例外。

ask 是在自動模式中真正發揮作用的規則類型。自動模式會移除例行提示，而 ask 規則會針對你希望由人員確認的特定命令重新顯示提示。部署命令應放在這裡。如果你希望在程式碼離開此主機前設置檢查點，Bash(git push *) 也應放在這裡。將憑證檔案放在 deny 是另一項必要措施，並且可搭配一開始就避免讓 agent 接觸憑證。

設定檔本身依優先順序排列如下，越前面的優先順序越低：

• ~/.claude/settings.json：你的使用者設定，套用至每個專案。
• .claude/settings.json：專案設定，提交至 repository。
• .claude/settings.local.json：你針對單一 repository 的個人設定，不納入 git 追蹤。
• 由管理員部署的受管理設定。在 Linux 上，該檔案是 /etc/claude-code/managed-settings.json。任何內容都無法覆寫受管理的權限規則，包括命令列旗標。

這裡有一個陷阱，而且原因已有文件說明。自 Claude Code v2.1.142 起，若 defaultMode: "auto" 來自 .claude/settings.json 或 .claude/settings.local.json，就會被忽略；這是為了避免 repository 透過提供設定檔自行啟用自動模式。若將該行設定在那裡，工作階段會以 default 模式啟動，且不會在任何地方顯示錯誤。請將該行移至 ~/.claude/settings.json。執行 /permissions，即可列出每個作用中的規則及其來源檔案。

關閉模式的兩個開關

管理員有兩個停用開關，兩者都接受字串 "disable"，而不是布林值。

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

文件明確說明應將它們放在哪裡：

若要防止使用 bypassPermissions 或 auto 模式，請在任何設定檔中，將 permissions.disableBypassPermissionsMode 或 permissions.disableAutoMode 設為 "disable"。這些設定最適合用於無法覆寫的受管理設定。

disableAutoMode 會從 Shift+Tab 週期中移除 auto，並在啟動時拒絕 --permission-mode auto。disableBypassPermissionsMode 對 bypass 模式執行相同工作，而且可在任何範圍中生效。因此，您可以將它設在自己的 ~/.claude/settings.json 中，避免自己在正式伺服器上凌晨 2 點想使用某個不該使用的模式。若伺服器供其他人使用，請改將兩者放在 /etc/claude-code/managed-settings.json 中，因為使用者設定檔屬於使用者，而受管理設定檔不屬於使用者。

為什麼 VPS 的自動模式需要隔離邊界

分類器會逐一檢查每個動作。它不會限制核准後的動作接下來能做什麼。文件清楚說明：

分類器是每個動作的控制機制，不是隔離邊界。因此，無人值守執行時仍需要隔離邊界來提供縱深防禦；但對 --dangerously-skip-permissions 而言，隔離邊界是必要條件。

因此，遠端主機應搭配自動模式與你願意捨棄的環境，而不是使用 bypassPermissions 再抱持僥倖。文件只建議在隔離環境中使用繞過模式，例如沒有網際網路存取權的容器、虛擬機器或開發容器；在這些環境中，Claude Code 無法損害主機系統。執行資料庫與反向代理的 VPS 不屬於上述任何一種環境。

伺服器上的安全措施主要有 3 項。以一般使用者身分執行 Claude Code，絕不要使用 root。為該使用者提供工作目錄，不要讓它能讀取其他有價值的內容。與其修復主機，不如重新建置主機；這也是每次工作完成後丟棄一次性 VM的理由。從建立使用者到設定防火牆規則，這些措施背後的強化細節已涵蓋於在 VPS 上執行 Claude Code 的完整安全檢查，因此此處不再重複。

Claude Code 會自行強制執行 root 規則。在 Linux 和 macOS 上，若使用 sudo 或以 root 身分執行，它會拒絕以繞過模式啟動：

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

在辨識出的沙箱內會略過這項檢查。因此，文件對自主容器工作的建議，是使用以非 root 使用者執行 Claude Code 的開發容器。若你是透過 SSH 從手機或筆記型電腦控制代理程式，在 tmux 中維持長時間執行的 Claude Code 工作階段也適用相同的原則：工作階段執行期間，沒有人會監看提示。所有操作都必須先通過登入；因此，如果主機以 Permission denied (publickey) 拒絕你的連線，詳細的 SSH 輸出會告訴你實際遇到的 5 種故障是哪一種。

在 Ubuntu VPS 上設定 Bash sandbox

內建 sandbox 會限制 Claude 執行的每個 Bash 命令對檔案系統與網路的存取，作業系統也會將這些限制套用到子程序。在 Linux 上需要安裝 2 個套件。

sudo apt-get install bubblewrap socat

啟動 Claude Code 並執行 /sandbox。面板會開啟 Mode、Overrides 和 Dependencies 分頁，Dependencies 會列出目前缺少的項目。相依性檢查會在啟動時執行，因此安裝套件後請重新啟動 Claude Code，否則面板仍會將這些套件顯示為缺少。

在 Ubuntu 24.04 及更新版本中，預設的 AppArmor policy 會阻止 bubblewrap 建立所需的 user namespace，因此 sandbox 無法啟動。請確認該設定是否套用到您的系統：

sysctl kernel.apparmor_restrict_unprivileged_userns

出現 0，或顯示找不到該 key 的錯誤，表示不需要進行任何處理。出現 1 則表示 bwrap 需要自己的 profile：

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

此 profile 套用至 bwrap 本身，不會套用至其在 sandbox 內執行的命令。接著在設定中縮小限制範圍：

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

這段內容應放在專案的 .claude/settings.json 中，因為只有從專案設定解析 . 時，它才會指向專案根目錄。若將相同內容放入 ~/.claude/settings.json，. 會改為解析至 ~/.claude，因此 denyRead 規則會持續封鎖專案檔案，且每個命令都無法讀取其預定編輯的程式碼。

請了解這項設定未涵蓋的範圍。sandbox 會限制 Bash 及其子程序。內建檔案工具會在 Claude Code 程序內執行，而 MCP（model context protocol）伺服器和 hooks 則是獨立程序，會在主機上不受限制地執行。若要將這些程序全部置於同一個限制範圍內，請在 container、virtual machine 或 @anthropic-ai/sandbox-runtime package 中執行整個 Claude Code 程序；撰寫本文時，該 package 仍是 beta research preview。

每種設定適合哪種模式？

自己筆電上的個人儲存庫

使用 auto，並針對希望繼續執行的操作設定 ask 規則。您本人就在鍵盤前，分類器的後備機制確實能聯絡到您，而且損害範圍限於您控制的一台機器。14 August 的預設值就是為此情境設計的。

共用 VPS

對每位使用者分別使用 auto，並在各使用者自己的 ~/.claude/settings.json 中設定。執行 Claude Code 的帳戶不得是 root，也不得讀取其他使用者的工作內容。在 /etc/claude-code/managed-settings.json 中將 disableBypassPermissionsMode 部署為 "disable"，並一併加入保護共用路徑的拒絕規則。共用主機最能清楚說明為何 bypassPermissions 不適用，因為該模式假設存在的隔離邊界並不存在：其他租戶就在這個邊界內。

CI 與無人值守工作階段

使用 dontAsk，並明確列出工作所需的命令，設定 allow。沒有任何人會看到提示時，自動拒絕是正確的失敗模式。Auto mode 同樣會以非互動方式執行，但分類器反覆封鎖操作時，會中止 -p 工作階段。因此，工作若遇到這些封鎖，會在完成一半時失敗。將 bypassPermissions 限定用於可從映像重新建置的容器或虛擬機器，並避免在同時執行重要服務的主機上使用。

FAQ

Claude Code 何時會將 auto mode 設為預設模式？

自 2026 年 8 月 14 日起，Pro、Max 與 Team 方案的新工作階段會採用此設定。文件補充說明，您可以隨時切換模式；自行設定的預設模式會維持不變，除非您接受一次性的切換提示；由組織管理的預設模式則不會變更。公告指出，在首階段推出期間，Enterprise 方案及使用 API 的帳戶仍可選擇不啟用 auto mode。請查看狀態列，確認工作階段目前實際使用的模式；auto mode 會顯示 ⏵⏵ auto mode on。

在 VPS 上，我應該使用 auto mode 還是 bypassPermissions？

使用 auto mode，並搭配隔離邊界。分類器會在每個動作執行前進行檢查，但文件明確指出，這是逐一動作的控制機制，不是隔離邊界。因此，無人看管的執行環境仍需要容器、虛擬機器，或一台您願意重新建置的主機。bypassPermissions 會完全略過檢查，文件僅建議在隔離環境中使用。Claude Code 在 Linux 上以 root 身分啟動此模式時會拒絕啟動，並顯示 --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons。

如何禁止伺服器上的所有人使用 auto mode 或 bypass mode？

在 /etc/claude-code/managed-settings.json 中，將 permissions.disableAutoMode 和 permissions.disableBypassPermissionsMode 設為字串 "disable"。受管理的設定優先於所有其他範圍，因此任何使用者設定檔或命令列旗標都無法覆寫這些設定。disableAutoMode 會從 Shift+Tab 循環中移除 auto，並在啟動時拒絕 --permission-mode auto。disableBypassPermissionsMode 也可從任何範圍生效，因此單一使用者可以在自己的 ~/.claude/settings.json 中設定它。

為什麼我的 defaultMode: "auto" 設定未生效？

因為設定位於錯誤的檔案中。從 Claude Code v2.1.142 起，若 defaultMode: "auto" 來自 .claude/settings.json 或 .claude/settings.local.json，就會被忽略，避免存放庫透過提供設定檔自行授予 auto mode。工作階段會以 default 模式啟動，且不會顯示錯誤。請將設定移至 ~/.claude/settings.json，然後執行 /permissions，確認每項作用中規則的來源檔案。若 auto mode 仍無法使用，請檢查模型需求：Sonnet 4.5 等較舊模型不受任何 provider 支援。