MCP-сервери в Codex: config.toml, транспорти і чому сервер не відповідає

Агент читає ваш код і виконує команди в терміналі — але не бачить ні завдання в трекері, ні макета у Figma, ні свіжої документації бібліотеки, яку ви оновили вчора. Усе це доводиться копіювати в чат руками. MCP закриває саме цю прогалину: ви один раз оголошуєте зовнішній сервер, і його інструменти зʼявляються в агента під час сесії. Далі — як це робиться в OpenAI Codex: де лежить конфігурація, які ключі в ній працюють, як передати секрет, що робити з сервером, який не відповідає, і скільки таке підключення коштує в токенах.

Коротко (TL;DR)

MCP (Model Context Protocol) — це стандарт, за яким агент підключається до зовнішніх інструментів і даних. Якщо вам потрібно розібратися з самим протоколом — клієнт, сервер, інструменти, ресурси — у нас є окремий матеріал про те, що таке MCP і як він працює. Тут мова тільки про налаштування в OpenAI Codex: що саме писати у файл і які граблі на цьому шляху.

Головне, що варто знати відразу (дані на 11 серпня 2026, Codex CLI версії 0.147.0):

• Налаштування MCP живуть у спільному файлі конфігурації ~/.codex/config.toml, у секціях виду [mcp_servers.<імʼя>] (офіційна документація Codex щодо MCP). Окремого файлу під MCP немає.
• Один конфіг на три поверхні. Застосунок ChatGPT для комп’ютера, Codex CLI і розширення для IDE мають спільну MCP-конфігурацію для одного хоста: налаштували раз — перемикаєтеся між клієнтами без повторного налаштування.
• Транспортів два. Локальний процес (stdio), який Codex запускає сам командою, і віддалений сервер за адресою (Streamable HTTP). Третього варіанта немає.
• Є шлях через термінал: codex mcp add, list, get, remove, login, logout. Команда зручніша для першого налаштування, файл — для того, що потрібно повторювати на новій машині.
• Перевірка підключення — команда /mcp в інтерфейсі Codex: вона показує підключені сервери та їхні інструменти.
• Підключення не безкоштовне. За моїм заміром чотири типові сервери дають 69 інструментів, схеми яких займають близько 13 тисяч токенів контексту в кожному ході — ще до першого рядка вашого коду.

Далі за порядком: транспорти, усі ключі конфігурації, команди, секрети, авторизація, перевірка, розбір відмов, хмара, ціна та довіра до чужих серверів.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Що дає Codex підключений MCP-сервер

Після підключення в агента зʼявляються інструменти — функції, які він може викликати під час сесії сам, без того щоб ви копіювали дані в чат. Сервер Linear віддає інструменти роботи із завданнями, сервер Figma — доступ до макетів, Context7 — свіжу документацію бібліотек.

Оточення хмарних завдань Codex: setup-скрипт, кеш і доступ до інтернету

config.toml і профілі Codex: 6 шарів пріоритету та заборонені ключі проєкту

Сесія Codex CLI на годину роботи: команди, витрата контексту й відкат через git

Codex CLI проти Codex Cloud: десять критеріїв вибору під завдання

DeepSeek Harness вийшов під MIT: відкрита обв’язка ІІ-агентів і реліз V4-Pro

Крім інструментів Codex читає в сервера поле instructions — текст, який сервер повертає під час інціалізації. Codex використовує його як настанову, що діє на весь сервер, поряд з описами окремих інструментів. Офіційна документація радить авторам серверів тримати перші 512 символів цього поля самодостатніми: саме вони доступні моделі тоді, коли вона вирішує, як користуватися сервером.

Практична рамка проста. Вбудованих можливостей Codex — файлова система, команди оболонки, git, вебпошук — достатньо майже для будь-якої роботи всередині репозиторію. MCP потрібен там, де завдання виходить за ці межі: трекер завдань, інструмент дизайну, браузер, база даних, внутрішній сервіс компанії. Це саме говорить і документація OpenAI: MCP беруть, коли агентові потрібні можливості, що живуть поза локальним робочим простором.

Два транспорти Codex: локальний stdio і віддалений Streamable HTTP

Перше рішення під час налаштування — який транспорт. Codex підтримує рівно два, і вони ж є двома стандартними привʼязками в специфікації протоколу.

Про SSE варто сказати окремо, бо навколо нього багато плутанини. Окремого транспорту «HTTP+SSE» більше немає: Streamable HTTP замінив його починаючи з ревізії протоколу 2024-11-05. Але сам механізм Server-Sent Events нікуди не зник — він використовується всередині Streamable HTTP, коли сервер віддає відповідь потоком. Тобто зник транспорт, а не технологія.

Ще одна тонкість для тих, хто копає глибше. Свіжа ревізія специфікації від 28 липня 2026 помітно змінила будову протоколу: прибрала сесію з рукостисканням initialize і заборонила серверу самому ініціювати запити. При цьому всі чотири сервери, які я піднімав для замірів 11 серпня 2026, узгодили попередню ревізію — 2025-06-18, а документація Codex і далі описує читання поля instructions «під час інціалізації». Висновок для практики: екосистема живе на попередній ревізії, і перевіряти стан треба не за посібниками, а за відповіддю самого сервера.

Оголошуємо сервер у config.toml: розбір кожного ключа

Codex зберігає налаштування MCP у config.toml поряд з рештою конфігурації. За замовчуванням це ~/.codex/config.toml. Можна обмежити сервери одним проєктом через .codex/config.toml у репозиторії — але лише для проєктів, яким ви явно довіряєте.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Кожен сервер описується таблицею [mcp_servers.<імʼя>]. Імʼя ви обираєте самі, за ним потім звертаються команди get, remove і login.

Ось робочий приклад локального сервера:

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["LOCAL_TOKEN"]

[mcp_servers.context7.env]
MY_ENV_VAR = "MY_ENV_VALUE"

Ключі stdio-сервера:

А ось віддалений сервер:

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }

Ключі HTTP-сервера:

Спільні ключі працюють для обох транспортів:

Тонко налаштований сервер разом виглядає так:

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
disabled_tools = ["screenshot"]        # застосовується ПІСЛЯ enabled_tools
default_tools_approval_mode = "prompt"
startup_timeout_sec = 20
tool_timeout_sec = 45
enabled = true

[mcp_servers.chrome_devtools.tools.open]
approval_mode = "approve"

Зверніть увагу на screenshot: він стоїть в обох списках, і заборона перемагає. Це офіційний приклад, і він спеціально показує пріоритет.

Ключ type у конфігурацію не пишемо

Сторонніми посібниками кочує рядок type = "stdio" всередині блоку сервера. У довіднику опцій Codex такого ключа немає, і я вирішив перевірити це не на слово, а експериментом на ізольованій копії конфігурації.

У звичайному режимі Codex такий рядок проковтує молча — конфігурація завантажується, сервер працює. Але в CLI є прапорець --strict-config, який сам описаний як «помилитися, якщо config.toml містить поля, не розпізнані цією версією Codex». Під ним той самий файл падає з конкретним формулюванням:

Error: error loading config: .../config.toml:2:1:
unknown configuration field `mcp_servers.withtype.type`

Метод я перевірив контролем: дописав у свідомо валідний конфіг вигаданий ключ bogus_key_check — і режим назвав його на імʼя так само. Тобто перевірка працює, і вердикт щодо type однозначний: цією версією Codex ключ не розпізнається.

Звідки тоді плутанина? Поле type справді існує — але у виводі, а не у вхідному файлі. Команда codex mcp list --json друкує блок transport з полем type і значеннями stdio або streamable_http. Автори посібників бачать його у виводі й переносять у вхідний конфіг. Шкоди від зайвого рядка у звичайному режимі немає, користі — теж.

Команди codex mcp add, list, get і remove

Другий шлях налаштування — термінал, без ручного редагування файлу. Точний синтаксис за версією 0.147.0:

Форма запису в add строга: codex mcp add [OPTIONS] <NAME> (--url <URL> | -- <COMMAND>...). Або адреса, або команда після подвійного дефіса — разом вони не використовуються. Корисні прапорці:

• --env KEY=VALUE — змінні середовища для сервера, тільки для stdio;
• --bearer-token-env-var ENV_VAR — імʼя змінної з токеном, тільки для HTTP;
• --oauth-client-id і --oauth-resource — параметри входу OAuth.

Офіційний приклад додавання безкоштовного сервера документації виглядає так:

codex mcp add context7 -- npx -y @upstash/context7-mcp

А віддалений сервер GitHub, за інструкцією самого GitHub, підключається через точку входу HTTP:

codex mcp add github --url https://api.githubcopilot.com/mcp/ \
  --bearer-token-env-var GITHUB_PAT_TOKEN

Коли що обирати: команда швидша й не дає зробити помилку в імені ключа, а файл відтворюваний — його можна покласти у власні dotfiles і розгорнути на новій машині одним рухом. Тонке налаштування на кшталт enabled_tools чи політики схвалень усе одно робиться файлом.

Змінні середовища і секрети: чим env відрізняється від env_vars

Це та розвилка, на якій застрягають найчастіше: сервер запускається, а токена не бачить. У stdio-сервера є два різні ключі, і вони роблять різні речі.

• env — задає змінним значення. Пишете MY_ENV_VAR = "MY_ENV_VALUE" — процес сервера отримає саме це значення.
• env_vars — перелічує змінні, які дозволено передати із середовища. У довіднику опцій це назване білим списком: ви вказуєте імʼя, а значення підхоплюється з вашого середовища.

Різницю видно у виводі codex mcp list --json: env повертається картою зі значеннями, а env_vars — списком імен. У моєму експерименті це виглядало як "env": {"MY_ENV_VAR": "MY_ENV_VALUE"} проти "env_vars": ["LOCAL_TOKEN"].

У env_vars є розширена форма запису з зазначенням джерела:

env_vars = ["LOCAL_TOKEN", { name = "REMOTE_TOKEN", source = "remote" }]

Простий рядок і source = "local" читають локальне середовище Codex. source = "remote" читає середовище віддаленого виконавця й працює лише з віддаленим stdio.

Окремо про секрети в HTTP-серверів: ключ bearer_token_env_var зберігає імʼя змінної, а не сам токен. Записати токен значенням у config.toml не дає жоден задокументований ключ — і це правильна поведінка, бо конфігурація нерідко потрапляє в dotfiles-репозиторій.

Приємна деталь, яку я побачив в експерименті: табличний вивід codex mcp list маскує значення змінних зірочками (MY_ENV_VAR=*****), залишаючи видимими імена. Конфігурацію можна показати колезі або вставити в тікет, не розкривши секретів.

Авторизація сервера: codex mcp login, bearer-токен і сесія ChatGPT

У stdio-серверів авторизації як окремого механізму немає — і це не недогляд Codex, а вимога специфікації: реалізаціям на stdio наказано не дотримуватися OAuth-специфікації, а отримувати облікові дані із середовища. Звідси й набір ключів: лише env та env_vars.

У HTTP-серверів джерел кілька, і порядок важливий. Ключ auth — це те, що пробується після налаштованих bearer-токенів і заголовків авторизації:

• oauth (значення за замовчуванням) — бере збережені облікові дані MCP-OAuth;
• chatgpt — використовує поточну сесію ChatGPT для довіреної першосторонньої адреси, з відкатом на збережений OAuth.

Важливе застереження з документації: якщо жодне джерело облікових даних не розвʼязалося, Codex може підключитися до сервера взагалі без авторизації. Тобто «підключилося» не означає «авторизувалося», і це варто перевіряти очима.

Для входу в сервера, який вимагає OAuth, є окрема команда:

codex mcp login figma --scopes files:read,file_comments:write

Сама специфікація вимагає від HTTP-транспорту OAuth 2.1 з обовʼязковим PKCE, реалізації Protected Resource Metadata (RFC 9728) на боці сервера і параметра resource за RFC 8707 на боці клієнта. Звідси й ключі scopes та oauth_resource у конфігурації Codex — вони пряме продовження цих вимог.

Два налаштування врятують у незручних випадках:

• mcp_oauth_callback_port (ключ верхнього рівня, в офіційному прикладі 5555) — якщо провайдер вимагає фіксований порт зворотного виклику. Без нього Codex займає довільний вільний порт.
• mcp_oauth_callback_url — якщо потрібна власна адреса зворотного виклику. Тут легко помилитися: цей ключ задає базову адресу, до якої Codex дописує серверний ідентифікатор, і реєструвати в провайдера потрібно повний підсумковий redirect_uri разом із цим суфіксом, а не лише базовий хост.

Де лежать отримані токени, задає ключ mcp_oauth_credentials_store. Припустимі значення — auto, file і keyring, і цей набір я отримав від самого Codex: підставив у конфігурацію свідомо неправильне значення під --strict-config і отримав відповідь «unknown variant bogus_value, expected one of auto, file, keyring». Тобто за замовчуванням (auto) вибір робить сам Codex, а keyring явно просить системне сховище ключів.

Далі починається зона, де я не можу дати гарантії. За розбором вихідного коду на сторонньому ресурсі, при недоступному системному сховищі Codex відкочується на файл $CODEX_HOME/.credentials.json відкритим текстом. Офіційного підтвердження цієї деталі я не знайшов, тому вважаю її ймовірною, але неперевіреною. Практичний висновок від неї не залежить: якщо для вас важливо, де фізично лежить токен від чужого сервісу, ставте keyring явно, а не покладайтеся на auto.

Перевіряємо, що інструменти доїхали до агента

Оголосити сервер і підключити сервер — різні події. Приймання налаштування займає хвилину й робиться трьома способами.

1. /mcp в інтерфейсі Codex. Штатний спосіб: команда показує активні сервери та їхні інструменти. Працює і в термінальному інтерфейсі — якщо ви з ним ще не освоїлися, увесь робочий цикл Codex CLI розібрано окремо, — і в застосунку. Якщо сервер у списку є, а інструментів у нього нуль — проблема на боці сервера, а не конфігурації.
2. codex mcp list у терміналі. Виводить дві таблиці — окремо локальні stdio-сервери, окремо віддалені HTTP — зі стовпцями статусу й авторизації. Прапорець --json віддає те саме машинозрозуміло.
3. codex mcp get <імʼя> --json — конфігурація одного сервера так, як її побачив Codex. Швидкий спосіб зловити помилку в ключі: якщо ви очікували enabled_tools, а у виводі його немає, значить написали не те.

У виводі є поле, якого немає на сторінці документації щодо MCP, — auth_status (у таблиці це стовпець Auth). У stdio-сервера воно показало unsupported, у HTTP-сервера з bearer-токеном — bearer_token. Це найшвидший спосіб побачити, яке джерело облікових даних розвʼязалося, ще до запуску сесії.

Загальна діагностика встановлення — команда codex doctor: вона перевіряє встановлення, конфігурацію, авторизацію і стан runtime. А от точкової перевірки одного сервера в Codex поки немає: команди codex mcp check <server> не існує, це відкритий запит на функціональність у репозиторії з 25 травня 2026.

Сервер MCP не відповідає: пʼять причин і що дивитися в кожній

Найчастіша скарга звучить так: сервер додано, у конфігурації все правильно, а інструментів у агента немає. Причин небагато, і вони добре різняться за симптомом.

Перший рядок я відтворив сам: поклав в ізольовану конфігурацію блок лише з args, без команди й адреси. Codex відповідає так:

Error: failed to load bootstrap configuration
Caused by:
    invalid transport
    in `mcp_servers.broken`

Другий рядок — найбільш недооцінений, і його варто пояснити докладно, бо він розкриває більшість «мовчазних» серверів. Специфікація вимагає від stdio-сервера жорстко: він не має права писати в стандартний вивід нічого, крім валідних повідомлень протоколу; для журналів є стандартний потік помилок. А пакети з npm полюбляють надрукувати під час старту банер, попередження про застарілу версію або підказку. Будь-який такий рядок ламає потік JSON-RPC — і Codex бачить сервер, що відповідає смітником. Перевіряється просто: запустіть ту саму команду в терміналі руками й подивіться, що вона друкує до першого рядка JSON.

Про таймаути корисно знати порядок величин. У моєму замірі «прогріті» сервери піднімалися за 0,62–0,82 секунди, а під час першого холодного запуску із завантаженням пакета — за 1,64–4,91 секунди. Типове обмеження старту — 10 секунд, тобто на швидкому канналі запас є, а на повільному перший запуск у нього вкладається вже не завжди.

Windows-випадок відзначено в репозиторії окремим відкритим тікетом від 30 березня 2026: stdio-сервер падає під час запуску через corepack/npx, але працює при вказанні абсолютного шляху до node.exe. Задачу створено на застосунок для комп’ютера (версія 0.117.0-alpha), але конфігурація в поверхонь спільна, тому ставитися до цього варто як до загальної особливості Windows, а не як до помилки одного клієнта. Якщо частина команди працює на Windows, простіше відразу домовитися про абсолютні шляхи в проєктній конфігурації.

MCP у хмарних задачах проти локального запуску Codex

Тут потрібна чесність, бо посібники зазвичай пишуть «налаштуйте MCP у Codex», не розділяючи поверхні продукту. А поверхні поводяться по-різному.

Станом на 11 серпня 2026 офіційні сторінки про хмарне середовище Codex — будова контейнера, скрипти встановлення, кеш, доступ до інтернету — MCP-сервери не згадують узагалі, а на форумі OpenAI з 7 жовтня 2025 висить відкритий запит на підтримку MCP у хмарних задачах, без відповіді. Прямого формулювання «у хмарі MCP не підтримується» в документації немає, тому коректно говорити про стан документації, а не про неможливість у принципі. Практичний висновок один: розраховувати на MCP у хмарних задачах не варто, а сценарії із зовнішніми інструментами тримати на локальному клієнті.

Дві особливості хмари пояснюють, чому це не лікується обхідними шляхами.

По-перше, мережа. У фазі роботи агента доступ до інтернету за замовчуванням заблокований; скрипт встановлення при цьому виконується з доступом, щоб поставити залежності. Дозволити мережу можна, але осмислено — списком доменів (є готовий набір для збирання залежностей) і, для додаткового захисту, обмеженням методів до GET, HEAD і OPTIONS, за якого POST, PUT, PATCH і DELETE блокуються. Віддалений MCP-сервер, якому потрібен POST на свою точку входу, у таку політику не вписується.

По-друге, секрети. Звичайні змінні середовища живуть усю задачу, а секрети доступні лише скриптам встановлення й з причин безпеки видаляються до початку фази агента. Тобто звична схема «покладу токен сервера в секрети середовища» у хмарі не працює за будовою.

Є експериментальний ключ experimental_environment зі значенням remote, який запускає stdio-сервер через віддалений виконавець, коли той доступний. Але для віддалених HTTP-серверів таке розміщення, за формулюванням довідника, не реалізовано — тож повноцінною відповіддю на «MCP у хмарі» цей ключ вважати не можна.

Скільки контексту коштує десяток серверів: замір на чотирьох

«MCP зʼїдає контекст» — загальне місце, але цифр майже ніхто не наводить. Я вирішив зміряти сам, бо від цього залежить практичне рішення, скільки серверів тримати ввімкненими.

Метод простий і відтворюваний: підняти сервер по stdio, виконати інціалізацію, запитати список інструментів і порахувати, скільки займають їхні схеми — імʼя, опис і JSON Schema вхідних параметрів. Саме ці схеми клієнт зобовʼязаний покласти в промпт, щоб модель знала, що вона може викликати. Рахував тим самим токенізатором, який використовують моделі OpenAI. Замір від 11 серпня 2026:

Тринадцять тисяч токенів за чотири сервери — стільки їде в контекст у кожному ході, до першого рядка вашого коду і до вашого запитання.

Найкорисніше в цій таблиці — не підсумок, а розкид. На один інструмент виходить від 168 до 526 токенів, і «дорогий» сервер — не той, у кого більше інструментів. У Context7 їх лише два, але кожен коштує 526 токенів, бо описи довгі. А в Playwright із його 24 інструментами виходить 168 токенів на штуку. Тобто рахувати треба не сервери й навіть не інструменти, а обсяг описів.

Обумовлю обмеження методу: я міряв самі схеми, а фактичний промпт клієнта додає власне обрамлення навколо кожного інструмента, тому мою цифру чесно вважати нижньою межею. Незалежна оцінка є лише одна: стороння публікація від 8 квітня 2026 дає 200–500 токенів накладних на сервер, 550–1400 токенів на інструмент і близько 55 тисяч токенів за хід у сервера GitHub із 93 інструментами. Це істотно більше за мій замір, метод там не описаний — наводжу як чужу оцінку, а не як факт.

Ціна не лише в токенах. У репозиторії Codex відкритий тікет від 6 травня 2026 про те, що за великої кількості налаштованих серверів виявлення інструментів блокує перший хід, а команди-слеші недоступні, поки триває запуск MCP. Інший відкритий тікет, від 20 липня 2026, описує, як за великого каталогу інструментів зневаджувальні записи пишуть у локальний журнал дампи списку інструментів приблизно по 1,3 МБ. Ще один, уже закритий, був про підвисання застосунку на «токен-важких» серверах.

Лікується це не вимиканням серверів, а урізанням каталогу:

• enabled_tools — залишити в сервера лише ті інструменти, якими справді користуєтеся. З 29 інструментів браузерного сервера в конкретному завданні потрібні три-чотири.
• disabled_tools — прибрати точково те, що заважає; пам’ятайте, що заборона застосовується після дозволу.
• enabled = false — тримати сервер оголошеним, але вимкненим до моменту, коли він знадобиться.

Правильне налаштування десятка серверів — це не «увімкнути пʼять із десяти», а «залишити в кожного ті три інструменти, які потрібні». Ціна падає пропорційно обсягу описів, а не кількості блоків у конфігурації.

Довіра до сторонніх серверів: чим ризикує репозиторій

MCP-сервер — це чужий код, який агент запускає на вашій машині, або чужий сервіс, якому агент надсилає запити. Ризик тут не гіпотетичний, і OpenAI розбирає його на власному прикладі.

Впровадження інструкцій через дані. Усе, що повертає інструмент, модель читає як текст — і не завжди відрізняє дані від настанов. В офіційному розборі є робочий приклад: ви просите Codex виправити проблему за посиланням на завдання, а в його опису схована інструкція виконати команду, яка надсилає останній коміт на сторонній сервер. Якщо агент її виконає, код витече. MCP-сервер — точно такий самий канал недовіреного тексту: відповідь трекера, опис задачі, вміст вебсторінки.

Права інструментів ширші, ніж здається. Деструктивні виклики інструментів обовʼязково вимагають схвалення, якщо інструмент оголосив відповідну анотацію. Ключове слово — «оголосив»: гарантія залежить від добросовісності автора сервера. Керована частина на вашому боці — політика схвалень: default_tools_approval_mode зі значеннями auto, prompt, writes і approve (режим writes запитує щодо інструментів, не позначених як такі, що лише читають) і перевизначення на конкретний інструмент через tools.<інструмент>.approval_mode. Як це стикується із загальними правилами доступу агента, розібрано в матеріалі про режими схвалення і пісочницю.

Секрет іде далі, ніж ви думаєте. Токен, який ви дали серверу, доступний серверу цілком — а не «лише для читання завдань». Особистий токен доступу з широкими правами, відданий чужому серверу, дорівнює видачі цих прав авторові сервера.

Що робити практично:

• давати серверу мінімальні права в самому сервісі, а не покладатися на налаштування Codex;
• тримати default_tools_approval_mode = "prompt" у будь-якого сервера, якому не довіряєте повністю;
• урізати каталог до потрібних інструментів — це водночас і про токени, і про безпеку;
• обирати офіційні сервери постачальника сервісу, а не неофіційні обгортки;
• пам’ятати про типові налаштування: локальний режим пісочниці workspace-write тримає мережу вимкненою, а в хмарі інтернет у фазі агента теж вимкнений за замовчуванням. Ризик створює той, хто ці налаштування послаблює.

Проєктна конфігурація .codex/config.toml заслуговує окремої обережності: вона працює лише для довірених проєктів, і це не формальність. Файл у чужому репозиторії — це чужий список серверів, які запустяться у вас.

Codex сам як MCP-сервер: команда codex mcp-server

У Codex дві ролі, і друга майже не описана в україномовних матеріалах. Якщо пошукати «MCP-сервер для Codex», половина видачі виявиться про сторонні обгортки з назвами на кшталт codex-mcp-server на GitHub — тобто про Codex у ролі сервера для інших агентів. Штатний спосіб для цього є, і чужий пакет для нього не потрібен:

codex mcp-server

Команда описана самим CLI як «запустити Codex як MCP-сервер (stdio)». Вона віддає два інструменти:

• codex — запустити сесію Codex. Крім обовʼязкового prompt приймає перевизначення: політику схвалень, режим пісочниці (read-only, workspace-write, danger-full-access), модель, робочий каталог, окремі налаштування конфігурації.
• codex-reply — продовжити сесію за ідентифікатором потоку.

Оглянути інтерфейс можна інспектором протоколу:

npx @modelcontextprotocol/inspector codex mcp-server

Важливе застереження: у репозиторії цей інтерфейс позначений як експериментальний і такий, що може змінитися без попередження. Для робочого конвеєра це означає «закріпіть версію і чекайте поломок під час оновлення», а не «не використовуйте».

Навіщо це потрібно на практиці: так Codex вбудовується в чужого агента як виконавець — наприклад, оркестратор викликає Codex на завдання по репозиторію й отримує результат. Якщо вам ближчий зворотний сценарій, де Codex залишається головним, — це все, про що йшла мова вище.

MCP, скіл чи плагін: що обрати під завдання

Перед тим як підключати сервер, варто перевірити, чи потрібен він узагалі. У Codex три механізми розширення, і вони розв’язують різні завдання — цю розвилку документація описує прямо, а посібники з налаштування зазвичай пропускають.

Практична драбинка виходить така. Якщо завдання розвʼязується вбудованими можливостями — файли, команди оболонки, git — не підключайте нічого. Якщо це повторюваний процес із вашими правилами — це скіл; до речі, правила проєкту загалом задаються файлом AGENTS.md, і він часто закриває те, для чого люди тягнуться до MCP. Якщо потрібні зовнішні системи — трекер, дизайн, браузер, база — тоді MCP.

Часто найкраща відповідь — комбінація: скіл описує процес і називає, які інструменти MCP використовувати. Різниця в ціні контексту тут не на користь MCP: у скілів працює поступове розкриття, коли заздалегідь видно лише метадані, а в MCP схеми інструментів лежать у контексті весь час.

У серверів, що прийшли з плагіна, є своя особливість: транспорт і команду такого сервера користувацька конфігурація не задає — вони приходять із маніфесту плагіна. Але ввімкненням і політикою інструментів керувати можна, через окрему секцію plugins.<плагін>.mcp_servers.<сервер>.

Якщо ви працюєте і з іншими агентами, корисно порівняти механіку: у Claude Code той самий протокол налаштовується інакше, і розбір MCP у Claude Code показує, де відмінності принципові, а де косметичні.

Які MCP-сервери варто підключити до Codex і як оголосити кожен

Список серверів зростає швидко, тому нижче — ті, що названі в офіційній документації Codex як звичайні робочі варіанти, з типом підключення й точкою уваги під час розбору відмов.

Окремо про підхід до вибору. Спокуса підключити все відразу зрозуміла, але із заміру вище видно, чим це оплачується. Розумна стартова конфігурація — один сервер документації і один сервер того сервісу, де живуть ваші завдання. Браузерні сервери вмикати під конкретну роботу: у них найбільші каталоги.

Що в налаштуванні MCP застаріє першим і чим перевірити в себе

Тема швидко рухається, тому відзначу, що перевіряти насамперед. Змінюються версія CLI і склад підкоманд (на 11 серпня 2026 це 0.147.0, реліз від 7 серпня), набір ключів конфігурації, типові таймаути, підтримка MCP у хмарі, ревізія протоколу і ціна схем у токенах.

Перевіряти краще не за посібниками, а за трьома командами: codex mcp --help покаже актуальний склад підкоманд, codex mcp get <імʼя> --json — як Codex прочитав вашу конфігурацію, а codex doctor — стан встановлення загалом. Якщо сумніваєтеся, чи визнає Codex якийсь ключ, відтворіть мій прийом: запустіть із --strict-config і подивіться, чи не назве він поле невідомим. Ще один надійний хід — звикнути дивитися в /mcp після кожного редагування конфігурації; це дві секунди, а лікує більшість непорозумінь.

Часті запитання

Чи працюють MCP-сервери в хмарних задачах Codex?

Станом на 11 серпня 2026 офіційна документація щодо хмарного середовища MCP-сервери не описує, а запит на таку підтримку висить на форумі OpenAI відкритим з жовтня 2025. Налаштування MCP задокументовано для локальних клієнтів — CLI, розширення IDE і застосунку. Плануйте сценарії із зовнішніми інструментами на локальному запуску.

Де Codex зберігає налаштування MCP і чи можна тримати їх у репозиторії?

У спільному файлі конфігурації: за замовчуванням ~/.codex/config.toml, секції [mcp_servers.<імʼя>]. Проєктний варіант .codex/config.toml у репозиторії теж підтримується, але лише для проєктів, яким ви явно довіряєте. Секретів у файл не пишіть: ключ bearer_token_env_var приймає імʼя змінної середовища, а не сам токен.

Чому сервер додано, але в /mcp немає жодного інструмента?

Найчастіше сервер друкує в стандартний вивід щось поза повідомленнями протоколу — банер, попередження про застарілу версію. Специфікація це забороняє, і потік ламається. Запустіть команду сервера руками в терміналі й подивіться, що вона друкує до першого рядка JSON. Друга за частотою причина — не вистачило типових 10 секунд на старт.

Скільки MCP-серверів можна тримати ввімкненими одночасно?

Жорсткого обмеження немає, але є ціна. За моїм заміром чотири типові сервери дають 69 інструментів і близько 13 тисяч токенів схем у кожному ході. Рахувати треба не сервери, а обсяг описів інструментів: розкид становив від 168 до 526 токенів на інструмент. Краще тримати багато серверів оголошеними, але урізати каталог кожного через enabled_tools.

Чи можна записати токен просто в config.toml?

Жоден задокументований ключ цього не дозволяє: bearer_token_env_var і env_http_headers приймають імена змінних середовища, а не значення. У локальних серверів значення можна задати через env, але це той самий файл, який часто потрапляє в dotfiles-репозиторій, тому для секретів краще використовувати env_vars і тримати значення в середовищі. Де зберігаються OAuth-токени, задає ключ mcp_oauth_credentials_store зі значеннями auto, file і keyring.

Чи потрібен у конфігурації ключ type = “stdio”?

Ні. У довіднику опцій Codex такого ключа немає, а під прапорцем --strict-config ця версія називає його невідомим полем. У звичайному режимі рядок просто ігнорується. Плутанина виникає тому, що поле type є у виводі команди codex mcp list --json зі значеннями stdio і streamable_http — автори посібників переносять вихідне поле у вхідний файл.