AI Extensions, 8 ноября: когда MCP-подключения могут быть общими

Если открыть один MCP-сервер в нескольких проектах, могут появиться отдельные подключения. OpenCode 2.2.6 позволяет включить совместное использование. Однако одинаковое название сервера еще не означает одинаковые настройки. У общего подключения также нет roots: сервер не получает через этот механизм корни каталогов проектов.

Сегодняшний обзор источников

OpenCode v2.2.6 опубликован 6 ноября. Разработчики обещают меньше процессов и более быстрый запуск благодаря общим MCP-подключениям; добавлены и средства для сценарных запусков. Лицензия MIT разрешает использование на своих условиях. Свежий выпуск показывает работу над проектом, но не доказывает безопасность или пригодность. Я не устанавливал эту версию, не измерял запуск и не проверял MCP-серверы с ней.

Начальная точка настройки: установленный OpenCode, его конфигурация MCP и отдельная авторизация сервера при необходимости. Согласно документации MCP, pool по умолчанию выключен.

Какие подключения объединяются

Документация ограничивает объединение каталогами одного сервера OpenCode и подключениями по версии протокола 2026-07-28. Если включен pool, а protocol не указан, используется auto. Старый ответ сервера или явный режим legacy оставляют отдельное подключение для каждого каталога.

У удаленных серверов должны совпадать URL, заголовки, настройки OAuth и учетная запись, а также протокол и тайм-ауты. Названия обычно могут различаться, но авторизация хранится по имени: для OAuth имя тоже должно совпадать. У локальных серверов сравниваются команда, окружение и рабочий каталог.

Общий локальный сервер обслуживает каталоги на той же машине, но не каталоги workspace. Для разных проектов нужен фиксированный cwd. Без него сервер запускается в папке каждого проекта, а OpenCode выводит предупреждение. Менять рабочий каталог ради объединения опасно, если сервер должен видеть только один проект.

Roots и права требуют отдельного решения

У общего подключения нет roots. Запрос ввода от инструмента появляется в том каталоге, который его вызвал. Эти правила не обещают, что сервер сам ограничивает доступ каждым проектом. Я бы сначала проверил доступ к файлам и область учетной записи.

Два проекта с одной широкой учетной записью могут пройти сравнение конфигураций, хотя люди ожидают разных границ данных. Pooling не дает недостающего разрешения. Моя рекомендация: разделять production и staging, а для серверов, зависящих от roots или изменяемого состояния проекта, оставлять pooling выключенным до проверки. Это рекомендации по развертыванию, а не сообщение об обнаруженной уязвимости OpenCode.

Ниже намеренно неисполняемая запись для рецензирования, а не допустимая конфигурация OpenCode. Она хранит решения без секретов и ничего не изолирует.

1. Два каталога запрашивают сервер
2. Сравнение настроек и согласованного протокола
3. Общее подключение только при совпадении; roots отсутствуют

{
  "server_role": "public-documentation-search",
  "pool_requested": true,
  "same_account_scope": "review-required",
  "requires_project_roots": "review-required",
  "fixed_local_cwd": "not-applicable-to-remote",
  "protocol_seen": null,
  "approved": false
}

Для разрешенного пробного запуска подойдут одноразовый сервер и синтетические данные. Сравните pool-off и pool-on в двух каталогах, затем измените одно условие совпадения. Зафиксируйте согласованный протокол, число процессов или подключений и каталог, получающий запрос ввода. Проверьте сервер, которому нужны roots. Успешный вызов инструмента не доказывает изоляцию. Здесь предложен план проверки; результаты не получены.

Сценарный запуск теперь может ждать бесконечно

Выпуск сообщает, что opencode run ждет фоновые shell-команды, подагентов и задания изображений, запущенные его запросом, затем дает модели обработать результаты перед выходом. Встроенного ограничения ожидания нет. Сервер разработки или watcher может удерживать запуск до прерывания. Согласно заметкам, SIGTERM отменяет сессию с ее фоновыми заданиями и завершает процесс кодом 143.

Для CI я бы задал внешний тайм-аут и заранее определил ожидаемый результат. Готовый текст ответа не означает готовность файла, который еще зависит от фонового задания. Появился run -w для новой рабочей копии git; его нельзя сочетать с --continue и --session. Флаг --archived скрывает сценарные сессии из обычных списков и входящих, поэтому журналы задания требуют внимания.

С чего начать

Сервер документации только для чтения и с одинаковой областью учетной записи подходит для небольшого пробного объединения. Серверу с зависимостью от roots нужен отдельный тест. Изменение ожидания в CI стоит проверить даже без pooling. Ни заметки к выпуску, ни популярность не подтверждают реальное поведение конкретного сервера.

Промпты для проверки

• Проверить границы общего MCP (JSON)
• Ограничить ожидание фоновых задач (JSON)