Claude Code 2.1.259: Org-Level MCP Server Push и исправление потери состояния при параллельных сессиях

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

В этом changelog два изменения имеют прямые операторские последствия. Первое: managedMcpServers — новое поле в managed settings, которое позволяет администратору раздать HTTP/SSE MCP серверы всем пользователям без какой-либо настройки с их стороны. Второе: исправление бага, при котором параллельные сессии тихо перезаписывали ~/.claude.json друг друга — это приводило к потере workspace trust и MCP-конфигурации в multi-agent и CI-окружениях при любом количестве одновременных сессий больше одной.

Третье изменение закрывает gap в gateway proxy: CLAUDE_CODE_MAX_CONTEXT_TOKENS молча игнорировался для model ID с суффиксом @YYYYMMDD — именно такой формат используют версионированные псевдонимы моделей на Vertex AI.

Изменение, меняющее org-level MCP rollout

managedMcpServers — новое поле в managed settings файле (слой политик HKLM / MDM / managed-settings.json). Администратор задаёт его один раз; оно применяется ко всем пользователям при запуске сессии, как и остальные managed settings.

Ключевое ограничение: принимаются только HTTP/SSE MCP серверы. Любая запись с полем command молча пропускается — без ошибок и предупреждений. Это намеренная граница безопасности: managed layer предназначен для удалённых серверов под управлением организации, а не для запуска локальных процессов с машины пользователя из admin config.

Формат записей совпадает с .mcp.json для HTTP/SSE серверов:

{
  "managedMcpServers": {
    "corp-tools": {
      "type": "http",
      "url": "https://mcp.your-corp.internal/tools"
    }
  }
}

Для команд, которые эксплуатируют внутренние MCP серверы — поиск по коду, тикет-системы, внутренняя документация — путь развёртывания впервые становится policy-level, а не per-user onboarding.

Что реально меняет миграция с allowedMcpServers

Поведенческое изменение, которое застанет операторов врасплох — в allowedMcpServers.

До 2.1.259: если существовал файл managed-mcp.json и был задан allowedMcpServers, allowlist фильтровал в том числе managed-серверы. Managed-сервер, не включённый в allowlist, не загружался.

После 2.1.259: allowedMcpServers управляет только серверами, которые добавляют сами пользователи. Записи в managed-mcp.json загружаются безусловно при обновлении, независимо от allowlist.

Если организация использовала allowedMcpServers для контроля того, какие managed-серверы активны — эта конфигурация перестаёт работать после обновления. Путь миграции однозначен: перенести логику контроля в deniedMcpServers. Серверы, которые нужно заблокировать, попадают в этот список; allowlist теперь работает только с пользовательскими MCP-серверами.

Команды, использующие allowedMcpServers: [] как lockdown (блокировка всех пользовательских серверов при разрешении managed), поведение не почувствуют. Но любая конфигурация с конкретными именами managed-серверов в allowlist в качестве фильтра — эти записи теперь инертны для managed-серверов.

Баг с параллельными сессиями, который тихо ломал CI

Баг: когда несколько Claude Code сессий работали одновременно и писали в ~/.claude.json, они молча откатывали изменения друг друга. Разрешения workspace trust, выданные в одной сессии, могли исчезнуть к моменту завершения другой. MCP-регистрации, добавленные на ходу, терялись. Состояние проекта, записанное параллельным агентом, перезаписывалось.

Это не гипотетический edge case. Любой CI pipeline, запускающий параллельные Claude Code агенты — автоматический code review, генерация тестов, multi-agent coding workflows — был подвержен этому. Сложность отладки в том, что записи в ~/.claude.json не падают и не логируют ошибку; последний писавший просто побеждает, предыдущие изменения исчезают молча.

Исправление сериализует запись в ~/.claude.json. Для операторов с multi-agent pipeline это означает, что workspace trust grants, MCP-регистрации и состояние проекта теперь должны сохраняться на протяжении всего жизненного цикла сессии — без кастомных блокировок и workaround с общим состоянием.

Что операторы неправильно настраивали для Vertex

CLAUDE_CODE_MAX_CONTEXT_TOKENS молча игнорировался для model ID с суффиксом @YYYYMMDD — например, claude-fable-5-1@20260901, который использует Vertex AI для версионированных псевдонимов.

Claude Code не распознавал их как известные версии и пропускал переопределение лимита токенов. В gateway proxy, маршрутизирующем через Vertex с версионированными псевдонимами, лимиты контекстного окна откатывались к дефолтным, даже когда переменная была задана. Политики cost control и prompt budget через CLAUDE_CODE_MAX_CONTEXT_TOKENS не применялись для Vertex-pinned model ID.

Исправление распространяет сопоставление model ID на идентификаторы с суффиксом @YYYYMMDD. Если ваш gateway proxy перенаправляет Claude Code сессии на Vertex с версионированными псевдонимами — проверьте, что token limit теперь применяется.

Что проверить и настроить после обновления

Четыре конкретных действия после обновления до 2.1.259:

1. Проверьте использование allowedMcpServers. Если у вас есть managed MCP серверы и вы использовали allowlist для управления тем, какие из них активны — перенесите эту логику в deniedMcpServers до развёртывания 2.1.259. Allowlist больше не фильтрует managed-записи.

2. Оцените managedMcpServers. Если в организации работают внутренние HTTP/SSE MCP серверы — время перенести их в managed layer. Пользователи не будут их настраивать вручную, и серверы не исчезнут из-за редактирования локального конфига.

3. Проверьте multi-agent CI pipeline. Если вы делали кастомные блокировки или сериализацию сессий как обходной путь вокруг бага с параллельными записями — теперь эти workaround можно упростить. Рекомендуется сначала проверить новое поведение в staging, прежде чем убирать старую логику блокировки.

4. Проверьте конфигурацию Vertex model aliases. Если вы проксируете Claude Code на Vertex через @YYYYMMDD model IDs и задаёте CLAUDE_CODE_MAX_CONTEXT_TOKENS — убедитесь, что лимит теперь применяется. Быстрая проверка: запустите сессию против известного Vertex версионированного псевдонима и проверьте, что cap на контекстное окно работает.

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

Изменения managedMcpServers и deniedMcpServers работают на уровне политик Claude Code, выше gateway. Gateway видит эти сессии одинаково независимо от того, какие MCP серверы присутствуют.

Где gateway становится релевантным: если ваши managedMcpServers записи указывают на внутренние HTTP/SSE серверы, эти серверы должны быть доступны из сетевого контекста агента. Команды, использующие TheRouter как gateway для исходящих запросов, должны убедиться, что URL MCP серверов либо маршрутизируются через gateway, либо исключены из него — в зависимости от того, внутренние это или внешние endpoints.

Исправление Vertex @YYYYMMDD напрямую касается команд, использующих TheRouter для проксирования Claude Code трафика на Vertex AI. Если gateway перенаправляет запросы на версионированные псевдонимы Vertex, контекстные лимиты через CLAUDE_CODE_MAX_CONTEXT_TOKENS теперь должны работать end-to-end. Проверьте конфигурацию роутинга, если вы наблюдали неожиданное поведение лимитов контекста на Vertex-pinned моделях.