В этом материале
OpenCode V2 использует упорядоченные action/resource/effect: выигрывает последнее совпадение, а правила агента следуют за общими.
Если OpenCode V2 отвечает, но запрещает инструмент, проверяйте эффективные правила вместо замены локального провайдера. V2 использует упорядоченный массив permissions: выигрывает последнее совпадение, а правила агента применяются после общих.
Конкретная граница приложения
Правило V2 содержит action, resource и effect. Значения эффекта — allow, deny или ask. Шаблон сопоставляется со всем значением ресурса, поэтому путь или команда должны соответствовать фактической проверке. Документация сначала загружает конфигурацию меньшего приоритета, затем общие правила и правила агента. Позднее широкое правило способно перекрыть раннее исключение. Некоторые операции проверяют несколько ресурсов: любой deny запрещает действие, иначе любой ask вызывает подтверждение. Базовая политика также участвует, поэтому отдельная строка не описывает весь результат. Названия V1 permission, bash и task отличаются от V2 permissions, shell и subagent. Сначала установите поколение приложения и реальный формат, чтобы правка вообще относилась к действующей системе разрешений (OpenCode V2 Permissions).
Практический маршрут
Определите точное запрещённое действие и ресурс задачи. Откройте активный opencode.jsonc и изучите permissions по порядку, включая правила выбранного агента. Для просмотра Git широкое правило shell с ask может предшествовать узкому allow для git status *. Запрет нужной запрещённой операции размещайте после широких разрешений. Не заменяйте всю политику на allow ради одной команды. Для изменения нескольких файлов изучите каждую цель и границу external_directory отдельно (OpenCode V2 Config).
Разобранный пример
Пользователь ожидает свободный git status, но поставил широкое shell ask после специального разрешения status. Последнее совпадение выигрывает, поэтому действует широкая строка. Разместите нужное исключение после общего правила и повторите действие только для чтения. В отдельной правке нескольких файлов один запрещённый путь всё равно способен остановить всю операцию, даже если первый путь разрешён. Эти случаи объясняются разными частями документированного решения.
| Проверка | Запись |
|---|---|
| Действие | Фактически проверяемое разрешение V2, например shell либо edit. |
| Ресурс | Нормализованный путь или строка команды, полученная анализатором приложения. |
| Порядок | Последнее совпадающее эффективное правило с учётом дополнений выбранного агента. |
Как правильно прочитать сбой
doom_loop и lsp не являются текущими действиями разрешений V2 Core: старые примеры не объясняют нынешний запрет shell. Разрешение приложения также не расширяет права операционной системы. Команды сохраняют доступ учётной записи компьютера; сопоставление правил не является системной песочницей и не меняет владельца запущенного процесса или доступных ему ресурсов (OpenCode V2 introduction).
Что завершает проверку
Исправление должно объяснять конкретное действие в эффективной упорядоченной политике. Рабочий провайдер и разрешённый инструмент являются отдельными условиями; общее разрешение всего скрывает различие и убирает полезные границы исходной задачи.
Связанные материалы: Воспроизводимый стек инференса: как сохранить результат GPU-пилота, LLM для кода на 12 ГБ VRAM: модель, контекст и запас.