跳轉到主要內容
自動模式讓 Claude Code 無需權限提示即可執行，方法是透過分類器路由每個工具呼叫，該分類器會阻止任何不可逆、破壞性或針對您環境外部的操作。使用 autoMode 設定區塊告訴該分類器您的組織信任哪些儲存庫、儲存桶和網域，以便它停止阻止常規內部操作。
自動模式可在 Anthropic API 上供所有使用者使用。在 Amazon Bedrock、Google Cloud Vertex AI 和 Microsoft Foundry 上，您必須先設定 CLAUDE_CODE_ENABLE_AUTO_MODE。如果 Claude Code 報告您的帳戶無法使用自動模式，請檢查完整要求，其中也涵蓋支援的模型和 Team 與 Enterprise 方案上的管理員啟用。
開箱即用，分類器只信任工作目錄和目前儲存庫的已設定遠端。推送到您公司的原始碼控制組織或寫入團隊雲端儲存桶等操作會被阻止，直到您將它們新增到 autoMode.environment。 有關如何啟用自動模式以及它預設阻止的內容，請參閱權限模式。本頁是設定參考。 本頁涵蓋如何：

​
分類器讀取設定的位置

分類器讀取與 Claude 本身載入的相同 CLAUDE.md 內容，因此您專案的 CLAUDE.md 中的「永遠不要強制推送」之類的指令同時引導 Claude 和分類器。從那裡開始了解專案慣例和行為規則。 對於跨專案應用的規則，例如受信任的基礎設施或組織範圍的拒絕規則，請使用 autoMode 設定區塊。分類器從以下範圍讀取 autoMode：
範圍檔案用途
一個開發人員~/.claude/settings.json個人受信任的基礎設施
一個專案，一個開發人員.claude/settings.local.json每個專案的受信任儲存桶或服務，gitignored
組織範圍受管設定分散到所有開發人員的受信任基礎設施
--settings 旗標或 Agent SDK內聯 JSON自動化的每次呼叫覆蓋
分類器不從 .claude/settings.json 中的共用專案設定讀取 autoMode，因此簽入的儲存庫無法注入其自己的允許規則。 來自每個範圍的項目會被合併。開發人員可以使用個人項目擴展 environment、allow、soft_deny 和 hard_deny，但無法移除受管設定提供的項目。因為允許規則在分類器內充當軟阻止規則的例外，開發人員新增的 allow 項目可以覆蓋組織 soft_deny 項目：組合是加法的，而不是硬策略邊界。
分類器是在權限系統之後執行的第二道門。對於無論使用者意圖或分類器設定如何都必須永遠不執行的操作，請在受管設定中使用 permissions.deny，它在諮詢分類器之前阻止操作，無法被覆蓋。

​
定義受信任的基礎設施

對於大多數組織，autoMode.environment 是您唯一需要設定的欄位。它告訴分類器哪些儲存庫、儲存桶和網域是受信任的：分類器使用它來決定「外部」的含義，因此任何未列出的目的地都是潛在的資料外洩目標。 預設環境清單信任工作儲存庫及其設定的遠端。若要在該預設值旁邊新增您自己的項目，請在陣列中包含字面字串 "$defaults"。預設項目會在該位置被插入，因此您的自訂項目可以在它們之前或之後。 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}
項目是散文，不是正規表達式或工具模式。分類器將它們讀取為自然語言規則。按照您向新工程師描述基礎設施的方式編寫它們。徹底的環境部分涵蓋：
  • 組織：您的公司名稱以及 Claude Code 的主要用途，例如軟體開發、基礎設施自動化或資料工程
  • 原始碼控制：您的開發人員推送到的每個 GitHub、GitLab 或 Bitbucket 組織
  • 雲端提供者和受信任的儲存桶：Claude 應該能夠讀取和寫入的儲存桶名稱或前綴
  • 受信任的內部網域：您網路內的 API、儀表板和服務的主機名稱，例如 *.internal.example.com
  • 關鍵內部服務：CI、工件登錄、內部套件索引、事件工具
  • 其他上下文：受管制行業的限制、多租戶基礎設施或影響分類器應將什麼視為風險的合規要求
一個有用的起始範本：填入括號中的欄位並移除任何不適用的行。 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}
您提供的上下文越具體，分類器就越能區分常規內部操作和資料外洩嘗試。 您不需要一次性填入所有內容。合理的推出：從預設值開始，新增您的原始碼控制組織和關鍵內部服務，這解決了最常見的誤報，例如推送到您自己的儲存庫。接下來新增受信任的網域和雲端儲存桶。隨著阻止出現，填入其餘部分。

​
覆蓋阻止和允許規則

三個額外的欄位讓您取代分類器的內建規則清單：autoMode.hard_deny 用於無條件安全邊界，autoMode.soft_deny 用於使用者意圖可以清除的破壞性操作，以及 autoMode.allow 用於例外。每個都是散文描述的陣列，讀取為自然語言規則。對於在分類器之前執行的工具模式型硬阻止，請使用 permissions.deny。 在分類器內，優先順序分為四個層級：
  • hard_deny 規則無條件阻止。使用者意圖和 allow 例外不適用。
  • soft_deny 規則接著阻止。使用者意圖和 allow 例外可以覆蓋這些。
  • allow 規則然後覆蓋匹配的 soft_deny 規則作為例外。
  • 明確的使用者意圖覆蓋剩餘的軟阻止：如果使用者的訊息直接且具體地描述 Claude 即將採取的確切操作，分類器允許它，即使 soft_deny 規則匹配。
一般請求不算作明確意圖。要求 Claude「清理儲存庫」不授權強制推送，但要求 Claude「強制推送此分支」則授權。 要放寬，當分類器重複標記預設例外不涵蓋的常規模式時，新增到 allow。要加強，對於預設值遺漏的特定於您環境的破壞性風險，新增到 soft_deny，或對於必須永遠不能跨越的安全邊界，新增到 hard_deny。要保留內建規則同時新增您自己的規則，請在陣列中包含字面字串 "$defaults"。預設規則會在該位置拼接，因此您的自訂規則可以在它們之前或之後，並且當內建清單在版本發佈中變更時，您繼續繼承更新。 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}
設定 environment、allow、soft_deny 或 hard_deny 中的任何一個而不包含 "$defaults" 會取代該部分的整個預設清單。沒有 "$defaults" 的 soft_deny 陣列會丟棄每個內建軟阻止規則，包括強制推送、curl | bash 和生產部署。沒有 "$defaults" 的 hard_deny 陣列會丟棄內建資料外洩和安全檢查繞過規則。
每個部分獨立評估，因此單獨設定 environment 會保持預設 allow、soft_deny 和 hard_deny 清單完整。只在您打算完全掌控清單時才省略 "$defaults"。要安全地執行此操作，執行 claude auto-mode defaults 列印內建規則，將它們複製到您的設定檔案中，然後根據您自己的管道和風險容限檢查每個規則。

​
檢查預設值和您的有效設定

三個 CLI 子命令幫助您檢查和驗證您的設定。 將內建 environment、allow、soft_deny 和 hard_deny 規則列印為 JSON： 
claude auto-mode defaults
列印分類器實際使用的內容為 JSON，在設定的地方應用您的設定，否則使用預設值： 
claude auto-mode config
獲得關於您的自訂 allow、soft_deny 和 hard_deny 規則的 AI 反饋： 
claude auto-mode critique
在儲存設定後執行 claude auto-mode config 以確認有效規則是您期望的，並且 "$defaults" 已展開到位。如果您已編寫自訂規則，claude auto-mode critique 會檢查它們並標記模糊、冗餘或可能導致誤報的項目。如果您需要移除或重寫內建規則而不是在其旁邊新增，請將 claude auto-mode defaults 的輸出儲存到檔案，編輯清單，並將結果貼到您的設定檔案中以取代 "$defaults"。

​
檢查拒絕

當自動模式拒絕工具呼叫時，拒絕會記錄在 /permissions 下的「最近拒絕」標籤中。在拒絕的操作上按 r 將其標記為重試：當您退出對話框時，Claude Code 會傳送一條訊息告訴模型它可能重試該工具呼叫並繼續對話。 對同一目的地的重複拒絕通常意味著分類器缺少上下文。將該目的地新增到 autoMode.environment，然後執行 claude auto-mode config 確認它生效。 要以程式設計方式對拒絕做出反應，請使用 PermissionDenied hook。

​
另請參閱

  • 權限模式：自動模式是什麼、它預設阻止什麼以及如何啟用它
  • 受管設定：在您的組織中部署 autoMode 設定
  • 權限：在分類器執行之前應用的允許、詢問和拒絕規則
  • 設定：完整的設定參考，包括 autoMode 鍵