Как проверить language servers через copilot lsp list

Проверено 13 сентября 2026 года. copilot lsp list — неинтерактивная inspect-only команда. Вариант --json выдаёт элементы формы { id, fileExtensions?, sourcePlugin? }. Для запуска, остановки или перезагрузки language server официальная справка направляет в интерактивную команду /lsp.

Первоисточник — GitHub Copilot CLI command reference. Для MCP-сценария дополнительно используйте официальную настройку MCP servers. Цены, квоты и список доступных моделей здесь не приводятся: они не нужны для процедуры и могут меняться. Названия команд и параметров взяты из текущей официальной справки.

У CLI есть три разных уровня результата: команда может быть синтаксически принята, фактически выполнена и дать ожидаемый эффект. Проверяйте все три. Нулевой exit code без проверки файла или интерфейса недостаточен; красивый текст ответа при ненулевом exit code тоже нельзя считать успехом.

Перед тестом запишите точную гипотезу в одном предложении: «после команды появится такой-то файл, источник, запрет или набор подсказок». Затем определите независимый способ проверки, который не опирается на объяснение самого ассистента. Для файла это просмотр содержимого и diff, для разрешения — намеренно безопасная попытка запрещённого действия, для списка — сравнение структурированного вывода. Такой подход помогает обнаружить ситуацию, когда команда отработала, но не в том каталоге, не для того пользователя или не в той конфигурации.

Подготовка безопасной среды

Для первого запуска используйте тестовый репозиторий, временный каталог или read-only задачу. Сохраните baseline: существующие файлы конфигурации, список источников, текущий completion или разрешения. Если команда пишет файл, заранее определите точный путь и сделайте резервную копию только этого файла. Если команда предоставляет доступ, перечислите разрешённые и контрольные запрещённые объекты.

Не используйте глобальные разрешения ради удобства, когда задачу решает точный флаг. В CI разделяйте stdout, stderr и exit code. В интерактивной сессии читайте запросы разрешений и не подтверждайте действие только потому, что его предложил Copilot. Любой сгенерированный код или конфигурацию просматривайте как обычный внешний patch.

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

1. Перейдите в каталог проекта, где наблюдается проблема с языковым контекстом.
2. Выполните copilot lsp list и проверьте идентификаторы серверов.
3. Сохраните структурированный снимок: copilot lsp list --json > lsp-before.json.
4. Сопоставьте fileExtensions с файлами задачи: например, .ts или .cs должны относиться к ожидаемому серверу.
5. Проверьте sourcePlugin, чтобы отличить встроенную конфигурацию от plugin-provided.
6. Не пытайтесь управлять сервером через list: откройте интерактивную сессию и используйте /lsp для start, stop или reload.
7. После изменения конфигурации снова выполните copilot lsp list --json > lsp-after.json и сравните файлы.
8. Удалите временные снимки либо приложите безопасный diff к диагностическому issue.

После выполнения повторите диагностическую команду или откройте новую shell/CLI-сессию, если эффект должен пережить перезапуск. Сравните результат с baseline. Если изменилось больше файлов или источников, чем ожидалось, остановитесь, сохраните diff и выполните откат до продолжения.

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

Заполните эту карточку перед изменением. Её можно вставить в issue или change request:

Диагностика LSP
Проект: <путь>
Проблемный файл: <имя и расширение>
Команда: copilot lsp list --json
Ожидаемый id: <server>
fileExtensions: <список>
sourcePlugin: <plugin или отсутствует>
Действие в live session: /lsp <start|stop|reload>
Результат после повторного list: <описание>
Дата проверки документации: 13.09.2026
Официальный источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

Для подготовки проверки можно скопировать prompt ниже. Он не разрешает ассистенту придумывать состояние окружения:

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

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

Реалистичный пример

Входные условия. Copilot плохо понимает навигацию в TypeScript. Инженер запускает JSON-список и ищет сервер с .ts/.tsx и его sourcePlugin.

Ожидаемый результат. Получен inspect-only отчёт. Если нужного расширения нет, проблема зафиксирована без ложного утверждения, что команда list что-то перезапустила; управление выполняется отдельно через /lsp.

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