Гайд · TNWS AI

Как удалить MCP-сервер из Copilot CLI

GitHub CopilotCopilot#GitHub Copilot #Copilot CLI #MCP

13 сентября 2026 6 мин—

Безопасное удаление user-level MCP server через copilot mcp remove и правильная работа с workspace .mcp.json.

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

Этот гайд решает конкретную задачу: удалить ненужный user-level server и не пытаться той же командой стереть репозиторную workspace-конфигурацию. Он нужен администраторам и разработчикам, которые управляют Model Context Protocol в GitHub Copilot CLI и хотят доказуемо контролировать источники, инструменты и права. MCP server расширяет возможности агента, поэтому даже read-only интеграцию следует рассматривать как границу доверия.

Перед началом зафиксируйте пользователя, copilot version, рабочий каталог и цель изменения. Не добавляйте server «на будущее»: перечислите один сценарий, нужные tools и владельца. Сделайте baseline через list/get, чтобы после операции увидеть ровно ожидаемое изменение. Если конфигурация командная, оформляйте её через review, а секреты храните отдельно.

Проверенные факты и первоисточники

Проверено 13 сентября 2026 года. copilot mcp remove <name> удаляет user-level server. Workspace servers нужно менять непосредственно в их configuration files. В интерактивной форме /mcp delete <name> для workspace server сообщает файл, который следует редактировать.

Точные команды сверены с официальной Copilot CLI command reference и инструкцией GitHub по добавлению MCP servers. Изменяемые цены, тарифы и модели не используются. Указанные default или availability относятся к дате проверки; перед будущим изменением откройте источники заново.

Важно различать user, workspace, plugin и session configuration. Одинаковое имя может разрешаться по приоритету источников, а команда удаления может работать только для одного уровня. Поэтому в журнале изменения храните не только server name, но и source, transport, enabled status и список tools.

До изменения нарисуйте короткую цепочку данных: кто инициирует запрос, какой tool вызывается, куда уходит input и где сохраняется output. Отдельно отметьте, может ли server выполнять запись. Эта схема нужна не для формальности: по ней легко увидеть, что «чтение документации» на деле включает отправку фрагмента закрытого репозитория внешнему endpoint. Если маршрут данных неясен, не подключайте интеграцию до ответа владельца сервиса.

Также определите критерий остановки. При неожиданном tool, неизвестном source, ошибке TLS, запросе лишнего scope или появлении секрета в логе завершите session, отключите server и отзовите test credential. Не продолжайте эксперимент расширением прав: сначала устраните конкретную причину и снова начните с read-only проверки.

Модель угроз перед подключением

Проверьте четыре направления. Первое — происхождение executable или remote endpoint. Второе — данные, которые tools читают и меняют. Третье — credentials и место их появления в history/logs. Четвёртое — инструкции самого MCP server, способные влиять на поведение агента.

Для первой проверки используйте отдельный test credential с минимальным scope, безопасный read-only tool и объект без персональных данных. Не используйте production delete/update/create как негативный тест. Если нужен отказ, применяйте несуществующий тестовый ID, disabled state, исключённый tool либо недействительный временный credential.

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

Выполните list/get и определите источник server.
Если источник user-level, сохраните безопасную копию без credential values.
Проверьте зависимости: scripts и инструкции не должны ожидать этот tool.
Выполните copilot mcp remove NAME.
Повторите copilot mcp list --json и убедитесь, что user-level запись исчезла.
Откройте новую сессию и проверьте отсутствие tools.
Если server пришёл из workspace .mcp.json, не создавайте shadow user entry: откройте указанный файл в PR.
Отзовите отдельные credentials, которые больше нигде не используются.

После каждого изменения снова запускайте list/get и открывайте новую CLI session, если проверяется persistence. Старый процесс мог загрузить конфигурацию до изменения. Для remote server сопоставляйте client result с server-side audit log; для local process дополнительно проверяйте command path и отсутствие секретов в stdout/stderr.

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

Заполните карточку в change request:

Server: <name>
Source: user/workspace/plugin
Зависимости проверены: <список>
User removal: copilot mcp remove <name>
Workspace change: PR к <path>
List после изменения: <результат>
Credential revoked: да/не применимо
Дата проверки официальной документации: 13.09.2026
Источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

Готовый prompt для внутреннего помощника:

Подготовь безопасный план изменения MCP в GitHub Copilot CLI.
Используй только факты из заполненной карточки. Не придумывай status,
tools, transport, token, exit code или успешный результат.
Раздели ответ на: baseline, точную команду, позитивный read-only тест,
негативный тест без изменения данных, критерии успеха, очистку и откат.
Любой отсутствующий факт пометь «нужно проверить вручную».

<вставьте карточку>

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

Вход. Старый user-level server legacy-docs больше не используется; одноимённой workspace записи нет.

Ожидаемый результат. Remove убирает запись, list её не показывает, новая session не видит tools. Credential отзывается отдельно, потому что удаление config не гарантирует отзыв на server side.

Как удалить MCP-сервер из Copilot CLI

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

Проверенные факты и первоисточники

Модель угроз перед подключением

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

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

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

Позитивный и негативный тест

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

Чек-лист финальной проверки

FAQ

Что можно удалить командой remove?

Что делать с workspace server?

Отзывается ли token автоматически?

Зачем новая сессия?

Итог

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

Как добавить HTTP MCP-сервер в Copilot CLI

Как добавить локальный MCP-сервер в Copilot CLI

Как посмотреть MCP-серверы через copilot mcp list --json

Комментарии