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 會保留，不受這項變更影響。組織透過 managed settings 部署的預設值也會保留。公告文章另行說明，在第一階段的推出期間，Enterprise 方案以及透過 API 使用的帳戶仍可選擇是否使用 auto mode。

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

Claude Code 權限模式：從最高監督程度到最低

共有 6 種模式。每行開頭的名稱，就是您在設定中寫入或傳給 --permission-mode 的值。

• 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 會加入循環。只有在以 --permission-mode bypassPermissions 或 --dangerously-skip-permissions 啟動工作階段時，bypassPermissions 才會加入循環。dontAsk 永遠不會出現在循環中，因此請使用 claude --permission-mode dontAsk 設定。

Auto 模式也需要近期的模型；這通常是它完全不顯示的原因。截至 2026 年 8 月，文件列出的支援模型包括 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 請求
• Push 到目前使用中 repository 的任何 branch

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

在依賴這項機制前，必須先了解兩項文件記載的限制。第一，分類器會看到你的訊息、tool call 以及 CLAUDE.md 內容，但不會看到 tool result。因此，Claude 讀取的檔案或網頁內文，無法直接影響分類器。第二，當分類器連續 3 次阻擋操作，或在同一個工作階段阻擋 20 次時，自動模式會暫停，Claude Code 會改回要求你確認。這些門檻無法設定。在搭配 -p flag 的非互動模式中，沒有可供提示的使用者，因此重複遭到阻擋時會直接中止工作階段。

第二種行為在遠端主機上尤其容易造成問題。無人值守的執行一旦達到限制，就會停止並等待沒有查看終端機的人員。另一半的解法是縮小 agent 的工作範圍；將 agent 引導至可行的最小變更的 skill，可避免工作階段偏離目標，執行分類器會阻擋的大範圍操作。

設定中的 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 規則無法設定例外。

在 auto mode 中，ask 是最實用的規則類型。auto mode 會移除例行提示，而 ask 規則會針對你希望由人員確認的特定命令重新加入提示。部署命令應放在這裡。如果你希望程式碼離開該主機前先經過確認，Bash(git push *) 也應放在這裡。將憑證檔案放在 deny 是另一個必要做法，並且可搭配一開始就讓 agent 無法接觸憑證。

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

• ~/.claude/settings.json：你的使用者設定，套用至每個專案。
• .claude/settings.json：專案設定，提交至 repository。
• .claude/settings.local.json：你針對單一 repository 的個人設定，不納入 git 追蹤。
• Managed settings：由管理員部署。在 Linux 上，該檔案是 /etc/claude-code/managed-settings.json。任何設定都無法覆寫 managed permission rule，包括 command line flag。

這裡有一個具有明確文件說明原因的陷阱。自 Claude Code v2.1.142 起，如果 defaultMode: "auto" 來自 .claude/settings.json 或 .claude/settings.local.json，就會被忽略，避免 repository 透過提供設定檔自行啟用 auto mode。若在該處設定這一行，session 會以 default mode 啟動，且不會在任何地方顯示錯誤。請將該行移至 ~/.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 mode 執行相同工作，而且可在任何範圍中生效。因此，您可以將它設定在自己的 ~/.claude/settings.json 中，禁止自己在凌晨 2 點操作正式伺服器時進入不應使用的模式。若伺服器供其他人使用，請改將兩者放在 /etc/claude-code/managed-settings.json 中，因為使用者設定檔屬於使用者，而受管理的設定檔不屬於使用者。

VPS 上的 auto mode 為何需要隔離邊界

分類器一次只檢查一個動作。它不會限制核准後的動作會執行什麼。文件清楚說明：

分類器是逐一動作的控制機制，不是隔離邊界。因此，無人值守執行仍可透過隔離邊界增加縱深防禦；但對 --dangerously-skip-permissions 而言，隔離邊界是必要條件。

因此，遠端主機的搭配應是 auto mode 加上可接受遺失的環境，而不是 bypassPermissions 加上僥倖。文件規定 bypass mode 只能用於隔離環境，例如沒有網際網路存取權的容器、虛擬機器或 dev container；在這些環境中，Claude Code 無法損害主機系統。執行資料庫與反向代理的 VPS 不屬於上述任何一種環境。

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

Claude Code 會自行強制執行 root 規則。在 Linux 與 macOS 上，若以 sudo 身分或 root 執行 bypass mode，它會拒絕啟動：

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

在識別出的 sandbox 內會略過這項檢查。因此，對於自主執行的容器工作，文件建議使用由非 root 使用者執行 Claude Code 的 dev container。如果你透過手機或筆記型電腦使用 SSH 驅動代理程式，同樣的原則也適用於 在 tmux 中持續執行的 Claude Code 工作階段：工作階段執行期間，沒有人會查看提示內容。

在 Ubuntu VPS 上設定 Bash sandbox

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

sudo apt-get install bubblewrap socat

啟動 Claude Code 並執行 /sandbox。面板會開啟 Mode 分頁與 Overrides 分頁，另有 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 則是獨立程序，會在主機上不受限制地執行。若要讓所有這些元件都位於同一個邊界內，請將完整的 Claude Code 程序執行於 container、virtual machine 或 @anthropic-ai/sandbox-runtime 套件中；截至本文撰寫時，該套件仍屬 beta research preview。

每種設定適合使用哪種模式？

自己筆電上的個人儲存庫

使用 auto，並針對希望繼續執行的操作設定 ask 規則。你就在鍵盤前，分類器的 fallback 確實能將請求交給你處理，而且損害範圍限於你控制的一台機器。14 August 的預設值就是為這種情況設計的。

共用 VPS

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

CI 與無人值守的工作階段

使用 dontAsk，並明確列出工作所需的命令，設定為 allow。沒有任何人會看到提示時，auto-deny 是正確的失敗模式。Auto mode 也會以非互動方式執行，但分類器重複阻擋時，會中止 -p 工作階段。因此，遇到這類阻擋的工作會在執行到一半時失敗，並留下未完成的工作。只有在容器或虛擬機器可依映像重新建置時，才使用 bypassPermissions；不要在同時執行重要服務的主機上使用。

FAQ

Claude Code 何時會將自動模式設為預設值？

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

在 VPS 上，我應使用自動模式還是 bypassPermissions？

使用自動模式，並搭配隔離邊界。分類器會在每個動作執行前進行審查，但文件明確指出，這是逐一動作套用的控制機制，不是隔離邊界。因此，無人值守的執行仍應使用 container、virtual machine，或可接受重建的主機。bypassPermissions 會完全略過檢查，文件僅建議在隔離環境中使用。Claude Code 在 Linux 上以 root 身分啟動此模式時會拒絕執行，並顯示 --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons。

如何禁止伺服器上的任何人使用自動模式或 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，就會被忽略。這可避免儲存庫透過提供設定檔自行啟用自動模式。工作階段會以 default 模式啟動，且不會顯示錯誤。請將設定移至 ~/.claude/settings.json，然後執行 /permissions，確認每項有效規則來自哪個檔案。若自動模式仍無法使用，請檢查模型需求：Sonnet 4.5 等較舊模型不受任何 provider 支援。