Как запретить git push в Copilot CLI через --deny-tool

Проверено 13 сентября 2026 года. Официальный пример использует copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'. Суффикс :* совпадает со stem и пробелом: охватывает git push и git pull, но не gitea. Deny всегда имеет приоритет над allow, даже при --allow-all.

Первоисточник — 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. Создайте тестовый локальный репозиторий без production remote либо используйте безопасную ветку.
2. Запустите CLI с точным allow для shell(git:*) и deny для shell(git push).
3. Попросите выполнить git status; команда должна соответствовать разрешённому git stem.
4. Попросите подготовить локальный commit только если это безопасно и ожидаемо.
5. Попросите выполнить git push как негативный тест: CLI не должен получить разрешение на эту команду.
6. Проверьте, что запрет не заменён общим --allow-all: deny всё равно должен выигрывать.
7. Не используйте более широкое shell без аргумента, если нужны только Git-команды.
8. Зафиксируйте строку запуска в wrapper script без токенов и проверяйте её при обновлении CLI.

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

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

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

Политика Git для Copilot CLI
Allow: shell(git:*)
Deny: shell(git push)
Позитивный тест: git status
Негативный тест: git push
Remote тестового repo: <none/test>
Ожидание: status выполняется, push запрещён
Ответственный за ручной push: <роль>
Дата проверки документации: 13.09.2026
Официальный источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

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

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

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

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

Входные условия. Агент должен читать status и создавать локальный commit в тестовом repo, но публикация ветки требует человека.

Ожидаемый результат. git status попадает под allow pattern. git push попадает и под общий allow, и под точный deny, но запрет имеет приоритет, поэтому автоматическое выполнение блокируется.

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