Claude Code добавляет защиту записи в shell-стартовые файлы: что новая модель безопасности acceptEdits означает для безголовых развёртываний

Если ваша команда запускает Claude Code в безголовом режиме или через SDK с включённым acceptEdits, релиз от 2 июня изменил вашу поверхность безопасности — без каких-либо изменений в конфигурации. Новые интерактивные подтверждения теперь блокируют запись в shell-стартовые файлы и конфиги build-инструментов. Если ваш пайплайн рассчитывает на то, что эти операции выполняются без вопросов, он будет зависать.

Что изменилось

Релиз Claude Code от 2 июня (v2.1.157+) вводит два уровня защиты для предотвращения сценариев, при которых ИИ-сгенерированный код непреднамеренно получает постоянные привилегии исполнения:

Защита shell-стартовых файлов. Перед записью в .zshenv, .zlogin, .bash_login или ~/.config/git/ Claude Code теперь показывает явный запрос на подтверждение. Эти файлы выполняются при каждом открытии shell — успешная запись может установить постоянный хук, выполняющий произвольные команды от имени пользователя далеко за пределами текущей сессии Claude Code. Защита безусловная: она срабатывает независимо от состояния acceptEdits.

Защита конфигов build-инструментов в acceptEdits. Команды, использующие режим acceptEdits — где Claude Code автоматически применяет правки файлов без подтверждения каждой из них — теперь видят дополнительный слой подтверждения для класса файлов, способных предоставить право исполнения кода. Список защищённых файлов включает:

• .npmrc и .yarnrc* — могут определять lifecycle-хуки и install-скрипты
• bunfig.toml — тот же класс, инструментальная цепочка Bun
• .bazelrc — может указывать произвольные исполняемые файлы toolchain
• .pre-commit-config.yaml — выполняет хуки перед каждым коммитом
• .devcontainer/ — определяет полную среду контейнера, включая startup-скрипты

Это не косметические конфиги. Намеренно или случайно составленный .npmrc с хуком scripts.preinstall, например, будет выполнять произвольный код при каждом npm install в репозитории. Новая защита не позволяет acceptEdits обращаться с такими файлами как с обычными исходниками.

Почему это важно для AI engineering-команд

Паттерн acceptEdits широко используется в автономных развёртываниях coding agent. Команды настраивают Claude Code как фоновый agent — запускаемый через SDK, триггеримый CI или маршрутизируемый через API gateway — и рассчитывают на то, что он вносит и применяет правки без пауз на одобрение. Именно так достигается пропускная способность; и именно так скомпрометированный prompt или краевой случай в суждении модели мог незаметно записать хук в среду разработки.

Новые защиты разрушают неявное предположение о том, что acceptEdits — это плоское сквозное разрешение. Теперь у него есть исключения по классу файлов для всего, что находится в цепочке исполнения. Для большинства команд, работающих с кодом приложений, это незаметно. Для команд, управляющих infrastructure-as-code агентами, генераторами скаффолда, updater'ами devcontainer или менеджерами pre-commit хуков, это изменение рабочего процесса.

Также стоит отметить удалённую переменную окружения CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE: любой пайплайн, использовавший её для принудительного fast mode на развёртываниях Opus 4.6, больше не получит никакого эффекта. Переменная теперь является no-op, но не вызовет ошибку — что оставит конфигурацию, не делающую ничего, и может ввести в заблуждение при будущей отладке.

Router/operator-угол

Развёртывания через SDK и gateway. При развёртывании Claude Code через SDK (@anthropic-ai/claude-code) за API gateway или TheRouter поток tool-вызовов маршрутизируется как прежде. Изменилось то, что происходит внутри subprocess Claude Code при попытке записать конфиг build-инструмента: вместо молчаливого выполнения write tool-call он теперь выдаёт prompt, блокирующий выполнение до подтверждения человеком (или до timeout).

Если ваша инфраструктура оборачивает Claude Code с флагом --yes или CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, и человек не участвует в процессе, необходимо проверить, будет ли ваше развёртывание теперь получать необработанные prompt'ы. Prompt не представляется как API-ошибка — он проявляется на уровне TTY. Безголовые runner'ы, захватывающие только stdout/stderr, могут его не увидеть и просто зависнут.

Аудит области действия acceptEdits. Самое время проверить, какие паттерны файлов ваши Claude Code agent'ы сейчас имеют право записывать. Модель по умолчанию не ограничивает себя кодом приложения. Если вы не настроили явные паттерны ignore или ограничения области файлов в CLAUDE.md или settings.json, ваши agent'ы, вероятно, уже записывали в конфиги build-инструментов. Новая защита перехватывает это в будущем, но не проводит ретроспективный аудит уже записанного.

Изменение ключевого слова динамических воркфлоу. Триггерное ключевое слово для динамических воркфлоу изменилось с workflow на ultracode. Любая SDK-интеграция или шаблон prompt, использующий буквальное слово workflow как префикс prompt для запуска динамических воркфлоу, теперь будет молча не срабатывать — запрос обработается как обычный тёрн, а не как запуск динамического воркфлоу. Проверьте файлы CLAUDE.md и prompt-обёртки SDK, если используете эту функцию.

На что обратить внимание

• Проверьте безголовые пайплайны. Запустите тестовый тёрн, который должен инициировать запись в конфиг build-инструмента, в staging-среде. Убедитесь, обрабатывает ли ваш runner новый prompt или зависает.
• Проверьте область действия acceptEdits. Если ваши agent'ы по делу обновляют .npmrc или конфиги devcontainer, используйте settings.json для явного указания директорий или паттернов файлов. Явная область безопаснее, чем полагаться на суждение модели.
• Удалите CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE. Если какой-либо пайплайн устанавливает это значение, уберите его — это no-op, который может запутать при отладке в будущем.
• Если вы используете динамические воркфлоу, обновите все жёстко заданные триггеры ключевого слова workflow на ultracode.

Широкий паттерн здесь таков: модель безопасности Claude Code зреет от «доверяйте модели оставаться в области» к явному управлению на уровне классов файлов. Операторам, использующим Claude Code как чёрный ящик и маршрутизирующим все его tool-вызовы через API-слой, следует ожидать больше таких границ записи файлов, а не меньше, по мере развёртывания модели во всё более ответственных средах.