AI Extensions, 8 листопада: коли MCP-з'єднання можуть бути спільними
OpenCode 2.2.6 додає спільні MCP-з'єднання. Облікові записи, протокол, відсутність roots і очікування фонових завдань визначають межі.
Відкриття одного 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 попереджає про неможливість об'єднання. Змінювати cwd лише заради pooling небажано, якщо сервер мав бачити тільки свій проєкт.
Roots і права перевіряються окремо
Спільне з'єднання не має roots. Запит на введення від інструмента з'являється в каталозі, який його викликав. Жодне правило не обіцяє, що сервер сам забезпечує межі доступу між проєктами. Я спершу перевірив би доступ до файлів і область облікового запису.
Два проєкти з одним широким обліковим записом можуть відповідати умовам конфігурації, хоча люди очікують різних меж даних. Pooling не надає відсутнього дозволу. Рекомендую розділяти staging і production та залишати pooling вимкненим для серверів із залежністю від roots або змінного стану проєкту до перевірки. Це рекомендації щодо розгортання, а не повідомлення про знайдену вразливість OpenCode.
Далі наведено навмисно невиконуваний запис для рецензування, а не правильну конфігурацію OpenCode. Він зберігає рішення без секретів і не забезпечує ізоляції.
- Два каталоги запитують сервер
- Порівняння налаштувань і узгодженого протоколу
- Спільне з’єднання за відповідності; 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 приховує сценарні сесії зі звичайних списків та вхідних, тому журнали завдання стають важливішими.
З чого почати
Сервер документації лише для читання з однаковими межами облікового запису підходить для невеликого тесту pooling. Залежність від roots потребує окремої перевірки. Зміну очікування в CI варто перевірити й без об'єднання. Реальну поведінку конкретного сервера не засвідчують ні нотатки випуску, ні популярність.