GitHub Copilot CLI — это Copilot в терминале: запускается командой copilot в каталоге проекта, ведёт диалог прямо в консоли, читает код, предлагает правки и команды, а всё, что меняет файлы или запускает программы, выполняет после вашего разрешения. От чата в редакторе его отличает рабочая среда: терминал, явные права на команды и привычка к скриптам. Инструмент подходит тем, кто готов читать каждый diff и разрешать действия по одному.
Терминал вместо чата
По документации GitHub, CLI работает в Linux, macOS и Windows (в PowerShell и WSL), запускается командой copilot и просит подтвердить доверие к каталогу. Действия, которые меняют файлы или выполняют программы, требуют разрешения.
Чат внутри редактора живёт рядом с открытым файлом и отвечает на вопросы о коде. Терминальный агент устроен иначе: он видит каталог, из которого вы его запустили, умеет предлагать команды оболочки и вести работу по шагам. Поэтому он хорошо подходит для задач, где нужен запуск тестов, сборка, правка нескольких файлов и работа с репозиторием на GitHub, и всё это внутри консоли.
Вопросы к коду и проверку чужих изменений в чате мы разбирали в статье про GitHub Copilot Chat для команды разработки. Здесь другой слой: консольная работа агента, его разрешения и порядок приёмки результата. Если вы привыкли к ассистенту в редакторе, терминальный вариант потребует новой дисциплины, потому что риск выше: команда оболочки способна изменить больше, чем подсказка в окне.
Состав возможностей, названия флагов и поддерживаемые платформы меняются вместе с продуктом, поэтому перед внедрением откройте справку GitHub о Copilot CLI и сверьтесь с текущей версией. Всё, что описано ниже, опирается на неё и на здравый смысл безопасной работы с агентом.
Режимы работы
Один и тот же инструмент ведёт себя по-разному в зависимости от режима. Полезно знать, какой нужен для задачи, прежде чем запускать сеанс.
- Интерактивный режим: команда copilot открывает диалог, где вы формулируете задачу, уточняете и разрешаете действия по ходу.
- Режим плана: переключается сочетанием Shift+Tab, агент анализирует запрос, задаёт уточняющие вопросы и строит план до того, как напишет код.
- Программный режим: флаг -p или --prompt передаёт один запрос, после ответа программа завершается, и такой вызов удобно встраивать в скрипты.
- Выбор модели: команда /model в сеансе или флаг --model при запуске, плюс настраиваемая глубина рассуждения; список доступных моделей зависит от вашей подписки и политики организации.
- Серверы MCP: к агенту подключают внешние источники данных и инструменты, и каждое такое подключение расширяет его права.
Для первых задач берите режим плана: он заставляет агента показать замысел, пока файлы остаются в прежнем виде. Вы поправите формулировку, уберёте лишнее и только потом разрешите правки. Программный режим оставьте на потом, когда задача отработана вручную и вы знаете, что агент делает с ней предсказуемо.
Подключение внешних серверов MCP заслуживает отдельной осторожности. Каждый сервер даёт агенту новые действия, от чтения задач до записи в репозиторий, и его набор действий нужно изучить заранее. О том, как описывают такие действия и ограничивают их, рассказано в статье про подключение репозитория через MCP.
Права на команды
Главный вопрос терминального агента — что ему разрешено без вас. Документация описывает несколько уровней, и команде полезно выбрать их сознательно, а выбор записать.
| Ситуация | Как ведёт себя CLI | Что решает команда |
|---|---|---|
| Запуск в каталоге | Просит подтвердить, что вы доверяете каталогу | Запускать только там, где лежит проверенный код |
| Инструмент меняет или запускает файлы | Спрашивает: разрешить один раз, разрешить этот инструмент до конца сеанса или отказать с пояснением | Разрешать разово, пока поведение агента неизвестно |
| Флаг --allow-tool | Заранее разрешает названный инструмент, например команду shell | Короткий список безопасных действий, например тесты |
| Флаг --deny-tool | Блокирует названный инструмент и перекрывает разрешающие флаги | Закрыть удаление, отправку и обращения к сети |
| Флаг --allow-all-tools | Разрешает любые инструменты без вопросов; тот же смысл у --allow-all и --yolo | Только в изолированной среде без секретов |
Документация предупреждает: запускать CLI стоит только из каталогов, которым вы доверяете, и лучше обходить домашнюю папку и места с чувствительными данными. Для автоматического разрешения действий GitHub предлагает ограничивать риск песочницами, локальной или облачной; на момент проверки они описаны как публичная предварительная версия. Политики исключения содержимого, настроенные на уровне предприятия, организации или репозитория, CLI учитывает.
Практичный минимум для команды: отдельный каталог или контейнер для агента, никаких боевых секретов рядом, разрешения по одному на первых неделях и письменный список разрешённых инструментов. Тогда худший исход ограничен тестовой средой, а рабочий сервер остаётся вне зоны риска.
Постановка задачи
Хорошая терминальная задача читается как короткое техническое задание: что изменить, где, по какому признаку считать работу законченной. Расплывчатое «наведи порядок» приводит к правкам в файлах, о существовании которых вы забыли.
- Начните с чистой ветки и запустите тесты вручную, чтобы знать исходное состояние проекта.
- Включите режим плана и опишите цель одним абзацем: что должно измениться и какой тест должен пройти.
- Назовите каталоги, в которых агент вправе работать, и те, которые закрыты.
- Прочитайте предложенный план, поправьте формулировку и только затем разрешайте правки.
- Разрешайте команды по одной и следите, что именно агент запускает в оболочке.
Размер задачи подбирайте так, чтобы итоговый diff читался за один присест. Если агент предлагает правку на десятки файлов, остановитесь и разделите задачу: большой diff проверять труднее, а ошибка в нём теряется среди шума. Небольшие итерации с коммитом после каждой дают возможность откатиться на понятную точку.
Хорошо работают задачи с готовой проверкой: исправить падающий тест, добавить валидацию, обновить документацию, подготовить описание изменений. Плохо работают задачи без критерия готовности, потому что агент вправе остановиться, когда ему кажется, что хватит, а вам кажется иначе.
Что бы вы поручили терминальному агенту в первую очередь?
Проверка итога
Закончив работу, агент оставляет изменения в рабочем каталоге, и ответственность за них лежит на вас. Проверка нужна независимо от того, насколько уверенно звучал отчёт.
- Посмотрите список изменённых файлов и сравните его с замыслом из плана.
- Прочитайте весь diff, включая переименования, форматирование и обновления зависимостей.
- Запустите тесты и линтер самостоятельно: сообщение агента об успехе остаётся лишь предположением.
- Отдельно изучите изменения в тестах и конфигурациях: ослабленные условия выдают подгонку.
- Просмотрите журнал выполненных команд и убедитесь, что обращений в сеть и удалений нет.
Если вызовы агента встроены в скрипты через программный режим, проверка становится ещё важнее: рядом нет человека, который заметит странную команду. Для таких запусков держите узкий список разрешённых инструментов, пишите журнал и назначьте того, кто просматривает результаты по расписанию.
Агент предлагает, человек принимает. Правку, которую вы затрудняетесь объяснить коллеге своими словами, в репозиторий отправлять рано.
Через пару недель пилотной работы подведите итог: какие задачи агент закрыл без доработки, какие потребовали вмешательства, сколько времени ушло на проверку. По этим наблюдениям составляют регламент: типы задач, уровни разрешений, обязательное ревью. Подготовить такой регламент и встроить его в процесс разработки поможет внедрение ИИ в компанию, а как соотносятся терминальные агенты между собой, видно в обзоре Claude Code для команды.