Claude Code 2.1.269: три оператор-уровневых изменения в релизе с 60+ исправлениями

Claude Code 2.1.269 вышел сегодня утром — более шестидесяти отдельных изменений. Большая часть changelog — это работа с совместимостью терминалов: отрисовка курсора в редких эмуляторах, посторонние символы на медленных SSH-соединениях, правки, которые важны именно тем, кто на них натолкнулся. Однако внутри есть три изменения, которые командам, запускающим Claude Code в командном или корпоративном масштабе, стоит прочитать до начала следующей сессии.

Таймаут обнаружения gateway был жёстко задан в три секунды

Когда Claude Code запускает сессию с настроенным custom LLM gateway, перед первым запросом он опрашивает /v1/models, чтобы узнать, какие модели доступны. Этот запрос имел жёсткий трёхсекундный таймаут без возможности изменить его.

Три секунды работают для gateway в одной локальной сети. В двух распространённых production-конфигурациях это ломается: gateway с путём холодного старта (Lambda, Cloud Run, любой бессерверный бэкенд) и gateway за корпоративным прокси с overhead-инспекцией. Сессия завершала обнаружение моделей с ошибкой, откатывалась к значениям по умолчанию и молча маршрутизировала иначе, чем указано в конфигурации, — или вообще падала.

2.1.269 добавляет CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS — значение в миллисекундах, переопределяющее трёхсекундный дефолт:

export CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS=10000  # 10 секунд

Если вы маршрутизируете Claude Code через корпоративный gateway с нетривиальной задержкой холодного старта, эта переменная среды должна быть рядом с ANTHROPIC_BASE_URL в конфигурации деплоя. Прежним workaround был предварительный прогрев gateway-endpoint до старта сессий; теперь это не нужно.

Для локально размещённых gateway трёхсекундный дефолт сам по себе нормален — повышать его не нужно, если вы не наблюдаете ошибок discovery.

Параллельные workflow-агенты теперь имеют настраиваемый оператором лимит

Инструмент Workflow позволяет Claude Code распределять работу между параллельными субагентами. До 2.1.269 лимит параллельных агентов на запуск был внутренним и недоступным для операторов. Когда задача декомпозировалась на много параллельных веток, фактическая конкурентность определялась самой моделью.

2.1.269 добавляет CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS — целое число от 1 до 256:

export CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS=8

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

Конкретное значение зависит от rate limits вашего провайдера и бюджета команды. Если вы запускаете Claude Code против gateway с многоуровневыми квотами, относитесь к этому параметру как к размеру connection pool: задайте один раз, понаблюдайте за расходом токенов на первых параллельных workflow, потом скорректируйте.

Deny-правило с ! молча распространялось за пределы своего config-источника

Это самое значимое по последствиям изменение в релизе, и описание в changelog легко недооценить: «Fixed a deny or ask permission rule starting with ! applying beyond the settings source that wrote it; such a rule now applies only within its own source, and a bare ! negation is ignored.»

Claude Code применяет правила разрешений из нескольких источников в иерархии: управляемые настройки организации, настройки уровня проекта, пользовательские настройки, локальный .claude/settings.json. Deny-правило с ! — это отрицание: оно исключает конкретный путь из более широкого allow. Баг состоял в том, что такие правила-отрицания трактовались как глобальные и применялись во всех источниках, а не только в том, где написаны. Правило с ! в проектном .claude/settings.json молча ограничивало org-level allow grants, которые администратор организации ожидал видеть в полную силу.

На практике: если вы написали проектное !-правило, чтобы сделать исключение в рамках project-scoped allow, это исключение параллельно ограничивало org-level allows. В зависимости от того, что покрывают те allows, команда могла работать с более жёсткими ограничениями, чем планировалось, — или, в другой конфигурации, с более мягкими.

Исправление точечное: каждое !-правило теперь действует только в рамках написавшего его источника. Конфигурации, полагавшиеся на прежнее (некорректное) межисточниковое распространение, после обновления будут вести себя иначе. Перед развёртыванием 2.1.269 на весь парк машин проверьте конфигурации правил разрешений на каждом уровне источников и убедитесь, что область действия соответствует замыслу.

Это касается и Bedrock, и Vertex deployments с managed settings — один и тот же permission pipeline работает вне зависимости от того, какой провайдер принимает инференс-запрос.

Два исправления prompt cache для длительных агентных сессий

В 2.1.269 закрыты два сценария, в основном затрагивающих длительные или многоходовые агентные сессии.

Первое исправление: когда Claude Code упирался в лимит output-токенов и автоматически возобновлял ответ, на следующем ходу prompt cache частично сбрасывался. Агенты с большим контекстом, регулярно достигающие output-лимита, платили некэшированную цену за input-токены на ходу возобновления — хотя должны были попасть в кэш.

Второе исправление: возобновление сессии после прерывания Claude на середине мысли могло изменить способ переотправки более раннего контекста, нарушая повторное использование кэша на возобновлённом ходу. При одновременном возникновении оба эффекта накапливаются: сессия, которую часто прерывали и которая регулярно добивалась output-лимита, теряла cache reuse в обоих случаях.

Ни одно из исправлений не требует изменений конфигурации — они вступают в силу после обновления.

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

Если вы маршрутизируете сессии Claude Code через custom endpoint, добавьте CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS в конфигурацию деплоя рядом с ANTHROPIC_BASE_URL. Задайте значение, которое даёт вашему gateway достаточный запас относительно p95 задержки старта.

Если вы используете Workflow tool в fan-out нагрузках, установите CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS в соответствии с rate limits вашего провайдера. Пиковая конкурентность сверх квоты порождает retryable-ошибки, но эти retry потребляют окно rate-limit и добавляют задержку всему workflow.

Прежде чем разворачивать 2.1.269 на существующих клиентах, проверьте конфигурации правил разрешений — особенно там, где на уровне проекта или локальном уровне использовалось !-отрицание. Изменение корректное, но для конфигураций, опиравшихся на старое кросс-источниковое поведение, фактические ограничения могут измениться.

Предыдущие материалы по смежным изменениям в Claude Code: Claude Code 2.1.268: исправление gateway, Claude Code 2.1.266: gateway-регрессия.