Гайд · TNWS AI

Как разрешить npm test в Copilot CLI, не открывая все shell-команды

Copilot

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

Пошаговая настройка --allow-tool для запуска npm test в GitHub Copilot CLI: точный шаблон shell, тестовый репозиторий и проверка границ разрешения.

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

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

Сценарий применим к установленному и авторизованному GitHub Copilot CLI в доверенном тестовом репозитории. Основная команда: copilot -p 'Запусти npm test и объясни только реальные ошибки; не исправляй файлы' -s --allow-tool='shell(npm test)' --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 и сетевые обращения могут требовать согласия. Параметры запуска относятся к текущей сессии, тогда как часть разрешений, выданных через интерактивное подтверждение, может сохраняться в конфигурации. Если тест даёт неожиданный результат, сначала проверьте эти сохранённые настройки и конкретный рабочий каталог.

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

Откройте package.json и прочитайте scripts.test. Скрипт npm может выполнять произвольные дочерние команды с правами пользователя; разрешать его автоматически следует только в доверенном репозитории. Сначала локально выполните npm test в тестовой копии и зафиксируйте исходный exit code. Убедитесь, что скрипт не делает публикацию, установку с postinstall, очистку важных каталогов или сетевое обращение. Для внешних pull request скопируйте проект в изолированную среду, а не запускайте непроверенный package.json на рабочей машине.

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

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

В корне репозитория проверьте точную строку scripts.test через npm pkg get scripts.test. Если запись отсутствует, создайте тестовый сценарий обычным pull request, а не просите агента угадывать команду.
Запустите приведённый шаблон с --allow-tool, в котором Kind(argument) равен shell(npm test). Кавычки вокруг всего шаблона обязательны: скобки имеют смысл для командной оболочки.
В prompt прямо запретите изменение файлов и попросите привести имя упавшего теста и сообщение ошибки. Разрешение на npm test не равно разрешению на запись файлов.
Проверьте git status --short после завершения. Если тестовый скрипт создаёт snapshot или временные файлы, отличите его штатные артефакты от изменений агента.

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

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

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

copilot -p 'Запусти npm test и объясни только реальные ошибки; не исправляй файлы' -s --allow-tool='shell(npm test)' --no-ask-user

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

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

Вход: В package.json указано scripts.test: "node --test tests/*.test.js". Тест tests/price.test.js ожидает сумму 120, но функция возвращает 119.

Ожидаемый результат: Copilot запускает npm test без запроса разрешения для этого совпадающего shell-шаблона и сообщает о конкретном расхождении 120 против 119. Он не получает автоматически разрешение на npm publish или npm install. Сам запуск не гарантирует успешное прохождение тестов; это диагностическая операция.

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

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

Позитивная проверка: в журнале сессии есть фактический вывод npm test, а не выдуманная сводка. Негативная проверка: попросите отдельно npm publish в тестовой среде и убедитесь, что это действие не получает автоматическое разрешение от shell(npm test). Не выполняйте публикацию по-настоящему: остановитесь на экране разрешений или используйте изолированный mock. Если ваш scripts.test вызывает запись на диск, ограничение флага не предотвращает побочные эффекты самого скрипта.

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

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

Шаблон shell(npm:*) разрешает все команды со stem npm, включая install и publish; для узкой задачи он чрезмерен. --allow-all или --allow-all-tools тем более расширяют поверхность. Ещё одна ошибка — считать, что --no-ask-user запрещает запросы разрешений: он отключает инструмент ask_user, а не превращает непривилегированные действия в разрешённые. Если задача требует других tools, сделайте выбор явно и раздельно.

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

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

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

FAQ

Почему нельзя просто разрешить shell?

Такой шаблон допускает любые команды терминала. Узкий shell(npm test) соответствует одной планируемой операции и упрощает аудит.

Будет ли флаг сохранён навсегда?

Документация относит параметры командной строки к текущей сессии; они не записываются как постоянное разрешение в permissions-config.json.

Что делать, если test выполняет опасный скрипт?

Не разрешайте запуск. Сначала проверьте package.json и зависимости, затем примените изоляцию или используйте доверенную команду тестирования.

Можно ли ожидать одинаковый текст ответа?

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

Итог

Для задачи «дать агенту возможность запускать тесты JavaScript-проекта в одноразовой сессии, не выдавая безусловное разрешение на любые команды терминала» важна не только команда copilot -p 'Запусти npm test и объясни только реальные ошибки; не исправляй файлы' -s --allow-tool='shell(npm test)' --no-ask-user, но и доказательство её действия на маленьком тестовом случае. Сохраните исходное состояние, выполните разрешённый и запрещённый сценарии, затем перенесите только подтверждённый вариант в рабочий проект. При смене версии CLI перепроверьте первоисточник и повторите оба теста.