Claude Code 2.1.219: три изменения в управлении, которые операторы обязаны проверить перед деплоем

Три изменения в Claude Code 2.1.219 теряются среди многочисленных исправлений ошибок — но каждое из них меняет то, что развёрнутая конфигурация фактически разрешает делать, не требуя никаких изменений в коде.

Что именно изменилось, с конкретными настройками

sandbox.network.strictAllowlist — новая настройка, по умолчанию отключена.

До 2.1.219 sandbox при обращении к хосту, не входящему в allowlist, показывал диалог подтверждения — пользователь мог одобрить или отклонить запрос. При strictAllowlist: true отклонение происходит молча: любой хост, отсутствующий в sandbox.network.allowedHosts, блокируется без диалога.

Для headless-деплоев это принципиально важно. Если Claude Code работает в CI или за API gateway без наблюдателя у терминала, старое поведение ставило неизвестные хосты в очередь ожидания одобрения, которого никогда не последует — agent зависал. С strictAllowlist вы декларируете сетевой периметр в настройках, операционная система его соблюдает, возврата к диалогу нет.

Как включить:

// .claude/settings.json или managed settings
{
  "sandbox": {
    "network": {
      "strictAllowlist": true,
      "allowedHosts": [
        "api.anthropic.com",
        "registry.npmjs.org",
        "github.com"
      ]
    }
  }
}

Что меняется операционно: любой agent, пытающийся обратиться к неявному эндпоинту — например, к MCP-серверу с неизвестным облачным доменом или к пакетному регистру, который модель решила задействовать, — будет молча падать, а не зависать. Режим отказа становится предсказуемым, но вы берёте на себя поддержку allowlist по мере роста набора инструментов agent. Практически это означает: при подключении новых MCP-серверов или изменении стека инструментов на стороне agent нужно будет обновлять allowlist вручную, прежде чем разворачивать изменения в продакшене.

Вложенные subagent теперь достигают глубины 3 по умолчанию — для отката нужна явная настройка.

До 2.1.219 subagent в Claude Code не могли порождать собственных subagent: потолок глубины был 1. Начиная с 2.1.219 потолок по умолчанию равен 3: основной agent порождает subagent, тот порождает свои subagent, которые порождают ещё один уровень.

Стоимостное давление реально. При глубине 1 один orchestrator-запрос с 10 subagent генерирует 11 обращений к Claude API. При глубине 3 каждый из 10 теоретически может породить ещё 10, и каждый из тех ещё 10 — итого до 1111 вызовов API до окончания одного хода orchestrator. На практике воркфлоу до потолка не доходят, но «радиус поражения» неверно настроенного agentic-запроса растёт на порядок.

Чтобы вернуть старое поведение с глубиной 1:

# В shell-окружении или через env managed settings
export CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1

CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH — единственный доступный контроль.

Для операторов, маршрутизирующих Claude Code через gateway: каждый порождённый subagent делает независимые вызовы к upstream-провайдеру. Вложенность до глубины 3 означает всплески в метриках токенов, которые не соответствуют 1:1 топ-уровневым сессиям. Если вы используете per-session атрибуцию расходов для биллинга, предположение «один запуск CLI = один session трафика API» нарушается.

Размер динамического воркфлоу по умолчанию изменён с «без ограничений» на «medium» — менее 15 agent.

Dynamic Workflow в Claude Code позволяет модели оркестрировать переменное количество параллельных agent. До 2.1.219 ориентир размера был рекомендательным, а по умолчанию — «без ограничений». С 2.1.219 умолчание — «medium»: стремиться к менее чем 15 параллельным agent.

Это по-прежнему рекомендательно (модель может превысить ориентир при веских причинах), но теперь есть конкретный якорь для планирования.

Для операторов: если ваши Dynamic Workflow регулярно превышали 15 agent, теперь появился управляемый параметр.

Изменить умолчание:

// В любом settings-файле (проект, пользователь, или org managed settings)
{
  "workflowSizeGuideline": "large"   // "small" | "medium" | "large" | "unrestricted"
}

Или через /config → «Dynamic workflow size» в интерактивной сессии. Текущий активный ориентир отображается в строке статуса работающего воркфлоу, так что вы видите, что управляет текущим запуском, без открытия settings.

Вид со стороны маршрутизатора: где конфигурация, где исполнение

Все три настройки живут в слое settings Claude Code — проект .claude/settings.json, пользовательский или организационный managed settings — не в теле API-запроса к Anthropic. Это означает:

• Команды, маршрутизирующие Claude Code через Bedrock, Vertex AI или кастомный gateway, получают то же поведение, что и при прямом вызове Claude API. Контроли sandbox и subagent исполняются на клиентской стороне, до того как запрос доходит до слоя маршрутизации.
• Наблюдаемость на уровне gateway: ваш routing-прокси видит отдельные API-вызовы, но не видит глубину вложенности или состояние network allowlist на стороне Claude Code. Для видимости глубины subagent нужна инструментация на уровне SDK или чтение событий agent_turn в stream-json (флаг --forward-subagent-text, добавленный в 2.1.219, транслирует текст subagent глубины 2+ с ключом по tool_use id порождающего agent).
• Managed settings: для команд, доставляющих настройки через CLAUDE_CODE_SETTINGS_URL, все три параметра управляются централизованно и применяются при запуске — поддерживать файл настроек в каждом проекте не нужно.

Сравнение с другими coding agent: у Cursor Automations и Grok Build управление порождением agent реализовано на уровне облачного control plane, где оператор видит и ограничивает количество agent в дашборде. Управление Claude Code живёт на стороне CLI/SDK — это гибче, но для соблюдения политики на всём парке рабочих станций разработчиков или CI-раннеров требует намеренного деплоя managed settings.

Что проверить до распространения 2.1.219

Если Claude Code работает в CI или headless-режиме:
Включите sandbox.network.strictAllowlist: true и составьте allowlist из реальных логов. Без этого неизвестные вызовы в headless-среде зависнут без ответа — это была проблема до 2.1.219. Соберите список хостов из существующих логов, затем включайте.

Если Dynamic Workflow используются для крупных кодовых баз:
Проверьте, превышали ли ваши воркфлоу 15 agent. Если да — добавьте "workflowSizeGuideline": "large" или "unrestricted" в managed settings до деплоя 2.1.219, либо примите изменение поведения и следите за потреблением токенов в первых запусках.

Если вы ведёте per-session атрибуцию расходов:
Глубина 3 по умолчанию означает, что атрибуция на уровне top-level сессии больше не покрывает все расходы одного agentic-запуска. Установите CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 для строгих границ по сессии, или обновите логику атрибуции, агрегируя вызовы API по всему дереву от одного запуска CLI.

Отдельно: fast mode для Opus 4.7 теперь возвращает ошибку.
claude-opus-4-7 с speed: "fast" выдаёт ошибку в 2.1.219. В отличие от Opus 4.6, молчаливого fallback на стандартную скорость нет. Если в конфигурациях Claude Code явно задан Opus 4.7 с fast mode — эти вызовы упадут. Мигрируйте на Opus 5 или Opus 4.8 для доступа к fast mode.

Дополнительно: в 2.1.219 добавлено поле mcp_server_errors в событие инициализации stream-json headless-режима. Оно перечисляет записи --mcp-config, пропущенные при валидации конфигурации. В интерактивных сессиях то же самое выводится в виде предупреждения при запуске. Если вы используете Claude Code в headless-пайплайнах с несколькими MCP-серверами, парсите это поле при старте — оно поможет отловить ошибки конфигурации до того, как они проявятся в виде тихих сбоев вызовов инструментов в середине выполнения агента.