Claude Code MCP reliability routing: v2.1.191 чинит хрупкий control plane агента

Claude Code MCP reliability routing стал более конкретной задачей для операторов после релиза v2.1.191 от 24 июня. Главная новость — не новая модель и не яркая IDE-функция. Это набор небольших исправлений control plane: MCP discovery теперь повторяет запросы после кратких сетевых сбоев, MCP OAuth лучше работает в headless-средах, managed settings могут принудительно обновляться без cache, а sandbox network approvals сохраняются до конца session. Для команд, которые запускают coding agent через AI gateway, такие детали решают, упадет ли длинная задача fail closed, зациклится ли она на auth или потратит бюджет на восстановимый инфраструктурный шум.

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

Официальный Claude Code v2.1.191 release от Anthropic перечисляет несколько исправлений, которые легко пропустить, если смотреть только на model changes. Для operator важнее всего следующее:

• MCP capability discovery для tools/list, prompts/list и resources/list теперь повторяет transient network errors с коротким backoff.
• MCP OAuth discovery и token requests делают один retry после transient network errors, а headless-среды пропускают browser popup и сразу показывают paste-the-URL prompt.
• Managed settings forceRemoteSettingsRefresh теперь работает, когда задается через MDM или file policy, а refresh request отправляет Cache-Control: no-cache, чтобы proxy не отдавал stale policy.
• Sandbox network permission dialogs запоминают hosts, одобренные через "Yes", до конца session вместо повторного prompt на каждое соединение.
• Background agents, остановленные из tasks panel, больше не воскресают позже.
• Streaming text updates объединяются до 100ms, что снижает CPU usage во время responses примерно на 37%, а memory growth от terminal-output cache в длинных sessions уменьшен.

Эти изменения не переписывают Claude Code. Вместе они укрепляют agent control plane вокруг интерфейсов, которыми обычно владеют операторы: tool discovery, credential flow, policy propagation, sandbox egress и resource overhead в длинных sessions.

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

Coding agent надежен ровно настолько, насколько надежен control plane вокруг его tools. Если MCP server кратко падает во время tools/list, agent может принять отсутствующий tool за ограничение приложения. Если OAuth discovery ломается в SSH или CI, operator может увидеть auth failure вместо transient network issue. Если remote settings кэшируются proxy, fleet может продолжать работать со старыми model restrictions или permission policy уже после того, как команда считает новую policy развернутой.

Поэтому Claude Code MCP reliability routing нужно рассматривать как policy topic, а не как сноску в patch notes. Команды, которые route agent sessions через shared infrastructure, должны разделять три класса отказов:

1. Recoverable control-plane noise: retry MCP discovery и OAuth один-два раза до смены model route или fail task.
2. Policy freshness failures: fail closed, если managed settings нельзя refresh, особенно для model restrictions, sandbox policy и tool permissions.
3. Runtime-resource drift: наблюдать CPU, memory и terminal-output growth в длинных sessions, чтобы agent cost не прятался в host overhead.

Пользователи TheRouter могут связать эти классы с общей gateway-практикой через TheRouter docs: относитесь к agent sessions как к stateful workloads с tool inventory, identity, policy version и cost attribution, а не как к отдельным chat completions.

Взгляд со стороны роутинга и эксплуатации

Релиз меняет то, как router или gateway должен наблюдать coding-agent sessions. Один model fallback не исправит отсутствующий MCP tool list, stale remote policy или sandbox egress prompt, который повторяется каждые несколько секунд. Это control-plane conditions, значит routing layer нужен control-plane checklist.

Во-первых, логируйте MCP discovery отдельно от model requests. Ошибка tools/list не должна смешиваться с общей model latency. Ей нужны отдельные tags: MCP availability, server URL, retry count и final tool inventory. Так operators понимают, пришел ли failure из model reasoning или из missing tool context.

Во-вторых, добавляйте policy version и refresh status в session metadata. Исправление forceRemoteSettingsRefresh важно, потому что stale policy — один из самых простых путей drift в enterprise agent fleets. Если gateway routes sessions по team, project или risk tier, он также должен записывать managed-settings version, активную в начале session.

В-третьих, воспринимайте sandbox network approvals как egress state. Запоминание approved hosts в пределах session снижает prompt fatigue, но также означает, что network allowance у session меняется со временем. Operators должны сверять это с deny-by-default egress rules и compliance boundary вокруг repositories, package registries и internal APIs.

Что стоит проверить или попробовать пользователям TheRouter

Начните с controlled upgrade lane, а не с обновления всего fleet. Сравните v2.1.191 с текущей версией Claude Code на representative long-running task, где используются MCP, sandboxed commands и background agents.

Короткий operator checklist:

• Проверьте, что MCP discovery failures логируются с retry count и final status.
• Протестируйте MCP OAuth в headless или SSH-среде и задокументируйте paste-the-URL path.
• Убедитесь, что managed settings refresh обходит proxy cache, а active policy version видна operators.
• Рассматривайте sandbox network approvals как session-scoped egress state, а не только UX convenience.
• Сравните CPU и memory для длинной streaming session до и после upgrade.
• Перечитайте предыдущий анализ TheRouter о Claude Code 2.1.186 bash auto-respond and subagent permission routing, потому что v2.1.191 развивает ту же operator-тему: agent control plane становится первичной поверхностью надежности.

Практический вывод: Claude Code MCP reliability routing — это не столько смена модели, отвечающей на prompt, сколько доказательство того, что tools, credentials, policy и sandbox egress здоровы до того, как coding agent потратит еще час на неверный путь.