Команда Codex CLI /plugins: установка и управление плагинами

Слеш-команда Codex CLI /plugins применяется для просмотра установленных и доступных плагинов, а также управления ими — подключения, отключения, обновления и удаления расширений, которые добавляют Codex CLI новые возможности. На практике это один из самых удобных способов понять, какие инструменты уже доступны в текущей среде, какие из них активны и почему конкретная команда или интеграция работает не так, как ожидалось.

/plugins — это не просто список расширений, а точка управления дополнительными возможностями Codex CLI: от подключения внешних инструментов до контроля состояния уже установленных компонентов.

Команда особенно полезна в проектах, где Codex CLI используется не в одиночку, а вместе с репозиториями, внутренними сервисами, агентскими сценариями и сторонними интеграциями. Важно понимать разницу между плагином, приложением, навыком и MCP-сервером: внешне они могут решать похожие задачи, но подключаются и работают по-разному. Ниже разберём, как пользоваться /plugins, когда она действительно нужна, какие действия с её помощью выполняются и чем она отличается от команд /apps, /skills и /mcp.

Как использовать /plugins

Раздел с использованием команды важен потому, что у пользователя обычно возникает не один вопрос «как показать плагины», а сразу несколько: где увидеть доступные расширения, как понять их статус, как включить нужное, как удалить неиспользуемое и что делать при конфликте версий. Команда /plugins предназначена именно для работы с этим жизненным циклом.

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

Вызов выполняется непосредственно в интерактивном интерфейсе Codex CLI. Введите команду /plugins и подтвердите действие. В зависимости от версии CLI и способа поставки расширений может открыться список плагинов, меню управления или справочная информация с доступными подкомандами.

$ /plugins

Плагины:
- code-review     установлен, включён
- github-tools    установлен, отключён
- issue-tracker   доступен для установки

Действие: выбрать плагин или открыть подробности

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

Статус	Что означает	Что можно сделать
Доступен	Плагин найден в каталоге или источнике установки, но ещё не добавлен в окружение	Установить и проверить совместимость
Установлен	Файлы или описание плагина присутствуют в системе	Включить, отключить, обновить или удалить
Включён	Codex CLI может использовать возможности плагина в текущей сессии	Проверить команды, разрешения и настройки
Отключён	Плагин установлен, но не участвует в работе CLI	Включить при необходимости
Недоступен	Источник, зависимость или требуемая версия не найдены	Проверить сеть, версию и настройки источника
Ошибка	Плагин не запустился или не прошёл проверку	Открыть журнал, проверить конфигурацию и зависимости

В меню управления обычно доступны действия вроде просмотра сведений, включения, отключения, обновления и удаления. Точные названия пунктов могут различаться между версиями Codex CLI, поэтому безопаснее ориентироваться на встроенную подсказку, а не механически копировать команду из старой инструкции.

$ /plugins

Выберите действие:
1. Показать установленные
2. Показать доступные
3. Открыть сведения о плагине
4. Включить или отключить
5. Обновить
6. Удалить

Просмотр списка плагинов

Самый простой сценарий — проверить, какие расширения уже установлены и какие из них активны. Это удобно после установки Codex CLI, перед началом работы в новом проекте или при переносе окружения на другой компьютер.

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

Поле	Зачем оно нужно	На что обратить внимание
Имя	Позволяет отличить один плагин от другого	Не путайте похожие названия и форки
Версия	Показывает, насколько свежая установленная сборка	Проверьте совместимость с версией CLI
Источник	Указывает, откуда получен плагин	Для рабочих проектов предпочтительны проверенные источники
Состояние	Показывает, используется ли плагин сейчас	Отключённый плагин не всегда является сломанным
Разрешения	Объясняет, к каким данным и действиям получает доступ расширение	Особенно важны доступ к файлам, сети и внешним сервисам

$ /plugins

Фильтр: установленные

Название       Версия   Состояние    Разрешения
code-review    1.4.2    включён      чтение файлов, анализ diff
github-tools   0.9.1    отключён     API GitHub, чтение репозитория

Включение и отключение

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

Отключайте плагины, которые конфликтуют между собой, замедляют запуск, требуют лишних разрешений или не нужны в конкретном проекте. Включать всё подряд — стратегия примерно уровня «поставить все кнопки на пульт и нажимать наугад».

Ситуация	Лучшее действие	Почему
Плагин нужен сегодня, но не постоянно	Включить на время	Не требуется удалять и устанавливать его повторно
Появился конфликт функций	Отключить один из плагинов	Проще найти причину проблемы методом исключения
Плагин больше не используется	Удалить	Освободить место и уменьшить поверхность риска
Плагин подозрительно ведёт себя	Отключить и проверить журнал	Активное расширение не должно оставаться без контроля

$ /plugins

Плагин: github-tools
Действие: отключить

Результат:
- плагин отключён;
- сохранён в списке установленных;
- изменения вступят в силу для новых операций.

Установка и удаление

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

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

Проверка перед установкой	Почему важна
Совместимость с версией Codex CLI	Старый плагин может не поддерживать текущий интерфейс
Источник и автор	Помогают оценить доверие к компоненту
Набор разрешений	Показывает, какие действия сможет выполнять расширение
Зависимости	Отсутствующая библиотека или сервис может привести к ошибке запуска
Дата последнего обновления	Позволяет понять, поддерживается ли проект

$ /plugins

Выбран плагин: issue-tracker
Версия: 2.1.0
Источник: корпоративный каталог
Разрешения: чтение задач, создание комментариев

Подтвердить установку? да

Результат: плагин установлен, но отключён до проверки настроек.

Обновление и проверка версии

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

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

Этап	Что проверить	Ожидаемый результат
До обновления	Текущую версию и резервную конфигурацию	Можно вернуться к рабочему состоянию
Во время обновления	Ошибки зависимостей и запросы разрешений	Новые требования понятны и обоснованы
После обновления	Запуск, авторизацию и ключевые команды	Плагин выполняет прежние задачи
При сбое	Журнал, переменные окружения и совместимость	Причина локализована, а не скрыта повторными попытками

$ /plugins

Плагин: code-review
Текущая версия: 1.4.2
Доступна версия: 1.5.0

Действие: обновить
Результат: обновление завершено

Проверка:
- чтение diff: успешно;
- анализ изменённых файлов: успешно;
- публикация отчёта: требует повторной авторизации.

Просмотр подробностей и разрешений

Подробная карточка плагина нужна, когда одного названия недостаточно. В ней могут отображаться описание, команды, настройки, переменные окружения, требуемые разрешения и сведения о состоянии подключения.

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

Тип разрешения	Пример использования	Риск, который нужно учитывать
Чтение файлов	Анализ исходного кода и конфигурации	Плагин может увидеть секреты, случайно попавшие в файлы
Запись файлов	Генерация отчётов или исправлений	Возможны нежелательные изменения
Сетевой доступ	Обращение к API GitHub, Jira или внутреннего сервиса	Нужно контролировать адреса и передаваемые данные
Выполнение процессов	Запуск тестов, линтеров или системных команд	Ошибочная команда может изменить окружение

$ /plugins

Плагин: issue-tracker
Разрешения:
- чтение переменной TRACKER_URL;
- чтение задач проекта;
- создание комментариев;
- сетевой доступ к tracker.example.com.

Ограничения:
- удаление задач запрещено;
- доступ к файлам вне рабочего каталога запрещён.

Когда применять /plugins

Эта команда нужна не только администратору или человеку, который устанавливает расширения. Обычному пользователю она помогает разобраться в поведении Codex CLI: почему не появляется нужная функция, откуда взялась новая команда, почему один проект видит интеграцию, а другой — нет, и какой компонент отвечает за конкретное действие.

Если поведение CLI изменилось после установки расширения, сначала проверьте состояние плагинов, а уже потом меняйте проектные настройки или переустанавливайте весь инструмент.

Есть несколько типичных ситуаций, в которых /plugins особенно полезна:

• после первоначальной установки Codex CLI нужно проверить окружение;
• в проекте требуется подключить интеграцию с системой задач, репозиторием или внутренним API;
• нужно временно отключить расширение для диагностики конфликта;
• необходимо проверить, какие разрешения получает сторонний компонент;
• появилась новая версия плагина и нужно оценить смысл обновления;
• команда, которая раньше работала, перестала находить внешний сервис;
• один и тот же проект запускается на разных машинах с различными наборами возможностей.

Задача пользователя	Когда открыть /plugins	Что искать
Понять, установлен ли компонент	Перед первой настройкой интеграции	Имя и статус плагина
Устранить конфликт	После неожиданного поведения CLI	Недавно включённые расширения
Подготовить рабочее место	Перед началом проекта	Минимальный необходимый набор
Проверить безопасность	Перед подключением стороннего плагина	Источник, разрешения и зависимости
Восстановить интеграцию	После ошибки авторизации или обновления	Версию, токен и состояние подключения

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

Область	Типичное назначение	Преимущество	Ограничение
Пользовательская	Личные инструменты и привычные интеграции	Доступна в нескольких проектах	Можно случайно внести лишнее в рабочую среду
Проектная	Инструменты, необходимые конкретному репозиторию	Воспроизводимость для команды	Требует явной настройки и документирования
Системная	Общие политики и корпоративные расширения	Централизованный контроль	Пользователь может не иметь права менять настройки
Временная сессия	Проверка или диагностика	Минимальное влияние на окружение	Настройки могут не сохраниться

При диагностике полезно действовать последовательно, не меняя сразу несколько параметров. Сначала зафиксируйте текущий список, затем отключите подозрительный плагин, повторите операцию и сравните результат. Если проблема исчезла, включите компоненты по одному — такой подход напоминает поиск неисправной лампочки, только без риска стоять на табуретке.

1. Откройте /plugins и сохраните список установленных компонентов.
2. Проверьте, какие плагины были недавно включены или обновлены.
3. Отключите только один подозрительный компонент.
4. Повторите действие, на котором возникала ошибка.
5. Изучите журнал и карточку плагина, если проблема сохранилась.
6. Верните рабочую конфигурацию после завершения проверки.

Сценарий диагностики

1. /plugins
2. Зафиксировать: code-review включён, github-tools включён
3. Отключить github-tools
4. Повторить запрос к локальному репозиторию
5. Если ошибка исчезла — проверить токен и версию github-tools
6. Включить плагин после исправления

Не стоит устанавливать расширение только потому, что оно «может пригодиться когда-нибудь». Каждый дополнительный компонент увеличивает число зависимостей, разрешений и потенциальных точек отказа. Хорошая практика — держать активными только те плагины, которые действительно нужны текущему рабочему процессу.

Подход	Плюсы	Минусы	Когда выбирать
Активировать всё	Не нужно переключать компоненты	Больше конфликтов и разрешений	Только для краткого эксперимента
Минимальный набор	Проще контролировать среду	Иногда требуется ручное включение	Для ежедневной работы и продакшена
Разные профили	Удобно разделять задачи	Нужно документировать профили	Для разработчиков с несколькими типами проектов
Временное включение	Малое влияние на основную конфигурацию	Можно забыть включить нужный компонент	Для редких интеграций и диагностики

Примеры использования /plugins

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

Пример 1. Первичная проверка после установки

После установки Codex CLI не следует предполагать, что все нужные расширения уже активны. Сначала откройте список и определите, какие компоненты присутствуют, какие выключены и какие можно установить из доступного источника.

$ /plugins

Установленные:
- code-review 1.4.2 — включён
- test-runner 2.0.0 — включён

Доступные:
- github-tools 0.9.1
- issue-tracker 2.1.0

Рекомендация:
для анализа кода текущей конфигурации достаточно;
интеграции с внешними сервисами пока не подключены.

Практический вывод

Цель: запускать тесты и анализировать diff.

Нужны:
- code-review — оставить включённым;
- test-runner — оставить включённым.

Не нужны:
- github-tools — не устанавливать без задачи;
- issue-tracker — не устанавливать без доступа к трекеру.

Пример 2. Временное отключение конфликтующего плагина

Представим, что два расширения пытаются обрабатывать один и тот же тип запроса. Вместо удаления обоих компонентов отключите один, повторите операцию и проверьте результат. Это позволяет быстро определить источник конфликта без разрушения конфигурации.

$ /plugins

Активные плагины:
- formatter-a — включён
- formatter-b — включён

Наблюдение:
оба плагина изменяют форматирование Markdown.

Действие:
отключить formatter-b временно.

После повторной проверки

Результат: форматирование выполняется один раз, дублирования нет.

Вывод:
formatter-b вызывает конфликт с formatter-a.

Следующий шаг:
оставить formatter-b отключённым или настроить разные области ответственности.

Пример 3. Установка интеграции с системой задач

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

$ /plugins

Плагин: issue-tracker
Описание: чтение задач и публикация комментариев
Версия: 2.1.0
Разрешения:
- читать задачи проекта;
- создавать комментарии;
- сетевой доступ к tracker.example.com.

Действие: установить

Подтверждение: да
Результат: установлен, отключён до настройки авторизации.

Настройка после установки

1. Включить issue-tracker через /plugins.
2. Проверить адрес рабочего пространства.
3. Выполнить авторизацию.
4. Запросить одну тестовую задачу.
5. Убедиться, что создание комментария разрешено политикой проекта.

Важно: не передавать плагину токен с правами удаления задач,
если для работы достаточно чтения и комментариев.

Пример 4. Обновление плагина перед большим изменением

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

$ /plugins

Плагин: code-review
Установленная версия: 1.4.2
Доступная версия: 1.5.0

Изменения:
- улучшен анализ TypeScript;
- исправлена обработка больших diff;
- добавлена проверка конфигурации.

Действие: обновить
Результат: версия 1.5.0 установлена.

Проверка после обновления

Проект: backend-api
Проверки:
- анализ небольшого diff — успешно;
- анализ большого diff — успешно;
- поиск небезопасного ввода — успешно;
- формирование отчёта — успешно.

Решение:
обновление можно использовать в основном рабочем процессе.

Пример 5. Проверка разрешений перед подключением

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

$ /plugins

Плагин: deployment-helper
Запрашиваемые разрешения:
- чтение файлов проекта;
- доступ к переменным окружения;
- сетевой доступ;
- запуск внешних процессов;
- запись в каталог build.

Оценка:
для локальной сборки доступ к переменным окружения не требуется.

Действие:
отменить установку до уточнения конфигурации.

Безопасный вариант

1. Установить плагин в тестовом окружении.
2. Передать только TEST_API_URL.
3. Запретить доступ к production-токенам.
4. Ограничить запись каталогом build.
5. Проверить журнал действий.
6. Только после этого рассмотреть рабочее подключение.

Пример 6. Восстановление после ошибки авторизации

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

$ /plugins

Плагин: github-tools
Состояние: включён
Проверка подключения: ошибка 401 Unauthorized

Диагностика:
- плагин найден;
- версия совместима;
- токен не принят сервисом.

Действие:
обновить авторизацию, не переустанавливая плагин.

Порядок восстановления

1. Проверить, не истёк ли токен.
2. Убедиться, что токен принадлежит нужной учётной записи.
3. Проверить разрешения токена.
4. Повторить авторизацию.
5. Выполнить безопасный запрос только на чтение.
6. Не публиковать токен в журнале или переписке.

Пример 7. Удаление неиспользуемого плагина

Если расширение больше не нужно, его можно удалить. Но сначала проверьте, не зависит ли от него другой компонент и не используются ли его настройки в проекте. Удаление должно быть осознанным, особенно в командной среде.

$ /plugins

Плагин: legacy-reporter
Состояние: отключён
Последнее использование: более шести месяцев назад
Зависимости: не обнаружены
Проектные настройки: не используются

Действие: удалить
Подтверждение: да
Результат: плагин удалён из пользовательского окружения.

После удаления

Проверено:
- Codex CLI запускается;
- активные плагины работают;
- проектная конфигурация не содержит ссылок на legacy-reporter;
- сохранён экспорт списка активных компонентов.

Решение:
удаление безопасно, восстановление при необходимости возможно из каталога.

Пример 8. Сравнение окружений на двух машинах

Разные результаты на ноутбуке и сервере часто объясняются различиями в плагинах. Сравните имена, версии, статусы и источники. Сам факт одинакового названия ещё не означает одинаковое поведение: версии могут отличаться.

Машина разработчика — /plugins

code-review   1.5.0   включён
test-runner   2.0.0   включён
github-tools  0.9.1   включён

CI-сервер — /plugins

code-review   1.4.2   включён
test-runner   2.0.0   включён
github-tools  отсутствует

Причина различий:
сервер использует старую версию анализатора и не имеет интеграции GitHub.

Действие:
согласовать версии и явно задокументировать состав окружения.

Пример 9. Поиск причины медленного запуска

Большое количество активных расширений может увеличивать время запуска или выполнять проверку внешних сервисов. Отключайте компоненты по одному, измеряя результат, а не удаляйте их сразу.

Исходное состояние

Активны:
- code-review
- test-runner
- github-tools
- issue-tracker
- deployment-helper

Время запуска: 8,4 секунды

План:
временно отключить интеграции, которые не нужны для локального анализа.

Результат диагностики

После отключения github-tools и deployment-helper:
время запуска: 3,1 секунды

Вывод:
задержку создаёт один из сетевых плагинов или их совместная инициализация.

Следующий шаг:
включать их по одному и проверить журнал запуска.

Пример 10. Подготовка минимального набора для проекта

Для нового репозитория полезно заранее определить, какие плагины действительно нужны команде. Это снижает различия между рабочими местами и помогает новичку не тратить полдня на угадывание, почему у коллеги есть дополнительная команда, а у него нет.

Проект: payments-service

Обязательные:
- code-review 1.5.0 — анализ изменений;
- test-runner 2.0.0 — запуск тестов.

Опциональные:
- issue-tracker — только для владельцев задач;
- github-tools — только для сопровождения pull request.

Запрещённые без отдельного согласования:
- deployment-helper — имеет доступ к окружению развёртывания.

Рекомендуемая проверка нового рабочего места

1. Открыть /plugins.
2. Сверить обязательные плагины и версии.
3. Проверить, что обязательные компоненты включены.
4. Убедиться, что production-интеграции отключены.
5. Выполнить тестовый анализ и локальный запуск тестов.
6. Зафиксировать результат в документации проекта.

Чем /plugins отличается от /apps, /skills и /mcp

Похожие названия часто создают путаницу: пользователь видит несколько способов расширить Codex CLI и не понимает, куда обращаться за конкретной интеграцией. Команда /plugins управляет плагинами, а /apps, /skills и /mcp относятся к другим уровням расширения или подключения возможностей. Конкретный набор подкоманд и внешний вид меню может зависеть от версии Codex CLI, поэтому ссылки ведут на актуальную документацию CLI.

Плагин — это компонент управления возможностями, приложение — подключаемый сервис или интерфейс, навык — описание методики выполнения задачи, а MCP-сервер — стандартизированный источник инструментов и данных.

Границы между этими понятиями могут немного отличаться в разных версиях продукта, но для практической работы удобно придерживаться следующей модели: /plugins отвечает за расширения, /apps — за подключаемые приложения и сервисы, /skills — за специализированные инструкции и сценарии, а /mcp — за серверы, предоставляющие инструменты по протоколу MCP.

Команда	Чем управляет	Основной вопрос пользователя
/plugins	Плагинами и их состоянием	Какие расширения установлены и активны?
/apps	Подключёнными приложениями или сервисами	К каким внешним приложениям можно обратиться?
/skills	Навыками, сценариями и специализированными инструкциями	Какой готовый способ выполнения задачи доступен?
/mcp	MCP-серверами и их инструментами	Какие внешние инструменты и ресурсы предоставляет сервер?

/plugins и /apps

Плагин обычно воспринимается как расширение самого рабочего окружения: он может добавлять команды, обработчики, настройки или связку с определённым процессом. Приложение чаще представляет собой внешний сервис или подключаемый продукт, с которым Codex CLI взаимодействует через установленное соединение.

Например, плагин может добавлять механизм анализа изменений, а приложение — давать доступ к задачам в системе управления проектами. В реальной конфигурации эти сущности могут использоваться вместе: плагин обеспечивает логику, а приложение — внешний источник данных.

Критерий	Плагин	Приложение
Уровень	Расширение CLI	Подключаемый внешний сервис или продукт
Основная роль	Добавляет или изменяет возможности среды	Предоставляет данные, интерфейс или сервисные операции
Тип настройки	Версия, состояние, разрешения, зависимости	Аккаунт, адрес, область доступа, авторизация
Типичная проблема	Несовместимость или конфликт расширений	Ошибка авторизации или недоступность сервиса
Команда управления	/plugins	/apps

Пример выбора команды

Нужно понять, установлен ли анализатор diff:
используйте /plugins.

Нужно проверить, подключён ли рабочий трекер задач:
используйте /apps.

Нужно выяснить, почему внешний сервис отвечает 401:
сначала проверьте /apps и состояние авторизации,
а затем — плагин, который использует этот сервис.

/plugins и /skills

Навык — это прежде всего описание того, как выполнять определённую задачу. Он может содержать инструкции, ожидаемый формат результата, последовательность действий и правила использования инструментов. Плагин же отвечает за компонент или расширение, благодаря которому такая работа становится возможной или удобной.

Простой пример: навык может объяснять, как проводить ревью pull request по внутреннему чек-листу, а плагин — предоставлять функции доступа к репозиторию и формирования отчёта. Навык без нужного инструмента может дать только текстовую рекомендацию, а плагин без подходящего навыка может предоставить возможности без конкретной методики применения.

Свойство	Плагин	Навык
Что добавляет	Функциональный компонент или интеграцию	Методику, инструкции или сценарий
Главный объект управления	Установка и состояние компонента	Доступность и применение навыка
Зависимость от кода	Обычно имеет исполняемую часть или интеграцию	Может состоять преимущественно из инструкций
Пример	Плагин анализа безопасности	Навык подготовки отчёта по найденным рискам
Команда	/plugins	/skills

Сценарий

Задача: провести ревью API.

Шаг 1:
через /skills найти навык «API security review».

Шаг 2:
через /plugins проверить, активен ли security-analyzer.

Шаг 3:
запустить ревью по правилам навыка.

Вывод:
skill задаёт методику, plugin предоставляет часть возможностей.

/plugins и /mcp

MCP-сервер — это отдельный источник инструментов, ресурсов или данных, доступ к которому организован через протокол Model Context Protocol. Он может предоставлять Codex CLI функции работы с базой данных, файловым хранилищем, системой задач или внутренним API. Команда /mcp нужна для просмотра и управления именно такими подключениями.

Плагин и MCP-сервер могут быть связаны, но это не одно и то же. Плагин может помогать настроить, обнаружить или использовать MCP-сервер, однако сам сервер остаётся отдельным поставщиком инструментов. Если проблема заключается в том, что сервер не отвечает, начинать диагностику следует с /mcp, а не только с /plugins.

Критерий	Плагин	MCP-сервер
Назначение	Расширить или изменить работу CLI	Предоставить инструменты, ресурсы или данные
Где обычно находится	В окружении Codex CLI	Локально, в контейнере или во внешней инфраструктуре
Что проверяют	Версию, статус и разрешения	Соединение, доступность и список инструментов
Типичная ошибка	Компонент не загрузился	Сервер не отвечает или инструмент недоступен
Команда	/plugins	/mcp

$ /mcp

Подключённые серверы:
- project-files — доступен
- issue-tracker-mcp — ошибка соединения

Плагин issue-tracker установлен и включён.

Вывод:
проблема находится на уровне MCP-сервера или его подключения,
а не на уровне установки плагина.

Как выбрать правильную команду

Чтобы не запоминать абстрактные определения, задайте себе вопрос: что именно вы хотите проверить или изменить? Если речь идёт о компоненте Codex CLI — открывайте /plugins. Если нужно подключение к внешнему приложению — используйте /apps. Если нужен готовый набор инструкций — ищите его через /skills. Если требуется внешний инструмент или источник данных по MCP — проверяйте /mcp.

Запрос	Правильная команда	Пример результата
Какие расширения установлены?	/plugins	Список плагинов и их статусы
Подключён ли GitHub или трекер задач?	/apps	Список приложений и состояние авторизации
Есть ли инструкция для миграции базы?	/skills	Доступные навыки и сценарии
Доступен ли сервер с данными проекта?	/mcp	Серверы и предоставляемые инструменты
Почему появилась новая функция CLI?	/plugins	Недавно установленное или включённое расширение

Быстрая диагностика

Вопрос: не работает запрос к задачам.

1. /apps — проверить подключение приложения.
2. /mcp — проверить сервер и его инструменты.
3. /plugins — проверить расширение, которое вызывает интеграцию.
4. /skills — проверить, не требует ли сценарий специального навыка.
5. Снова выполнить безопасный запрос на чтение.

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

Симптом	Вероятный уровень проблемы	Первая проверка
Не найден ожидаемый сценарий	Навык	/skills
Команда расширения отсутствует	Плагин	/plugins
Сервис не принимает запрос	Приложение	/apps
Инструмент внешнего сервера недоступен	MCP	/mcp
Всё установлено, но результат непредсказуем	Конфликт или несовместимость	Сравнить версии и отключить компоненты по одному

Итоговое правило простое: /plugins отвечает за каталог и состояние плагинов, но не является универсальным меню всех возможностей Codex CLI. Используйте её для управления расширениями, а соседние команды — для своих уровней конфигурации. Такой подход делает окружение прозрачнее, упрощает диагностику и помогает не лечить ошибку авторизации удалением совершенно исправного плагина.