Claude Code 2.1.222 устраняет тихие разрывы stream на gateway и обход хука в фоновых задачах

Главное изменение Claude Code 2.1.222 — не новая функция, а режим тихого отказа, который никогда не фиксировался в логах. Если ваша команда маршрутизирует запросы Claude Code через кастомный ANTHROPIC_BASE_URL gateway — AI-routing proxy, AWS Bedrock endpoint или локальный прокси для соответствия требованиям — баг в таймере простоя stream молча убивал соединения, которые серверная сторона gateway считала здоровыми.

Вот что операторам нужно знать до того, как этот релиз попадёт на ваш флот.

Баг с таймером stream: что именно ломалось на кастомных gateway

Таймер простоя stream в Claude Code срабатывал, когда в течение окна ожидания по линии не поступало никаких байт. Цель — обнаруживать зависшие ответы. Баг: таймер не распознавал keepalive-фреймы, которые отправлял серверный side gateway. Поэтому когда ваш gateway правильно поддерживал TCP-соединение периодическими keepalive-пингами, клиент Claude Code видел тихую линию и объявлял stream мёртвым — даже если модель на той стороне ещё вычисляла ответ.

Характер сбоя зависел от логики retry:

• Без retry: CLI сообщал «Connection closed mid-response» на ответе, который фактически завершился на стороне модели, но последние байты ещё буферизировались в write-path gateway.
• С retry: тот же запрос отправлялся к upstream-провайдеру повторно, удваивая стоимость и latency для медленных генераций.
• В фоновых agent-задачах: тихие ошибки накапливались между ходами subagent, делая долгосрочные agentic-сессии ненадёжными на не-Anthropic endpoint.

Исправление в 2.1.222 делает таймер простоя прокси-осведомлённым: он сбрасывается при получении любых входящих данных, включая keepalive-фреймы, независимо от того, являются ли байты чанком ответа модели. Команды, у которых ANTHROPIC_BASE_URL указывает на routing proxy, Azure AI Foundry endpoint, AWS Bedrock-совместимый URL или локальный прокси для корпоративной инспекции трафика, после обновления должны увидеть исчезновение паттерна разрывов.

Поведение keepalive у разных провайдеров: почему это проблема routing-слоя

Поведение keepalive существенно варьируется между реализациями AI gateway:

• Прямое подключение к api.anthropic.com: чанки ответа поступают с предсказуемыми интервалами, паузы короткие. Старый порог таймера был откалиброван именно под этот паттерн трафика.
• Bedrock / Vertex AI: прокси-слои добавляют latency, вычисления на стороне модели занимают больше времени, начальное молчание между первым запросом и первым токеном длиннее — и это нормально.
• Кастомные AI routing proxy (агрегаторы, локальные MITM-прокси для аудита): могут буферизировать вывод перед пересылкой, создавая паузы в 10–30 секунд, которые превышали старый порог таймера Claude Code.

Ни один из этих gateway не делал ничего неправильного — они отправляют keepalive именно для того, чтобы клиент не объявлял соединение мёртвым. Таймер Claude Code просто игнорировал эти keepalive. Исправление приводит его в соответствие с поведением любого корректного HTTP/2 или SSE-клиента при обнаружении простоя.

Операторы, которые добавили собственный retry-wrapper поверх ANTHROPIC_BASE_URL для компенсации разрывов, теперь могут убрать этот слой. Командам, маршрутизирующим Claude Code через TheRouter, это также означает, что keepalive-поведение gateway теперь корректно распознаётся — актуальную конфигурацию base URL смотрите в документации TheRouter.

Обход хука в фоновых задачах: PreToolUse в summaries, compaction и renames

Второе исправление закрывает пробел в governance при выполнении фоновых agent-задач. В Claude Code есть хук PreToolUse, который операторы настраивают для управления тем, какие инструменты могут запускаться автоматически (без подтверждения пользователя). До 2.1.222 этот хук не вычислялся в фоновых задачах — конкретно при генерации сводок сессии, сжатии контекста (compaction) и операциях переименования файлов, которые Claude Code выполняет автономно между ходами.

Практическое следствие: правило PreToolUse, блокирующее, например, выполнение инструмента Bash в вашей политике, не применялось, когда compaction внутри запускал shell-команду. Ограничение инструмента, предназначенное для контроля команд, влияющих на production-окружение, можно было обойти через путь фонового compaction.

Исправление обеспечивает выполнение PreToolUse-оценки в каждом типе задачи — фоновой и интерактивной. Операторы, которые полагаются на hook-based access control, должны рассматривать 2.1.222 как обязательное обновление безопасности, если их деплой использует фоновые agent-сессии.

Область видимости git-команд в worktree: что изменилось по сравнению с 2.1.216

Claude Code 2.1.216 исправил escape из изоляции worktree, где subagent мог перенаправлять git-операции обратно в общий родительский checkout через флаги (--git-dir, -C <shared-path>) или переменные окружения (GIT_DIR, GIT_WORK_TREE). Тот патч исправил изоляцию на уровне редактирования файлов.

2.1.222 расширяет исправление на деструктивные git-команды через Bash внутри изолированных сессий worktree. Subagent, работающий в worktree, мог выполнить git reset --hard, git push --force или git branch -D, нацеленные на основной checkout, сконструировав команду с явным путём. Инструмент Bash допускал это даже при активной изоляции файлов, поскольку не наследовал ограничение пути worktree.

Начиная с 2.1.222, изоляция применяется к редактированию файлов и Bash в каждом типе сессии, включая subagent, порождённые внутри worktree-изолированного родителя. В сообщении коммита исправления явно сказано: «isolation now applies to file edits and Bash in every session type».

Операторам, запускающим параллельные subagent-конвейеры на отдельных ветках — разработку фич, автоматизацию code review, обновление зависимостей — следует проверить все agentic Bash-команды, выполненные до 2.1.222, если эти agent-ы работали с git и имели право записи в пути репозитория.

Атрибуция использования MCP и исправление алиасов моделей в организации

Ещё два исправления касаются биллинга и governance:

Атрибуция использования MCP-сервера завышала показатели: /usage приписывал каждый ход после вызова MCP-инструмента этому серверу, даже если последующие ходы никогда не использовали его результаты. 2.1.222 исправляет это: доля сервера отражает только запросы, которые фактически потребляли его вывод. Если вы делаете распределение затрат по MCP-серверам между командами, числа после обновления снизятся — и это будет корректно.

Алиасы моделей с ограничением по организации (model: opus, model: sonnet) при разрешении в модель вне разрешённого набора организации падали обратно на родительскую модель. Теперь они понижаются до новейшей разрешённой модели в запрошенном семействе. Для операторов, которые задают алиасы семейств моделей в managed settings, это меняет поведение fallback: agent теперь выбирает наиболее актуальную разрешённую модель семейства вместо того, чтобы молча использовать инициирующую модель.

Что нужно сделать после обновления

Уберите retry-wrapper поверх ANTHROPIC_BASE_URL, добавленный для компенсации разрывов stream. Базовый баг исправлен; дополнительный слой retry теперь может порождать дублирующиеся запросы для ответов, которые успешно завершаются с первой попытки. Проверьте правильное значение ANTHROPIC_BASE_URL в конфигурации Claude Code, сверяясь со страницей TheRouter models для получения доступных ID моделей.

Проверьте покрытие PreToolUse hook в managed settings. Хук теперь обязателен в фоновых задачах — но если ваш предыдущий деплой предполагал, что он не применяется, убедитесь, что логика хука корректно обрабатывает сценарии фоновых задач. Хук, рассчитанный только на интерактивные ходы, теперь может срабатывать во время запусков compaction.

Проверьте последнюю активность параллельных subagent с git на изолированных ветках worktree. В версиях 2.1.216–2.1.221 subagent внутри worktree всё ещё мог выдавать деструктивные git-команды через Bash. Если ваши agentic CI-конвейеры работали в этом окне, сравните ожидаемое состояние веток с фактической историей git в общем checkout.

Проверьте разрешение алиасов моделей в организации, если вы закрепляете алиасы семейств в managed settings и замечали fallback-модели в логах запросов. Новое поведение понижения версии может маршрутизировать к другой модели, чем прежний fallback.