SpyBara
Go Premium

auto-mode-config.md 2026-06-29 23:02 UTC to 2026-06-30 23:02 UTC

63 added, 9 removed.

2026
Tue 30 23:02 Mon 29 23:02 Sat 27 01:01 Fri 26 23:00 Thu 25 23:58 Wed 24 22:02 Tue 23 22:00 Mon 22 23:59 Fri 19 22:58 Thu 18 22:00 Wed 17 17:02 Tue 16 21:57 Mon 15 23:02 Sat 13 21:59 Fri 12 22:00 Thu 11 23:01 Wed 10 23:57 Tue 9 06:34 Mon 8 06:52 Sat 6 06:24 Fri 5 06:45 Thu 4 06:52 Wed 3 06:53 Tue 2 06:51

Настройка режима auto

Сообщите классификатору режима auto, какие репозитории, бакеты и домены доверяет ваша организация. Установите контекст окружения, переопределите правила блокировки и разрешения по умолчанию и проверьте вашу эффективную конфигурацию с помощью подкоманд CLI auto-mode.

Auto mode позволяет Claude Code работать без запросов разрешения, маршрутизируя каждый вызов инструмента через классификатор, который блокирует все необратимое, деструктивное или направленное вне вашего окружения. Правила отказа и явного запроса оцениваются перед классификатором и по-прежнему блокируют или запрашивают разрешение. Используйте блок настроек autoMode, чтобы сообщить этому классификатору, какие репозитории, бакеты и домены доверяет ваша организация, чтобы он перестал блокировать обычные внутренние операции.

По умолчанию классификатор доверяет только рабочему каталогу и настроенным удаленным репозиториям текущего репо. Такие действия, как отправка в исходный контроль вашей компании или запись в командный облачный бакет, блокируются до тех пор, пока вы не добавите их в autoMode.environment.

Информацию о том, как включить режим auto и что он блокирует по умолчанию, см. в разделе Permission modes. Эта страница является справочником по конфигурации.

На этой странице рассматривается, как:

Where the classifier reads configuration

Классификатор читает то же содержимое CLAUDE.md, что загружает сам Claude, поэтому инструкция вроде "никогда не делай force push" в CLAUDE.md вашего проекта управляет как Claude, так и классификатором одновременно. Начните с этого для соглашений проекта и правил поведения.

Для правил, которые применяются ко всем проектам, таких как доверенная инфраструктура или организационные правила отказа, используйте блок настроек autoMode. Классификатор читает autoMode из следующих областей:

Область Файл Используется для
Один разработчик ~/.claude/settings.json Личная доверенная инфраструктура
Один проект, один разработчик .claude/settings.local.json Доверенные бакеты или сервисы для каждого проекта
Организация Managed settings Доверенная инфраструктура, распределенная всем разработчикам
Флаг --settings или Agent SDK Встроенный JSON Переопределения для каждого вызова для автоматизации

Классификатор не читает autoMode из общих настроек проекта в .claude/settings.json, поэтому проверенный репо не может внедрить свои собственные правила разрешения.

Записи из каждой области объединяются. Разработчик может расширить environment, allow, soft_deny и hard_deny личными записями, но не может удалить записи, которые предоставляют управляемые настройки. Поскольку правила разрешения действуют как исключения из правил блокировки внутри классификатора, запись allow, добавленная разработчиком, может переопределить запись организационного soft_deny: комбинация является аддитивной, а не жесткой границей политики.

Define trusted infrastructure

Для большинства организаций autoMode.environment — это единственное поле, которое вам нужно установить. Оно сообщает классификатору, какие репозитории, бакеты и домены являются доверенными: классификатор использует его для определения того, что означает "внешний", поэтому любой пункт назначения, не указанный в списке, является потенциальной целью утечки данных.

Начиная с Claude Code v2.1.195, claude auto-mode defaults выводит два вида записей окружения.

  • Слоты доверия: называют то, что классификатор рассматривает как находящееся внутри вашей границы. Слоты — это Trusted repo, Source control, Trusted internal domains, Trusted cloud buckets, Key internal services и Internal package registry. Записи repo и source-control по умолчанию указывают на рабочий репозиторий и его настроенные удаленные репозитории. Все остальные слоты доверия по умолчанию имеют значение None configured, поэтому ничего больше не доверяется до тех пор, пока вы это не добавите.
  • Слоты чувствительности: называют то, что защитные правила рассматривают как высокий риск. Слоты — это PII / regulated-data locations, Sensitive remote targets и Protected IaC scopes. Каждый по умолчанию использует широкую эвристику, например рассматривая любой хост или пространство имен, чье имя содержит prod или production, как чувствительную удаленную цель, поэтому защитные правила активны до того, как вы что-либо настроите. Указание конкретных целей в слоте чувствительности заставляет эти правила применяться к названным целям вместо эвристики.

Версии до v2.1.195 выводят только первые пять слотов доверия.

Чтобы добавить свои собственные записи наряду с значениями по умолчанию, включите буквальную строку "$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, реестры артефактов, внутренние индексы пакетов, инструменты для инцидентов
  • Внутренний реестр пакетов: приватный npm, PyPI или другой реестр, через который должны проходить установки, поэтому установки, которые обходят его для публичного реестра, блокируются
  • PII / regulated-data locations: бакеты, базы данных или пути, которые содержат личные или регулируемые данные, поэтому классификатор защищает эти местоположения вместо того, чтобы угадывать из содержимого
  • Sensitive remote targets: пространства имен, хосты или контейнеры, которые считаются production, поэтому удаленные оболочки и port-forwards в них требуют вашего явного одобрения
  • Protected IaC scopes: ресурсы инфраструктуры, чьи apply или destroy всегда должны требовать от вас назвать изменение
  • Дополнительный контекст: ограничения регулируемой отрасли, многопользовательская инфраструктура или требования соответствия, которые влияют на то, что классификатор должен рассматривать как рискованное

Записи Internal package registry, PII / regulated-data locations, Sensitive remote targets и Protected IaC scopes требуют Claude Code v2.1.195 или позже. Более ранние версии по-прежнему читают их как простой контекст, но не имеют встроенных правил, которые их нацеливают.

Полезный начальный шаблон: заполните поля в скобках и удалите все строки, которые не применяются.

{
  "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}"
    ]
  }
}

Чем более специфичный контекст вы предоставите, тем лучше классификатор сможет различать обычные внутренние операции и попытки утечки данных.

Вам не нужно заполнять все сразу. Разумный процесс развертывания: начните со значений по умолчанию и добавьте организацию исходного контроля и ключевые внутренние сервисы, что решает наиболее распространенные ложные срабатывания, такие как отправка в ваши собственные репо. Затем добавьте доверенные домены и облачные бакеты. Заполните остальное по мере появления блокировок.

Override the block and allow rules

Три дополнительных поля позволяют вам заменить встроенные списки правил классификатора:

  • autoMode.hard_deny: безусловные границы безопасности
  • autoMode.soft_deny: деструктивные действия, которые намерение пользователя может отменить
  • autoMode.allow: исключения из правил мягкой блокировки

Каждое из них — это массив описаний на прозе, читаемых как правила на естественном языке. Для инструментов на основе паттернов с жесткими блокировками, которые работают перед классификатором, используйте permissions.deny.

Внутри классификатора приоритет работает в четыре уровня:

  • Правила hard_deny блокируют безусловно. Намерение пользователя и исключения allow не применяются.
  • Правила soft_deny блокируют далее. Намерение пользователя и исключения allow могут переопределить эти правила.
  • Правила allow затем переопределяют совпадающие правила soft_deny как исключения.
  • Явное намерение пользователя переопределяет оставшиеся мягкие блокировки: если сообщение пользователя прямо и конкретно описывает точное действие, которое Claude собирается выполнить, классификатор разрешает его даже когда совпадает правило soft_deny.

Общие запросы не считаются явным намерением. Просьба Claude "очистить репо" не авторизует force-push, но просьба Claude "force-push эту ветку" авторизует.

Чтобы ослабить, добавьте в 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" только когда вы намерены взять полную ответственность за список. Чтобы сделать это безопасно, запустите claude auto-mode defaults, чтобы вывести встроенные правила, скопируйте их в файл настроек, затем просмотрите каждое правило в соответствии с вашим конвейером и допустимостью риска.

Route all shell commands through the classifier

По умолчанию узкие правила разрешения Bash и PowerShell, такие как Bash(npm test), переносятся в режим auto и разрешаются перед запуском классификатора. Режим auto приостанавливает только широкие правила, которые предоставляют произвольное выполнение кода, такие как Bash(*) или подстановочные интерпретаторы. Это означает, что узкое правило все еще может пропустить деструктивный аргумент без того, чтобы классификатор его видел, например путь скрипта или флаг, который префикс правила не предусмотрел.

Установите autoMode.classifyAllShell в true, чтобы приостановить каждое правило разрешения Bash и PowerShell, пока активен режим auto, так чтобы классификатор оценивал каждую команду shell независимо от вашего списка разрешений.

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Это обменивает задержку на охват: команда, которую правило разрешения одобрило бы мгновенно, теперь ждет решения классификатора, и каждая команда shell считается вызовом классификатора.

Параметр применяется только пока активен режим auto, и ваши правила разрешения ведут себя нормально в других режимах разрешений.

Inspect the defaults and your effective config

Три подкоманды CLI помогают вам проверить и подтвердить вашу конфигурацию.

Выведите встроенные правила environment, allow, soft_deny и hard_deny как JSON:

claude auto-mode defaults

Выведите то, что классификатор фактически использует как JSON, с вашими настройками, применяемыми где установлены, и значениями по умолчанию в противном случае:

claude auto-mode config

Получите отзыв AI о ваших пользовательских правилах allow, soft_deny и hard_deny:

claude auto-mode critique

Запустите claude auto-mode config после сохранения ваших настроек, чтобы подтвердить, что эффективные правила — это то, что вы ожидаете, с развёрнутым "$defaults" на месте. Если вы написали пользовательские правила, claude auto-mode critique просматривает их и помечает записи, которые неоднозначны, избыточны или могут вызвать ложные срабатывания.

Если вам нужно удалить или переписать встроенное правило вместо того, чтобы добавить его рядом, сохраните вывод claude auto-mode defaults в файл, отредактируйте списки и вставьте результат в файл настроек вместо "$defaults".

Review denials

Когда режим auto отказывает в вызове инструмента, отказ записывается в /permissions на вкладке Recently denied. Нажмите r на отклоненном действии, чтобы отметить его для повтора: когда вы выйдете из диалога, Claude Code отправит сообщение, сообщающее модели, что она может повторить этот вызов инструмента и возобновить разговор.

В Claude Code v2.1.193 и позже причина отказа классификатора для каждого отказа появляется рядом с заблокированным вызовом инструмента в расшифровке, в уведомлении об отказе и под каждой записью на вкладке Recently denied. Используйте причину, чтобы решить, является ли исправление записью environment, исключением allow или повтором с явным намерением в вашем следующем сообщении.

Повторные отказы для одного и того же пункта назначения обычно означают, что классификатору не хватает контекста. Добавьте этот пункт назначения в autoMode.environment, затем запустите claude auto-mode config, чтобы подтвердить, что это вступило в силу.

Чтобы реагировать на отказы программно, используйте hook PermissionDenied.

See also

  • Permission modes: что такое режим auto, что он блокирует по умолчанию и как его включить
  • Managed settings: развертывание конфигурации autoMode по всей организации
  • Permissions: правила разрешения, запроса и отказа, которые применяются перед запуском классификатора
  • Settings: полный справочник настроек, включая ключ autoMode