Таймаут MCP в Claude Code: как настроить ожидание запуска

Короткий ответ

Команда CLAUDE_CODE_MCP_STARTUP_WAIT_MS=5000 claude -p "Run the scheduled check" позволяет ждать запуска MCP при первом ходе не более пяти секунд. Задайте CLAUDE_CODE_MCP_STARTUP_WAIT_MS=0, если задание может начаться до готовности любого MCP-сервера.

Переменная появилась в Claude Code 2.1.274 17 сентября 2026 года. В примечании к выпуску точно определены две вещи: значение ограничивает в миллисекундах ожидание перед первым неинтерактивным ходом, а 0 означает, что ждать не нужно. Значение по умолчанию для новой переменной не опубликовано. В заданиях без участия человека указывайте его явно, чтобы будущие изменения значения по умолчанию или системного окружения незаметно не изменили вашу политику запуска.

Неинтерактивным считается запуск с -p или --print — например, проверка в CI, задание cron или задача, запущенная через SDK. Этот переключатель не предназначен для интерактивных терминальных сессий.

Практическое правило выглядит так:

Эти диапазоны — практические рекомендации, а не значения Anthropic по умолчанию. Прежде чем стандартизировать настройки, измерьте собственные серверы.

Что именно задаёт таймаут MCP в Claude Code

Представьте первый ход как отправление поезда, а каждый MCP-сервер — как платформу для пересадки. CLAUDE_CODE_MCP_STARTUP_WAIT_MS определяет, сколько поезд простоит на станции в ожидании пассажиров. Эта переменная не решает, как долго каждый пассажир может добираться до станции, сколько займёт работа после посадки и когда должно завершиться всё путешествие.

Именно узкая область действия делает настройку полезной. До версии 2.1.274 операторы часто обращались к MCP_TIMEOUT, хотя он управляет другими часами. Теперь плановое задание может выбрать короткое окно готовности для первого хода, не приравнивая его к дедлайну каждого подключения к серверу или последующего вызова инструмента.

Четыре таймера — четыре разных решения при сбое

Самая надёжная схема явно называет каждый таймер и отводит ему одну задачу.

Есть также MCP_CONNECT_TIMEOUT_MS со значением по умолчанию 5,000 ms для пакета подключений, блокирующих запуск. Он действует при блокирующем запуске — например, с MCP_CONNECTION_NONBLOCKING=0 или для сервера с alwaysLoad: true. Справочник Anthropic по переменным окружения прямо отделяет его от MCP_TIMEOUT.

Для вызовов инструментов поле timeout у отдельного сервера в .mcp.json переопределяет MCP_TOOL_TIMEOUT для этого сервера. Это уместно, когда запрос к хранилищу данных обоснованно занимает больше времени, чем обращение к тикету. Но на новое ожидание первого хода это по-прежнему не влияет.

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

Воспроизводимый тест с медленным сервером

Границу можно воспроизвести на локальном stdio-сервере, который задерживает только ответ инициализации MCP. Сохраните этот код как slow-mcp.mjs:

import readline from "node:readline";

const delay = Number(process.env.SLOW_MCP_DELAY_MS || 5000);
const lines = readline.createInterface({ input: process.stdin });
const send = message => process.stdout.write(JSON.stringify(message) + "\n");

lines.on("line", line => {
  const request = JSON.parse(line);
  if (request.method === "initialize") {
    setTimeout(() => send({
      jsonrpc: "2.0",
      id: request.id,
      result: {
        protocolVersion: request.params.protocolVersion,
        capabilities: { tools: {} },
        serverInfo: { name: "slow-ready", version: "1.0.0" }
      }
    }), delay);
  } else if (request.method === "tools/list") {
    send({ jsonrpc: "2.0", id: request.id, result: { tools: [] } });
  }
});

Подключите его к Claude Code через slow-mcp.json:

{
  "mcpServers": {
    "slow-ready": {
      "type": "stdio",
      "command": "node",
      "args": ["./slow-mcp.mjs"],
      "env": { "SLOW_MCP_DELAY_MS": "5000" }
    }
  }
}

Запустите CLAUDE_CODE_MCP_STARTUP_WAIT_MS=1000 MCP_TIMEOUT=10000 claude -p "Reply with OK." --mcp-config ./slow-mcp.json --strict-mcp-config --output-format stream-json --verbose.

Флаг --strict-mcp-config исключает из теста посторонние пользовательские и проектные серверы. Потоковый формат показывает раннее событие system/init, включая имя и статус каждого MCP-сервера. При неверной конфигурации в нём также появляется mcp_server_errors.

Что показала локальная проверка

Предварительная проверка запуска Claude Code 2.1.274 до аутентификации использовала сервер с задержкой 5,000 ms. Поскольку вход в окружении не был выполнен, запуск остановился на аутентификации. Измерение охватывает только запуск — именно ту границу, которую мы и проверяем.

Время включает накладные расходы на запуск Claude Code и npx, поэтому эти значения не стоит напрямую закладывать в целевой уровень сервиса. Важен вывод по состояниям: при 0 и 1,000 ms проверка первого хода завершилась, пока сервер оставался в pending, а при 7,000 ms тот же сервер успел сообщить connected. Здесь не измеряются ни задержка модели, ни полная длительность задания.

Проверяйте готовность до начала полезной работы

Таймаут отвечает лишь на вопрос: «Сколько мы готовы ждать?» Для рабочего задания нужен и второй ответ: «Какие инструменты обязательны?»

Используйте двухступенчатую проверку:

1. До запуска основной задачи проверьте доступность каждой обязательной удалённой конечной точки или команды локального сервера. Для настроенных и одобренных серверов claude mcp list выводит такие состояния, как connected, необходимость аутентификации или ошибка подключения.
2. В потоке Claude Code проверьте system/init.mcp_servers. Обязательный именованный сервер должен иметь status: "connected", а запись mcp_server_errors для него должна быть пустой. Для кэшированных и необязательных серверов действуйте по явному списку разрешений.

Если обязательный сервер находится в pending, завершите запуск, не принимая результат основной задачи. Если сервер необязателен, запишите режим ограниченной функциональности в журнал и продолжайте. Так настройка ожидания становится входным параметром политики, а не самой политикой.

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

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

Экономический эффект — прежде всего в скорости отказа

Экономия вычислительных ресурсов реальна, но её легко переоценить. Предположим, 10,000 заданий в месяц иначе ждали бы полные 30 секунд, а вы установили бюджет первого хода в 3 секунды. Максимально можно высвободить 4,500 минут работы раннера.

Сейчас, по данным GitHub, минута работы стандартного 2-ядерного Linux-раннера стоит $0.006, а macOS-раннера — $0.062. По этим тарифам 4,500 минут соответствуют $27 времени Linux или $279 времени macOS до учёта включённых минут. Кроме того, GitHub округляет расход каждого задания вверх до целой минуты, поэтому улучшение на 27 секунд может вообще не повлиять на счёт, если итоговая длительность останется в том же расчётном интервале.

Гораздо важнее операционный выигрыш. Если задание отклоняет проверку готовности за три секунды, у планировщика остаётся время на повторную попытку, уведомление нужного специалиста или переключение на резервный сценарий. Если же задание незаметно запускается без базы данных или трекера задач, оно может выдать правдоподобный, но неполный результат. Обнаружить и исправить его обычно дороже, чем оплатить время раннера.

Если вы также ограничиваете объём больших ответов, руководство по лимитам вывода инструментов Claude Code разбирает эту отдельную часть процесса. Для автоматических установок и сетевой политики дополните проверку готовности доступом к сети на уровне отдельных команд.

Семь сценариев, которым это особенно полезно

1. Плановые финансовые и операционные отчёты

Финансовый специалист запускает отчёт в 6 утра, и заданию нужен MCP-сервер хранилища. Пометьте сервер как обязательный, добавьте небольшой запас к измеренному времени холодного запуска и остановите задание, если подключения нет. Выигрыш не только в скорости: так не появится аккуратно оформленный отчёт, составленный по файлам репозитория в отсутствие актуальных данных.

2. Автоматические проверки рисков в пул-реквестах

Платформенная команда запускает Claude Code для каждого пул-реквеста с высоким риском и рассчитывает на инструменты GitHub, трекера задач и сканера безопасности. Проверка может считать сканер и GitHub обязательными, а трекер задач — необязательным. Разработчики получат быстрый и понятный отказ вместо ревью, из которого незаметно исчезли самые важные свидетельства.

3. Задания для координации релиза

Релиз-менеджер поручает плановому агенту сопоставить влитые изменения, открытые инциденты и статус развёртывания. Для каждого источника можно задать отдельное правило готовности. Если MCP-сервер развёртывания недоступен, задание остановится до подготовки примечаний к релизу, которые могли бы создать ложное впечатление о его безопасности.

4. Ночная сортировка обращений в поддержку

Команда поддержки поручает заданию группировать тикеты, проверять историю аккаунта и готовить ответы. Серверы службы поддержки и клиентских данных обязательны, а Slack может быть необязательным. Ограниченное ожидание не даёт очереди встать, а правило готовности не позволяет додумывать конфиденциальный контекст клиента при отсутствии источника.

5. Ассистенты для реагирования на инциденты

Дежурный инженер запускает неинтерактивную диагностику из оповещения. Короткий бюджет запуска сразу показывает, доступны ли в действительности логи и метрики. Если недоступен любой из обязательных серверов, обёртка может сразу направить инженера к ручной инструкции, не тратя время инцидента на неполную диагностику.

6. Эфемерные раннеры с автомасштабированием

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

7. Мультитенантные агентные продукты

Продукт обслуживает клиентов с разными MCP-подключениями. Одному клиенту нужен Salesforce, другому — Linear, а третьему внешние инструменты не требуются. Список обязательных серверов для каждого запуска позволяет одному слою оркестрации выбирать короткое ожидание для каждого клиента, не превращая самую медленную интеграцию в значение по умолчанию для всех.

Три продукта, которые стоит создать

1. Проверка готовности MCP для Claude Code в CI

Это самая перспективная идея. Продукт представляет собой компактную обёртку для раннера: она читает политику обязательных серверов, запускает Claude Code с явно заданным ожиданием, записывает system/init и возвращает машиночитаемую ошибку готовности до того, как будет принят результат агента.

Спрос узкий, но коммерчески значимый: у запроса claude code automation около 140 поисков в США в месяц, рост за год в данных подсказок составляет 200%, а CPC — $10.88. Пользователи также спрашивают, как запускать Claude Code автоматически и как настроить Claude Code с MCP. Это прямые проявления проблемы настройки.

Минимальная версия, которую уже можно продавать, — CLI с файлом политики, аннотациями GitHub Actions и JSON-данными о каждом запуске. Сложность — в дистрибуции. Anthropic может добавить более развитые встроенные политики готовности, поэтому устойчивую ценность должны обеспечивать история запусков, оповещения и поддержка нескольких агентных сред выполнения.

2. Линтер политик таймаутов

Такой инструмент сканировал бы shell-скрипты, файлы CI, настройки и .mcp.json, а затем отмечал перепутанные таймеры: нулевое ожидание запуска при обязательных инструментах, короткий дедлайн задания вместе с 28-часовым таймаутом инструмента или необязательную интеграцию без ограничения.

Точный запрос mcp server timeout набирает около 10 поисков в США в месяц, а его годовая динамика в данных составляет -67%. Связанный запрос — MCP_TOOL_TIMEOUT; пользователи также спрашивают, как увеличить таймаут Claude Code. Этого спроса достаточно для функции внутри проверки готовности, но недостаточно для отдельной компании.

Для MVP нужны парсеры GitHub Actions, распространённого синтаксиса командной оболочки и конфигурации MCP в Claude Code, а также готовые рекомендации по исправлению. Главный риск — ложная уверенность: по статической конфигурации нельзя узнать реальное распределение времени холодного запуска сервера без измерений во время работы.

3. Телеметрия запуска плановых агентов

Такой продукт превращал бы события system/init в хронологию задержек подключения, состояний pending, неверных конфигураций и запусков с ограниченной функциональностью. Платформенные команды платили бы за тренды и оповещения по множеству репозиториев вместо ручного чтения файлов JSONL.

Здесь действует тот же спрос в 140 поисков в месяц по запросу claude code automation, а claude code browser automation добавляет ещё 40 и тоже показывает рост на 200% за год в данных подсказок. Общий сигнал — команды переводят Claude Code в повторяемые задания, где данные о запуске становятся операционной задачей.

MVP включает сборщик событий, карту обязательных и необязательных серверов и оповещения, когда готовность выходит за целевой показатель сервиса. Сложность — в чувствительности данных. Имена MCP и метаданные инструментов могут раскрывать внутренние системы, поэтому маскирование чувствительных полей и самостоятельное размещение должны входить в основу продукта, а не откладываться до поздней корпоративной доработки.

Ограничения и честный вывод

Эта настройка решает небольшую, но важную часть задачи надёжной автоматизации. Она не исправит сломанный MCP-сервер, не аутентифицирует коннектор с истёкшей сессией, не сократит последующий вызов инструмента и не остановит весь процесс Claude Code.

Не задавайте 0 для задания, чьё первое полезное действие требует MCP. При инициализации сервер может остаться в pending, а ожидание вернётся во время поиска инструмента. Не стоит и увеличивать значение до тех пор, пока нестабильные серверы не начнут выглядеть исправными. HTTP- и SSE-серверы повторяют подключение после временного первого сбоя, но ошибки аутентификации и «не найдено» требуют изменить конфигурацию. Более долгое ожидание лишь откладывает неизбежный вывод.

Кроме того, stdio-серверы не переподключаются автоматически после разрыва связи в середине сессии. Щедрое окно запуска ничего не говорит об их состоянии десять минут спустя.

Лучшая политика строга и намеренно скучна: короткое явно заданное ожидание первого хода, именованные обязательные серверы, проверка статуса, отдельный таймаут инструмента и внешний дедлайн задания. Такой набор даёт полезные ошибки вместо загадочных задержек.

В понедельник выберите одно плановое задание Claude Code, измерьте холодный запуск обязательных MCP-серверов, задайте минимальное честное ожидание и отклоняйте результат, если обязательный сервер остался в pending. Если такой уровень надёжности нужен во всех агентных процессах, я помогу построить промышленную систему.