Гайд · TNWS AI

Как запускать Copilot CLI в CI без уточняющих вопросов

Copilot

19 сентября 2026 7 мин—

Проверяемый сценарий --no-ask-user для Copilot CLI: однозначный prompt, ограниченные права, обработка невозможного задания и чистый вывод.

Этот гайд решает конкретную задачу: получить отчёт в неинтерактивном job, где агент не может задавать уточняющие вопросы и должен честно остановиться при недостатке данных. Ниже — воспроизводимый сценарий, а не обещание, что любой текстовый запрос сам по себе создаёт техническое ограничение. Факты о флагах и доступности проверены 19 сентября 2026 года по официальной документации GitHub; динамические тарифы и неподтверждённые лимиты здесь не приводятся.

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

Сценарий применим к установленному и авторизованному GitHub Copilot CLI в доверенном тестовом репозитории. Основная команда: copilot -p 'Прочитай README.md и выведи три подтверждённых факта; если файла нет, напиши ERROR: README_NOT_FOUND' -s --no-ask-user. Сначала выберите маленький тестовый проект, на котором можно проверить и успешный путь, и отказ. Если полномочий агента недостаточно, это безопасный сигнал уточнить конфигурацию, а не причина сразу включить все разрешения.

Важно различать четыре уровня: выбор доступных модели tools, разрешение tool на действие, доступ к файлам и сетевую политику ОС. Один флаг управляет лишь тем уровнем, который ему назначен в документации. Инструкция на естественном языке направляет поведение, но не заменяет реальное правило доступа. Поэтому результат оценивают по фактическим вызовам и артефактам, а не по фразе агента «я не буду».

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

В справочнике команд GitHub Copilot CLI указаны синтаксис основных параметров, список имён tools и правила шаблонов разрешений. Руководство по разрешениям различает --available-tools/--excluded-tools и --allow-tool/--deny-tool, объясняет сохранённые разрешения и приоритет deny. Для запуска с -p, -s и --no-ask-user используется официальное руководство по программному запуску. Эти первоисточники просмотрены 19 сентября 2026 года. Не переносите без проверки параметры между разными CLI: одинаковое слово «agent» не означает одинаковую модель прав.

Документация отдельно предупреждает, что изменение или чтение файлов, shell и сетевые обращения могут требовать согласия. Параметры запуска относятся к текущей сессии, тогда как часть разрешений, выданных через интерактивное подтверждение, может сохраняться в конфигурации. Если тест даёт неожиданный результат, сначала проверьте эти сохранённые настройки и конкретный рабочий каталог.

Подготовка тестового стенда

В официальной документации -p исполняет запрос программно, -s подавляет служебные сведения, --no-ask-user отключает tool ask_user. Это не автоматическое согласие на потенциально опасные tools. Для CI подготовьте учётные данные через секрет-хранилище системы, не помещайте токен в prompt или лог. Убедитесь, что README.md существует, и определите явный формат ошибки: строка ERROR: README_NOT_FOUND при отсутствии входа. Так job сможет отличить отсутствие файла от свободного ответа модели.

Запишите исходное состояние проекта: текущий каталог через pwd, версию CLI через copilot version, git status --short и наличие нужных входных файлов. Не вставляйте реальный секрет в тестовый prompt, публикацию или screenshot. Разделяйте код процесса, код завершения Copilot и утверждения модели: успешный exit code не доказывает правильность итогового текста, а отказ в разрешении не обязательно означает ошибку конфигурации.

Пошаговое выполнение

Сформулируйте prompt с точным файлом, количеством фактов, запретом домыслов и поведением при отсутствии входа. Не полагайтесь на «сам разберись» в полностью неинтерактивной среде.
Запустите -p, -s и --no-ask-user в тестовом job. Выдайте только минимально необходимые разрешения, если чтение конкретного файла запрашивает одобрение.
Сохраните stdout и код завершения команды отдельно. Проверьте наличие обязательных фактов в README.md; текст модели сам по себе не является доказательством корректности.
Удалите тестовый README в отдельной ветке или запустите на пустом тестовом каталоге и проверьте явный ERROR, не отправляя job в production.

После каждого прогона сравните git status --short с исходным состоянием. Если передан конкретный путь или имя инструмента, проверьте его посимвольно; похожее имя способно расширить либо сузить правило. Для команд с shell-скобками заключайте всё значение опции в одинарные кавычки. На Windows используйте правила кавычек своей оболочки и проверяйте, что CLI получает значение целиком.

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

Команда для контролируемой проверки; замените указанные тестовые пути, если пример использует файлы, и сначала прочитайте смысл каждого аргумента:

copilot -p 'Прочитай README.md и выведи три подтверждённых факта; если файла нет, напиши ERROR: README_NOT_FOUND' -s --no-ask-user

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

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

Вход: README.md содержит инструкции npm ci, npm test и запуск приложения npm start. CI должен вывести краткую справку для ревьюера.

Ожидаемый результат: На валидном входе ответ содержит только сведения, подтверждённые README.md. В тесте с отсутствующим файлом ответ должен содержать ERROR: README_NOT_FOUND либо job должен завершиться как неуспешный по вашей внешней проверке. Агент не зависает в ожидании ask_user.

Это критерий приемки, а не выдуманный лог запуска. В вашей среде модель может сформулировать ответ иначе, а организационная политика — отклонить действие. Считайте тест успешным только при совпадении наблюдаемого поведения с указанной границей и при наличии проверяемых исходных данных. Если нет доступа к выбранной модели, не подменяйте её незаметно: отметьте условие и повторите на совместимой конфигурации.

Положительный и отрицательный тест

Позитивная проверка использует настоящий README и сравнивает факты. Негативная — пустой каталог с тем же prompt. Добавьте после запуска скриптовую проверку файла и результата, потому что LLM может не соблюсти строковый контракт. Например, в shell сначала test -f README.md, затем запускайте Copilot; это надёжнее, чем доверять одному естественноязыковому условию.

При спорном результате сохраните только обезличенный журнал разрешений и минимальные воспроизводимые входные данные. Если задачу выполнял другой tool, явно укажите это в отчёте: правило для одного инструмента не обязательно распространяется на альтернативный. Такой негативный тест особенно полезен перед тем, как переносить пример в CI или командную практику.

Ошибки, отладка и ограничения

Нельзя делать вывод, что --no-ask-user автоматически разрешает shell, запись и URL: он отключает один инструмент вопросов. Не используйте --allow-all лишь для устранения зависания без песочницы. Не считайте exit code модели полноценной валидацией фактов: проверяйте исходные файлы и ожидаемый формат независимо. Учтите, что модель может вернуть отказ при нехватке разрешений, и job должен это обработать.

Чтобы локализовать причину, сделайте второй прогон на пустом тестовом репозитории с одним изменяемым параметром. Не меняйте одновременно prompt, модель, каталог и разрешения: тогда нельзя понять, почему исчезла ошибка. Если модель сообщает об отсутствии ресурса, сначала проверьте путь и доступ на уровне процесса, затем разрешения CLI, и лишь после этого формулировку задачи.

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

Точный синтаксис параметров сверен со справочником GitHub на 19 сентября 2026 года.
Входной файл, путь или домен соответствует тестовой задаче.
Исходное состояние репозитория записано до запуска.
Положительный тест показал ожидаемую разрешённую операцию.
Отрицательный тест не вызвал запрещённого действия.
Итоговый ответ сверён с фактическими файлами или журналом tools.
Секреты, реальные токены и частные пути не попали в отчёт.
Изменения в git просмотрены и объяснены.

FAQ

Что именно отключает флаг?

Согласно справке, инструмент ask_user; агент работает без уточняющих вопросов. Остальные разрешения настраиваются отдельно.

Можно ли направить ответ в файл?

Да, стандартное перенаправление stdout с -s даёт чистый текст, но сначала отделите ошибки и проверьте содержимое.

Что если данных недостаточно?

Задайте явный отказ или код ошибки и проверьте его внешним скриптом. Не заставляйте модель придумывать отсутствующий факт.

Подходит ли для автономных правок?

Только после отдельного анализа прав tools, изоляции и review diff. Для отчёта достаточно чтения.

Итог

Для задачи «получить отчёт в неинтерактивном job, где агент не может задавать уточняющие вопросы и должен честно остановиться при недостатке данных» важна не только команда copilot -p 'Прочитай README.md и выведи три подтверждённых факта; если файла нет, напиши ERROR: README_NOT_FOUND' -s --no-ask-user, но и доказательство её действия на маленьком тестовом случае. Сохраните исходное состояние, выполните разрешённый и запрещённый сценарии, затем перенесите только подтверждённый вариант в рабочий проект. При смене версии CLI перепроверьте первоисточник и повторите оба теста.