Claude Code 2.1.199: пять исправлений надёжности, которые каждый оператор обязан проверить прямо сейчас

Баги надёжности редко заявляют о себе явно. Они проявляются через тесты, которые молча проходят, отсутствующие сообщения об ошибках или демоны, перезапускающиеся по расписанию, о котором никто не договаривался. Claude Code 2.1.199 устраняет пять таких скрытых режимов отказа — и каждый из них требует внимания операторов до развёртывания Claude Code в production.

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

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

1. Ошибки TLS-сертификатов теперь немедленно завершают запрос с actionable-подсказкой. Раньше SSL-ошибки — включая вызванные TLS-инспектирующими прокси, отсутствием NODE_EXTRA_CA_CERTS или истёкшими сертификатами — исчерпывали retry-бюджет прежде, чем выводилось сообщение. В 2.1.199 TLS-ошибка сразу прерывает выполнение и показывает подсказку по исправлению. Никаких напрасных retry, никаких неоднозначных timeout-сообщений.

2. Ошибки subагентов больше не отражаются как успех. До этого релиза subагент, столкнувшийся с API-ошибкой — в том числе с исчерпанием usage limit, — мог вернуть эту ошибку как «успешный результат» родительскому агенту. Родитель потреблял строку ошибки как валидный вывод. Теперь ошибка корректно классифицируется и передаётся по цепочке вверх.

3. Лимит CLAUDE_CODE_RETRY_WATCHDOG поднят до 300; ограничение CLAUDE_CODE_MAX_RETRIES снято. Watchdog теперь по умолчанию выполняет до 300 retry для нетребующих ёмкости транзитных ошибок, а жёсткий лимит в 15 для CLAUDE_CODE_MAX_RETRIES снят. Команды, запускавшие длительные фоновые задачи через медленные или периодически перегруженные gateway, нередко неожиданно упирались в этот потолок.

4. Фоновый демон агентов на Linux больше не убивает себя каждые ~50 секунд. Некорректное завершение работы оставляло испорченную запись worker, из-за которой демон прекращал работу сам и вместе с ним все запущенные агенты примерно на каждом 50-секундном цикле heartbeat. Для Linux-хостов это был тихий production-сбой: агенты умирали и перезапускались без явной ошибки.

5. SendMessage теперь обнаруживает и отклоняет маршрутизацию при конфликте имён. Когда пересозданный агент использует имя предыдущего, SendMessage мог молча доставить сообщение не тому получателю. Исправление обнаруживает несоответствие идентификаторов и требует от вызывающей стороны переопределить цель, а не маршрутизировать вслепую.

Другие примечательные изменения в 2.1.199: стопки вызовов /skill-a /skill-b теперь загружают все ведущие skills (до 5), а не только первый; при server-ошибке в середине стрима частичный вывод сохраняется; транзитные 429, не связанные с usage limit, теперь автоматически повторяются с backoff для подписчиков.

Почему это важно для инженерных команд

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

Достоверность ошибок

Баг с «тихим успехом» subагента особенно опасен в автоматизированных pipeline. Если фоновый агент оркестрирует subагентов для записи, рефакторинга или деплоя, а subагент, исчерпав лимит, вернул ошибку как «вывод», родитель продолжит работу с некорректными данными. Исправление в 2.1.199 гарантирует корректное всплытие ошибок — но это также означает, что команды, неявно полагавшиеся на старое поведение (обрабатывавшие «rate limited» как no-op), должны проверить, что их обработчики ошибок теперь получают реальные ошибки, а не строки.

Экономика retry

Лимит в 15 для CLAUDE_CODE_MAX_RETRIES был скрытым потолком для команд, гоняющих Claude Code через gateway с агрессивным rate-limiting или очередями. Gateway, ставящий запросы в очередь и медленно высвобождающий их, мог вынуждать Claude Code исчерпывать retry до того, как очередь разгружалась, — и провал выглядел как ошибка провайдера. Новый лимит watchdog в 300 и снятие жёсткого ограничения дают операторам простор для настройки retry пропорционально реальным характеристикам задержки gateway.

Стабильность флота на Linux

Kill-loop-баг демона затрагивает любую команду, разворачивающую Claude Code как фоновый агент-сервис на Linux. При некорректном завершении предыдущей сессии — убитый контейнер, OOM-событие, сетевой разрыв — испорченная запись worker заставляла каждую последующую сессию умирать в течение 50 секунд. Команды, использующие Claude Code-агентов без присмотра на Linux-серверах, должны рассматривать это исправление как срочное.

Угол router/operator

Проверьте TLS-конфигурацию до следующего деплоя. Новое поведение быстрого завершения в 2.1.199 делает ошибки TLS мгновенно видимыми, а не после шторма retry. Если Claude Code работает за TLS-инспектирующим прокси (типично для корпоративных сред с Zscaler, Palo Alto или Cisco), убедитесь, что NODE_EXTRA_CA_CERTS указывает на ваш CA bundle. Деплой, ранее молча тративший retry на TLS-сбои, теперь покажет ошибку на первом запросе — это лучше, но может потребовать действий по CA-конфигурации.

Пересмотрите контракты обработки ошибок subагентов. В мультиагентных workflow, где lead-агент делегирует subагентам и потребляет их результаты, изменение в отчётности об ошибках означает, что тип ошибки и структура сообщения будут отличаться от того, что subагент возвращал раньше. Если у вас есть логика разбора, ожидающая конкретный формат строки из результата subагента, протестируйте её против нового облика ошибки.

Проверьте CLAUDE_CODE_MAX_RETRIES в конфигурации флота. Если вы явно задали CLAUDE_CODE_MAX_RETRIES=15 или ниже, вы уже были у старого потолка. Теперь ограничение снято — вероятно, стоит повысить это значение, особенно для агентов, работающих через gateway с переменной задержкой очереди.

Убедитесь в корректности процедур завершения работы Linux-демона. Если вы запускаете Claude Code на Linux с оркестровкой контейнеров, которая может прерывать агентов в середине сессии, убедитесь, что ваша процедура завершения отправляет корректный сигнал stop, а не SIGKILL. Исправление 2.1.199 обрабатывает испорченную запись worker, но корректное завершение предотвращает само появление повреждения.

Защита SendMessage от конфликта имён важна для длительных swarm-задач. В workflow, где агенты порождаются, выполняют задачи и заменяются новыми с тем же логическим именем, старое поведение могло молча маршрутизировать сообщения не в ту сессию. Новая проверка несоответствия требует явного переопределения цели — это значит, что ваш оркестрационный слой должен отслеживать текущий handle агента, а не только его имя.

На что обратить внимание пользователям TheRouter

Если вы маршрутизируете сессии Claude Code через TheRouter, изменение быстрого завершения TLS в 2.1.199 упрощает диагностику проблем с сертификатами на уровне gateway. Если ваш gateway завершает TLS и перевыпускает собственный сертификат, убедитесь, что хранилище CA-доверия Claude Code настроено на принятие центра сертификации вашего gateway. Увеличение retry watchdog также означает большую устойчивость Claude Code к задержкам очереди gateway — полезное свойство при маршрутизации через gateway, распределяющий трафик по нескольким upstream-провайдерам.

Для команд, выполняющих мультиагентные рабочие нагрузки, обновитесь до 2.1.199 перед следующим production-деплоем. Исправление достоверности ошибок subагентов и защита SendMessage от конфликта имён — оба улучшения корректности, влияющие на надёжность оркестровки агентов в масштабе.