Гайд · TNWS AI

Как включить или отключить plugin в Copilot CLI

6 мин

Управление Copilot CLI plugin командами enable и disable: новая session, repository overlay, Managed policy и проверка результата.

Задача и применимость

Этот материал решает конкретную задачу: временно отключить plugin без uninstall, а затем вернуть его, учитывая repository и managed settings. Он рассчитан на пользователей GitHub Copilot CLI, которые хотят управлять plugins воспроизводимо: понимать источник, фиксировать состояние до изменения, проверять компоненты и иметь рабочий откат.

Plugin может включать custom agents, skills, hooks, MCP servers и другие настройки. Поэтому установка — не косметическое действие. До неё нужно проверить manifest, источник кода, закреплённую версию или ref, permissions и маршрут данных. Название plugin само по себе ничего не доказывает.

Проверенные факты и официальные источники

Проверено 13 сентября 2026 года. Команды copilot plugin enable NAME и copilot plugin disable NAME управляют установленным plugin. Managed plugin/marketplace нельзя локально переопределить. Если активацию определяет repository enabledPlugins overlay, CLI отвергает локальный toggle и сообщает settings file, который контролирует состояние.

Основной первоисточник — 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, чтобы другой инженер мог повторить проверку без устных пояснений.

Пошаговые действия

  1. Проверьте plugin через list --json и сохраните enabled baseline.
  2. Выполните copilot plugin disable NAME.
  3. Если CLI сообщает Managed или repository settings file, не обходите policy; изменяйте источник только через его владельца.
  4. При успехе повторите list и подтвердите enabled:false.
  5. Откройте новую session и проверьте отсутствие функций plugin.
  6. Для возврата выполните copilot plugin enable NAME.
  7. Снова проверьте enabled:true и безопасный сценарий в новой session.
  8. Задокументируйте controlling layer: user, repository overlay или managed policy.

После операции всегда открывайте новую Copilot CLI session. Уже работающий процесс мог загрузить старую конфигурацию. Повторите оба списка и сравните по name, а не по порядку строк. Если изменилось больше одного элемента, не выдавайте результат за успешный до разбора diff.

Готовый шаблон для копирования

Заполните карточку изменения:

Plugin: <name>
Baseline enabled: true/false
Команда disable: <результат>
Controlling layer: user / repository / managed
Settings file из ошибки: <если есть>
Проверка новой session: <результат>
Команда enable: <результат>
Rollback подтверждён: да
Дата проверки документации: 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 позитивный тест,
негативный тест, признаки успеха, риски, очистку и откат.
Отсутствующий факт пометь «нужно проверить вручную».

<вставьте заполненную карточку>

Реалистичный пример входа и ожидаемого результата

Вход. В репозитории plugin release-helper управляется .github/copilot/settings.json; пользователь пытается отключить его глобально.

Ожидаемый результат. CLI не сохраняет бесполезный global toggle, а указывает controlling settings file. Изменение оформляется владельцем репозитория через review; managed policy не обходится.

Доказательством служит фактический 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 вместо догадки.

Типичные ошибки

  • Пытаться обходить Managed badge.
  • Игнорировать указанный settings file.
  • Проверять состояние только в старой session.
  • Использовать uninstall вместо временного disable.

Общая ошибка — оценивать 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

Почему toggle может быть отклонён?

Состояние может определять repository overlay или managed policy.

Что означает Managed?

Локальное конфликтующее значение не может победить управляемую настройку.

Где увидеть enabled?

В выводе plugin list --json.

Нужно ли переустанавливать для enable?

Нет, enable возвращает отключённый установленный plugin.

Итог

Безопасное управление plugin состоит из четырёх частей: проверенного source, точной команды, теста в новой session и сравнения before/after. Marketplace облегчает доставку, но не переносит ответственность за trust. Перед следующим обновлением снова откройте официальную reference, потому что команды, schema и managed behavior могут измениться.

Читайте также

Комментарии

Пока тихо. Скажите первое слово