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

Самое важное и самое пропускаемое - платформенные различия. На macOS изоляция строится одними средствами операционной системы, на Linux другими, и уровень поддержки зависит от ядра и настроек. При недостаточной поддержке часть действий может потребовать подтверждения или дополнительной настройки на уровне системы. Отсюда правило: политику проверяют на каждой операционной системе фактическим поведением, а не переносят по названию режима.

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

У песочницы есть граница применимости, и её лучше проговорить прямо. Она защищает машину от процесса, а не проект от агента. Внутри рабочей области с правом записи агент может переписать почти что угодно: удалить нужный файл, испортить миграцию, закоммитить полуготовое; неприкосновенным остаётся лишь узкий набор служебных файлов: конфигурация самого инструмента и редактора, файл исключений и служебные файлы репозитория вроде настроек и хуков системы контроля версий. Изоляция при этом отработает безупречно - именно это ей и разрешили. Значит, от неверных правок защищает другой слой: узкая задача, просмотр diff, тесты и система контроля версий, из которой изменение можно откатить. Ждать от песочницы качества кода - та же подмена, что ждать от подтверждений безопасности файловой системы.

Инженерный вывод простой: сначала узкая граница, потом удобство. Расширять доступ дешевле, чем сужать после инцидента, и каждое расширение стоит делать точечным - конкретный путь, конкретный домен. Соблазн выключить изоляцию целиком, чтобы не мешала, понятен, но он превращает управляемую границу в её отсутствие.

Типичные провалы предсказуемы. Спутать песочницу с подтверждениями и ждать от одной того, что даёт другое. Перенести политику с macOS на Linux по названию и не проверить фактическое поведение. Оставить открытую запись во временный каталог как обходной путь. Принять отказ политики за поломку проекта и чинить не то. И не выполнить негативный тест, приняв текст конфигурации за доказательство.