Чтобы подключить MCP для Codex, достаточно описать сервер в таблице [mcp_servers.имя] файла config.toml либо добавить его командой codex mcp add, а затем проверить вызов на тестовом репозитории. Один и тот же файл читают приложение, консольный Codex и расширение для редактора, поэтому ошибка в записи сразу видна везде. Схема подходит команде, где доступ инструмента ограничивают списком разрешённых действий и режимом одобрения.
Где лежит настройка
Серверы MCP в Codex описываются в ~/.codex/config.toml или в проектном .codex/config.toml доверенного проекта; поддерживаются локальные STDIO-серверы и удалённые серверы по Streamable HTTP.
Согласно документации Codex, конфигурация общая для консольного клиента, расширения и приложения. Личные подключения кладут в домашний файл, а общие для команды, привязанные к репозиторию, — в проектный, причём проектный файл читается только в доверенных проектах. Это разделение подсказывает порядок: сервер с личным токеном лежит у владельца токена, сервер без секретов можно описать рядом с кодом и согласовать на ревью.
Базовую установку и запуск разбирает статья про Codex CLI, повторяемые процедуры агента — материал про skills в Codex. Здесь речь о подключении внешних инструментов. Другой клиент и другой формат файла описаны в разборе подключения MCP к Claude; копировать оттуда записи в TOML без перевода полей нельзя.
Выбор между локальным процессом и удалённым адресом делают по расположению данных. Локальный STDIO-сервер запускается на машине разработчика и видит то, что видит его пользователь: файлы, локальные базы, переменные оболочки. Удалённый сервер живёт у владельца сервиса, ему передают токен, а вход по OAuth снимает хранение ключа на ноутбуке. Для каждого варианта заранее решите, кто отвечает за обновления и что случается при недоступности сервера.
Определите, какой инструмент нужен и кто за ним отвечает. Для первой проверки хватит сервера документации или чтения репозитория: он безопасен, быстро проверяется и сразу показывает, видит ли Codex список действий.
Запись сервера
Два типа записи различаются набором полей. Для локального процесса указывают command, при необходимости args, env и cwd. Для удалённого сервера нужен url, а доступ задают через bearer_token_env_var, http_headers либо вход по OAuth командой codex mcp login. Список подключённых серверов выводит codex mcp list, а внутри интерактивного сеанса состояние показывает команда /mcp.
| Вид сервера | Обязательное поле | Секрет передают через | Где проверить |
|---|---|---|---|
| Локальный процесс STDIO | command | Поле env или переменная окружения оболочки | codex mcp list и /mcp |
| Удалённый сервер | url | bearer_token_env_var либо codex mcp login | codex mcp list и /mcp |
| Запись для проекта | Тот же набор в .codex/config.toml | Только переменные окружения, а значения секретов остаются вне файла | Открытие проекта в доверенном режиме |
Среди служебных полей три пригодятся сразу. Поле enabled выключает сервер без удаления записи, required прерывает старт Codex при сбое запуска сервера, который вы объявили обязательным, а tool_timeout_sec ограничивает время одного вызова инструмента. Для первых проверок оставьте required выключенным: сбой подключения тогда превращается в сообщение, а работа команды продолжается.
Токен хранят в переменной окружения, а в TOML указывают лишь её имя. Так файл можно показывать на ревью, а ротация ключа сводится к замене переменной. Название сервера задавайте осмысленное: оно попадает в журнал одобрений и в команду /mcp, и по нему человек понимает, к какой системе обращается агент.
Права инструментов
Подключение сервера открывает все его инструменты, пока их список остаётся без ограничений. Codex позволяет сузить этот список: поле enabled_tools задаёт разрешённые действия, disabled_tools убирает лишние уже после разрешающего списка. Для режима одобрения существует параметр default_tools_approval_mode со значениями auto, prompt, writes и approve, а для отдельного инструмента его переопределяет tools.имя.approval_mode. Точный перечень значений проверяйте на странице документации своей версии.
- Выпишите все инструменты сервера и отметьте, какие только читают, а какие создают или удаляют.
- Впишите в
enabled_toolsтолько читающие инструменты, нужные для задачи. - Установите для сервера режим с запросом подтверждения и ослабляйте его по одному инструменту после проверки.
- Для записывающих действий оставьте обязательное одобрение человеком, даже когда описание инструмента выглядит безобидно.
- Сохраните файл, перезапустите сеанс и убедитесь командой
/mcp, что виден именно сокращённый список.
Ограничение на стороне Codex дополняйте ограничением на стороне системы. Токен с правом чтения запретит запись, даже когда модель получит такую идею из текста задачи или комментария к коду. Хорошая привычка — читать описание каждого инструмента глазами: автор сервера пишет его для модели, и расплывчатое описание часто скрывает широкую функцию вроде произвольного запроса к базе. Такие универсальные инструменты исключайте из списка, пока нет отдельной причины и отдельного контроля. Подробнее об отзыве прав и сроках жизни ключей написано в статье про OAuth, токены и отзыв прав в MCP.
Пробный репозиторий
Проверку делают на копии: отдельный репозиторий с фиктивными файлами, тестовый проект в трекере, песочница базы. Боевые данные подключают после того, как вы увидели ожидаемый список инструментов и один правильный ответ.
Поставьте Codex узкую задачу: например, найти в тестовом репозитории файл конфигурации и пересказать его параметры через подключённый инструмент чтения. Нужно увидеть три вещи: что сервер стартовал без ошибок, что вызван именно разрешённый инструмент и что пересказ совпадает с исходным файлом. Затем попросите действие вне списка, например удаление файла, и убедитесь, что Codex отказывает или запрашивает подтверждение.
Какую систему вы бы подключили к Codex первой?
Принимайте результат по таблице проверки: строка на каждый инструмент, столбцы «вызван», «ответ совпал с источником», «режим одобрения сработал». Журнал сеанса сохраните вместе с версией файла конфигурации. Если сервер завис или медленно стартует, увеличьте startup_timeout_sec (по справочнику конфигурации, по умолчанию 10 секунд) и сравните поведение. Повторяйте прогон на другом тестовом наборе, чтобы отличить ошибку записи от особенностей конкретных файлов. Отдельно проверьте реакцию на ошибку доступа: отзовите тестовый токен и посмотрите, что сообщает агент. Корректный итог — прямое сообщение о сбое и возврат к ручной работе; выдуманный ответ вместо данных считается дефектом сервера или инструкции, и допуск к рабочим данным откладывается.
Поддержка набора
После пробного прогона договоритесь о правилах. Новый сервер добавляют через запрос на изменение конфигурации, где указаны назначение, владелец, тип токена, список разрешённых инструментов и режим одобрения. Так проектный файл становится реестром и остаётся компактным даже через полгода работы.
Раз в квартал или после каждого крупного изменения проектов просматривайте реестр и удаляйте записи, которые давно простаивают: каждый забытый сервер продолжает держать доступ, который ему назначили. После обновления пакета сервера повторяйте пробный вызов: набор инструментов мог измениться. Если токен скомпрометирован, сначала отзовите его в самой системе, затем меняйте переменную окружения. Заведите правило и для проектного файла: изменения записей проходят тот же ревью, что и код, а в описании запроса указано, какие данные увидит инструмент. Лимиты и распределение доступа между сотрудниками разобраны в материале про лимиты Codex в команде.
Если вам нужен проект с разбором систем, ролей, журнала и приёмкой, обсудим его на странице про внедрение ИИ в компании. Состав работ и стоимость определим после знакомства с процессом: объём данных, число интеграций и требования к безопасности задают границы проекта.
Откройте тестовый репозиторий и добавьте одну запись командой codex mcp add. В enabled_tools оставьте единственный читающий инструмент, проверьте его в /mcp и попросите Codex сделать один вызов. Расширяйте список лишь после того, как пересказ совпал с источником.