У проверяющего отключили Edit и Write, но оставили Bash. Это не делает рабочую копию недоступной для изменения: оболочка может запустить скрипт, перенаправить вывод в файл или вызвать программу, которая сама пишет данные. Название инструмента не определяет все его последствия.
Для ревью нужно отдельно решить три вопроса: что помощник читает, какие команды выполняет и к каким внешним системам обращается. Ниже — схема ограничений для проверки изменения формы публикации. Она описывает желаемое устройство среды, а не универсальный конфигурационный файл для любого агента.
Начните с минимального результата
Проверяющий должен найти дефекты в согласованном diff и вернуть их с доказательствами. Ему нужны требования, изменённые файлы и достаточно окружающего кода, чтобы проследить поведение. Право исправлять найденное для такого результата не требуется.
Отделите чтение кода от запуска приложения. Статический просмотр способен найти пропущенную проверку доступа, но не подтверждает, что тест проходит. Если нужны оба вида проверки, можно использовать одного исполнителя с тщательно настроенной средой либо два отдельных поручения: анализ исходников и запуск согласованных тестов.
Разделите три технические границы
Файловая система. Исходники можно предоставить через доступ только для чтения, а временные файлы разрешить в отдельном каталоге. Тогда программа, которой нужны логи или кеш, не должна писать в репозиторий. Конкретная настройка зависит от песочницы, контейнера и инструмента запуска.
Команды. Разрешённый терминал способен менять файлы, базу и процессы. Даже тестовая команда может выполнять подготовительные скрипты. Изучите её реальное назначение и окружение, а не только имя. Доступ к Docker тоже нельзя считать обычным чтением: через него доступны операции внутри контейнеров и подключённых томов.
Сеть и внешние сервисы. Запрет записи в папку не запрещает отправить HTTP-запрос, письмо или команду в подключённый сервис. Проверка формы не должна отправлять настоящие сообщения или менять рабочую запись. Для неё нужны подставные получатели, тестовая БД и ограниченные учётные данные.
В документации песочницы Claude Code файловая и сетевая изоляция рассматриваются отдельно. Настройки конкретного продукта нужно проверять в его документации. Наличие слова sandbox в интерфейсе не доказывает, что все доступные коннекторы и команды ограничены одинаково.
Когда достаточно чтения без оболочки
Для первого прохода по небольшому diff можно оставить только инструменты чтения и поиска. В официальном примере субагента Claude Code используется список Read, Grep, Glob. Этот пример не включает Bash; переносить к нему вывод «может запускать любые команды, но не писать» нельзя.
Попросите проверяющего связать замечание с конкретным сценарием. «Возможно, здесь проблема с правами» слабее, чем «запрос обычного пользователя достигает сохранения, потому что на этой ветке отсутствует проверка разрешения; вот вызывающий маршрут». Необходимость доказательств относится к качеству работы, а технические права — к доступным действиям. Одно не заменяет другое.
Как организовать запуск тестов
Создайте отдельную копию для проверки, укажите тестовое подключение и убедитесь, что оно не совпадает с рабочей БД. Уберите ненужные секреты и доступы. Нужные зависимости лучше подготовить до запуска агента: установка пакетов может выполнять дополнительные скрипты и обращаться в сеть.
Поручение проверяющему:
Прочитай требования и diff формы публикации.
Исходники доступны только для чтения.
Тесты запускает отдельный согласованный процесс в тестовой среде.
Верни дефекты: действие, ожидаемое поведение, причина в коде.
Не исправляй исходники и не обновляй ожидаемые результаты тестов.
Если доказательств недостаточно, перечисли недостающие данные.Для исполнителя тестов задайте точную команду, каталог и допустимые побочные эффекты. Отчёт должен содержать фактический код завершения и существенную часть вывода. Если команда не смогла подключиться к тестовой базе, это блокировка проверки, а не отрицательный результат тестирования приложения.
Красный тест не даёт разрешения менять его ожидание. Сначала нужно установить, ошибочен код, тест или среда. Исправление выполняется отдельным поручением с понятной причиной, после чего повторяется тот же сценарий.
Проверьте ограничения до важного ревью
В одноразовой среде убедитесь, что попытка создать безвредный файл в защищённой папке действительно запрещена, а запись в разрешённый временный каталог работает. Проверьте сетевые ограничения контролируемым запросом к тестовому адресу. Такая проверка не должна выполняться на рабочих данных или обходить установленные правила.
После сессии сравните состояние репозитория с исходным. Это дополнительное обнаружение изменений, а не замена техническому запрету. Чистый diff ничего не говорит об отправленных письмах, изменениях внешней БД или прочитанных секретах.
Человек определяет допустимый доступ и принимает решение по найденным дефектам. Проверяющий с узкими правами всё ещё способен ошибиться в выводах. Правильная граница нужна, чтобы ошибка анализа не превратилась одновременно в незаметное изменение системы.
