Claude Code 2.1.274 предупреждает, пока память не кончилась

Вы набираете список «3. 2. 1.», а транскрипт показывает «3. 4. 5.», аккуратно перенумеровав ваши же строки. В 2.1.274 нумерация и маркеры вида «N)» остаются такими, как вы их напечатали, но главная правка релиза на Github другая: видимое предупреждение, когда память подходит к критической отметке, вместе с шагами, как её освободить или безопасно перезапуститься.

Коротко

• Anthropic выпустила 2.1.274 с длинным списком правок: память, MCP, шлюз Claude apps, телеметрия, расширение для VS Code, Slack-интеграция Claude Tag и Code Review получили изменения в одном релизе.
• Новая переменная CLAUDE_CODE_MCP_STARTUP_WAIT_MS ограничивает, сколько первый неинтерактивный ход ждёт подключающиеся MCP-серверы; ноль означает не ждать вовсе, а в stream-json сессиях ожидание до двух секунд убрали.
• Порог, при котором появляется предупреждение о памяти, в описании релиза не назван, как и то, сколько именно памяти освобождают предложенные шаги.

Если вы не следили: предыдущий релиз, 2.1.272, вышел 14 сентября и, по данным справочника Claude Code Ultimate Guide, сводился к исправлениям плюс per-command allowed_domains для Bash, PowerShell и Monitor в auto-режиме с песочницей. Там же отмечают, что незадолго до этого Monitor-наблюдения получили жёсткий дедлайн: максимум 30 минут и 10 в одиночных прогонах -p, а бессрочный вариант убрали.

Фоновые команды перестали останавливаться после 30 минут простоя

Раньше фоновые команды снимались после 30 минут простоя на машинах с умеренной нехваткой памяти. Теперь их останавливают только при критически низкой памяти, а в отладочный лог пишут причину, по которой команду сняли.

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

Ещё один источник лишней работы: installed_plugins.json переписывался почти при каждом старте, если политика плагинов приходит из удалённых managed settings, и Claude Desktop из-за этого перезагружал плагины во всех открытых сессиях. Плагин из .zip заодно перестал отдаваться из устаревшей распаковки после нескольких наложившихся перезагрузок.

CLAUDE_CODE_MCP_STARTUP_WAIT_MS ограничивает ожидание MCP-серверов

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

Сравните с планёркой, которую держат, пока не подтянутся опоздавшие: иногда проще начать и дать им зайти по ходу. Так устроен запуск с --input-format stream-json: первый ход уже не ждёт до двух секунд серверы, чьи инструменты и так откладывает поиск по инструментам, они приходят на следующем ходу.

Две смежные правки про то же ожидание. Флаг --strict-mcp-config с пустым --mcp-config держал первый неинтерактивный ход до MCP_TIMEOUT из-за посторонних MCP-серверов. А первый ход облачной сессии иногда стартовал без инструментов MCP-сервера, поднятого через SDK и не успевшего подключиться.

На Bedrock, Vertex и Foundry по умолчанию включили v2-клиент MCP

Установки на Bedrock, Vertex, Foundry и сборки с отключённой телеметрией переходят на v2-клиент MCP и согласование протокола версии 2026-07-28 с прямыми HTTP-серверами, как это уже работает в остальных установках. Откатиться можно через MCP_SDK_GENERATION=v1 или MCP_PROTOCOL_NEGOTIATION=legacy.

Починили несколько углов транспорта. Серверы, описанные как http, но говорящие только на старом HTTP+SSE, не подключались, если на первый запрос отвечали 422 или другим 4xx. Вызовы инструментов через Streamable HTTP отваливались примерно через пять минут, даже когда для сервера задан больший таймаут. Промпты и ресурсы не обновлялись, когда сервер шлёт уведомление list-changed, не объявив listChanged.

Ошибки стали честнее. Отказ 403 insufficient_scope показывался как истёкший вход, а в 2.1.274 называет недостающие права и отправляет на повторную аутентификацию через /mcp. Секреты, подставленные из ${VAR} в конфигах MCP, перестали протекать в тексты ошибок подключения и в описание инструмента логина.

Проверка лимита трат в шлюзе укладывается в одно обращение к базе

В конфиге шлюза Claude apps появился store.connect_timeout_seconds: таймаут подключения к Postgres, по умолчанию пять секунд. Ошибка старта с недоступной базой указывает на store.postgres_url и на заданный таймаут, а сам старт делает до трёх попыток подключения, так что база, поднявшаяся на несколько секунд позже, не роняет загрузку.

Под нагрузкой проверка лимита трат ходила в базу четыре раза, а сейчас ей хватает одного обращения, и меньше проверок отваливается по таймауту. Заодно поймали необработанный reject, когда Postgres рвёт соединение прямо во время такой проверки. По SIGTERM шлюз даёт незавершённым запросам до 25 секунд вместо мгновенного обрыва всех потоков (CLAUDE_GATEWAY_DRAIN_TIMEOUT_MS).

В телеметрию, которую Claude Desktop и Cowork шлют через шлюз, добавили enduser.sub, субъект из IdP. Реплика предупреждает, когда открытых запросов больше 256, которые она отправляет наверх одновременно, а стартовый лог печатает этот предел. В OpenTelemetry появился атрибут effort у спана claude_code.llm_request, как в событии api_request, и событие claude_code.managed_settings_resolved с источниками managed-настроек.

Порог срабатывания предупреждения о памяти в релизе не назван, как и объём, который освобождают предложенные шаги, так что проверить обещание заранее нечем. Предел в 256 одновременных запросов наверх остался пределом: шлюз о нём предупреждает и пишет его в лог, но не поднимает. И странно, на наш взгляд, что до этого релиза проверка лимита трат стоила четырёх обращений к базе на каждый запрос.

Переход на v2-клиент MCP Если ваши сессии живут на Bedrock, Vertex или Foundry либо телеметрия у вас отключена, после установки 2.1.274 клиент MCP и версия согласования сменятся сами. Проверить стоит прямые HTTP-серверы: на случай поломки есть MCP_SDK_GENERATION=v1 и MCP_PROTOCOL_NEGOTIATION=legacy, но срок жизни этих переключателей в описании релиза не назван. Заодно поищите в конфигах записи с "type": "sdk": они пропускаются с предупреждением, регистрировать внутрипроцессные серверы может только SDK-хост.