Как проверить, что policy VS Code для agent permissions не только видна в диагностике, но и фактически блокирует deny, используя только одноразовые маркерные файлы.
Сначала проверьте, какую policy видит VS Code
Запустите штатную команду Developer: Policy Diagnostics и сверьте, что нужная политика помечена как применённая. Официальная справка указывает, что policy переопределяет пользовательскую setting. Однако этот экран показывает конфигурацию, а не итог операции. Перед передачей отчёта просмотрите его вручную: VS Code предупреждает, что диагностика может содержать чувствительные данны.
Создайте одноразовую песочницу
Вне рабочих репозиториев создайте новый пустой каталог. Положите в него три текстовых файла с безвредными маркерами allow, ask и deny. Не копируйте туда .env, ключи, конфиги, реальный код или историю Git. Откройте в VS Code только этот каталог. Так даже неожиданно разрешённая операция затронет только расходный маркер, а не проект, приватные данны или учётную запись.
Сверьте три ожидаемых исхода с фактами
Для allow запишите, прошла ли безопасная операция без диалога. Для ask — появился ли запрос и выполнено ли действие только после осознанного разрешения. Для deny — не смогло ли действие изменить маркер даже после любого предложения UI. Отделяйте три колонки: «показана policy», «появился диалог» и «изменился файл». Именно третья колонка проверяет enforcement.
При нарушении deny перейдите в fail-closed
Если маркер deny был прочитан или изменён вопреки ожиданию, не продолжайте тест на других путях. Закройте agent session и не открывайте ему реальные репозитории, домашние каталоги, секреты и ключи. Это и есть fail-closed: отсутствие доказанного enforcement считается недоверенным состоянием. Не пытайтесь компенсировать его ручными исключениями в policy, пока не понятна первая граница.
Обезличьте Policy Diagnostics и таблицу
Для эскалации сохраните версии VS Code и Windows, канал сборки, применённое имя policy и таблицу трёх исходов. Удалите из диагностики имена учётных записей, домены, пути, идентификаторы организации и серверов. Не прикладывайте содержимое маркеров: достаточно их хэшей до и после. Так отчёт покажет факт записи и не раскроет даже тестовый текст.
Что не следует считать доказательством
Надпись deny в UI не доказывает блокировку, а появление диалога не доказывает, что система правильно отличает ask от deny. Даже успешная блокировка одной операции не доказывает все пути и инструменты. Матрица отвечает на узкий вопрос: совпали ли три ожидаемых исхода в этой версии и среде. Любое расширение вывода требует отдельных доказательств.
Материал подготовлен редакцией VOne с применением ИИ для fail-closed матрицы; permissions и policy diagnostics проверены по официальной документации VS Code, issue использован только как обезличенный сигнал.
Источники и проверка
- Visual Studio Code — Manage approvals and permissions проверено 2026-08-11
- Visual Studio Code — Centrally manage settings проверено 2026-08-11
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.