Гайд · TNWS AI
Как посмотреть установленные plugins в Copilot CLI
Аудит установленных Copilot CLI plugins через copilot plugin list --json: version, source, marketplace, enabled и installedFrom.
Задача и применимость
Этот материал решает конкретную задачу: получить точный список установленных plugins, их версий, источников и состояния до обновления или удаления. Он рассчитан на пользователей GitHub Copilot CLI, которые хотят управлять plugins воспроизводимо: понимать источник, фиксировать состояние до изменения, проверять компоненты и иметь рабочий откат.
Plugin может включать custom agents, skills, hooks, MCP servers и другие настройки. Поэтому установка — не косметическое действие. До неё нужно проверить manifest, источник кода, закреплённую версию или ref, permissions и маршрут данных. Название plugin само по себе ничего не доказывает.
Проверенные факты и официальные источники
Проверено 13 сентября 2026 года. Команда copilot plugin list показывает установленные plugins. Вариант --json возвращает плоский массив; каждая строка содержит поля { name, marketplace?, version?, enabled, source, installedFrom? }. Старый объект { plugins, errors } больше не является текущим форматом.
Основной первоисточник — GitHub Copilot CLI plugin reference. Для структуры и trust review полезны также официальное создание plugins и официальное создание marketplace. Цены, тарифы и список моделей не используются: они не нужны для процедуры и меняются независимо.
Зафиксируйте copilot version, пользователя и current working directory. Управляемые настройки организации или repository overlay могут иметь приоритет над локальным значением. Если CLI сообщает Managed или указывает controlling settings file, не обходите ограничение: оформите изменение у владельца соответствующего уровня.
Подготовка и модель доверия
Сделайте два baseline: copilot plugin list --json и copilot plugin marketplace list --json. Храните временные копии вне tracked files. Для каждого plugin запишите name, version, source, installedFrom, enabled и marketplace. Для каталога — manifest name, owner и source.
Затем изучите компоненты plugin. Agent или skill может направлять модель, hook — выполнять код на событии, MCP server — обращаться к локальной или внешней системе. Отдельно отметьте write-capable действия и credentials. Для первого теста оставьте только read-only сценарий на тестовых данных.
Определите критерий остановки: неизвестный source, неожиданная смена ref, запрос лишнего scope, появление секрета в выводе, новый hook или write tool. При любом таком сигнале завершите session, отключите plugin и проведите отдельный аудит. Не расширяйте разрешения вслепую.
Для командной эксплуатации назначьте владельца каждого дополнительного marketplace и plugin. Владелец отвечает за периодический просмотр upstream, срок поддержки, проверку обновлений и удаление устаревших компонентов. Без владельца даже безопасный сегодня read-only plugin постепенно превращается в неизвестную зависимость: меняются source, transitive packages, endpoint и организационные требования.
Составьте минимальную тестовую матрицу. Она должна включать запуск CLI без plugin, с plugin, после disable и после rollback. Для marketplace отдельно сравнивайте catalog и installed state: появление новой версии в browse не означает, что локальный plugin уже обновился. Это различие предотвращает ложные отчёты об успешном обновлении и помогает воспроизводить проблему.
Все наблюдения записывайте с датой, точной командой и exit status, чтобы другой инженер мог повторить проверку без устных пояснений.
Пошаговые действия
- Откройте терминал под тем пользователем, чью конфигурацию проверяете.
- Выполните
copilot plugin listи прочитайте человекочитаемый список. - Сохраните структурированный baseline:
copilot plugin list --json > plugins-before.json. - Для каждого элемента проверьте name, enabled, source и installedFrom.
- Если plugin пришёл из marketplace, зафиксируйте его имя и marketplace отдельно.
- Не включайте неизвестный plugin до просмотра его manifest и источника.
- После одного контролируемого изменения сохраните plugins-after.json и сравните массивы по name.
- Удалите временные отчёты, если они раскрывают внутренние пути или названия закрытых репозиториев.
После операции всегда открывайте новую Copilot CLI session. Уже работающий процесс мог загрузить старую конфигурацию. Повторите оба списка и сравните по name, а не по порядку строк. Если изменилось больше одного элемента, не выдавайте результат за успешный до разбора diff.
Готовый шаблон для копирования
Заполните карточку изменения:
Команда: copilot plugin list --json
Ожидаемые plugins: <список>
Проверяемые поля: name, version, enabled, source, installedFrom, marketplace
Неизвестные элементы: <список>
Baseline: plugins-before.json
After: plugins-after.json
Решение: оставить / проверить / удалить
Дата проверки документации: 13.09.2026
Официальный источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-plugin-reference
Готовый prompt для подготовки change request:
Подготовь безопасный план изменения GitHub Copilot CLI plugin по карточке.
Не устанавливай, не удаляй и не меняй конфигурацию сам.
Не придумывай version, source, enabled, permissions или успешный результат.
Верни: baseline, точную команду, проверку manifest, read-only позитивный тест,
негативный тест, признаки успеха, риски, очистку и откат.
Отсутствующий факт пометь «нужно проверить вручную».
<вставьте заполненную карточку>
Реалистичный пример входа и ожидаемого результата
Вход. На рабочей станции ожидаются plugins review-tools и docs-helper; второй должен быть disabled.
Ожидаемый результат. JSON является массивом, содержит две записи и подтверждает enabled:false для docs-helper. Если появляется третий неизвестный source, инженер останавливает изменение и проверяет происхождение.
Доказательством служит фактический JSON list, manifest/source, новая session и безопасный вызов. Объяснение модели или сообщение «готово» без этих признаков недостаточно. Не публикуйте закрытые repository URLs, локальные пути и credentials в issue или общий лог.
Позитивный и негативный тест
Позитивный тест проверяет одну минимальную функцию plugin на тестовом объекте. Заранее запишите ожидаемое действие и убедитесь, что оно read-only. После выполнения сопоставьте output и, если есть внешняя система, её audit log.
Негативный тест проверяет границу: disabled plugin не загружается, удалённый marketplace не виден, неустановленный plugin отсутствует, managed toggle отвергается, а remove без force защищает зависимости. Не используйте реальный destructive call ради демонстрации.
Если поведение не совпало, проверьте precedence: project/personal компоненты могут перекрывать plugin, managed settings — локальные значения, а same-name MCP servers — разрешаться по собственному порядку. Зафиксируйте фактический controlling source вместо догадки.
Типичные ошибки
- Парсить вывод как старый объект plugins/errors.
- Считать list командой активации.
- Игнорировать installedFrom и source.
- Публиковать внутренние пути из JSON.
Общая ошибка — оценивать plugin только по описанию marketplace. Manifest и source являются началом проверки, но не заменяют review кода, компонентов и permissions. Для production предпочтительны закреплённые ref/sha и отдельный процесс обновления с regression tests.
Чек-лист финальной проверки
- Каталог TNWS проверен; title и slug уникальны.
- Синтаксис сверён с официальной документацией на 13.09.2026.
- Baseline plugins и marketplaces сохранён.
- Manifest, owner, source и version/ref/sha проверены.
- Agents, skills, hooks и MCP components перечислены.
- Write-capable действия и credentials оценены отдельно.
- Позитивный read-only тест выполнен.
- Негативный тест подтвердил границу.
- Новая CLI session использует ожидаемое состояние.
- Итоговые list --json отличаются только ожидаемо.
- Откат и отзыв credentials задокументированы.
FAQ
Какой формат у --json?
Текущая справка описывает плоский массив plugins.
Какие поля проверять?
Name, marketplace, version, enabled, source и installedFrom, если они присутствуют.
Меняет ли list состояние?
Нет, это команда чтения.
Зачем baseline?
Он показывает, что последующее действие изменило только выбранный plugin.
Итог
Безопасное управление plugin состоит из четырёх частей: проверенного source, точной команды, теста в новой session и сравнения before/after. Marketplace облегчает доставку, но не переносит ответственность за trust. Перед следующим обновлением снова откройте официальную reference, потому что команды, schema и managed behavior могут измениться.
Читайте также
Как добавить HTTP MCP-сервер в Copilot CLI
Подключение remote MCP server через copilot mcp add --transport http: URL, headers, проверка tools и безопасная диагностика.
Как добавить второй каталог в Copilot CLI через --add-dir
Безопасное использование --add-dir в GitHub Copilot CLI: доступ к файлам, доверенные skills/agents, относительные пути и проверка.
Как добавить локальный MCP-сервер в Copilot CLI
Подключение локального stdio MCP server через copilot mcp add: команда после --, проверка tools, sandbox status и безопасный откат.
Комментарии
Пока тихо. Скажите первое слово