# OpenCode V2 отвечает, но инструмент запрещён

Запрет инструмента OpenCode V2: порядок permissions, реальные названия действий, правила агента и решение для нескольких ресурсов.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/opencode-v2-tool-permission-denied/
Language: ru

Если OpenCode V2 отвечает, но запрещает инструмент, проверяйте эффективные правила вместо замены локального провайдера. V2 использует упорядоченный массив permissions: выигрывает последнее совпадение, а правила агента применяются после общих.

## Конкретная граница приложения

Правило V2 содержит action, resource и effect. Значения эффекта — allow, deny или ask. Шаблон сопоставляется со всем значением ресурса, поэтому путь или команда должны соответствовать фактической проверке. Документация сначала загружает конфигурацию меньшего приоритета, затем общие правила и правила агента. Позднее широкое правило способно перекрыть раннее исключение. Некоторые операции проверяют несколько ресурсов: любой deny запрещает действие, иначе любой ask вызывает подтверждение. Базовая политика также участвует, поэтому отдельная строка не описывает весь результат. Названия V1 permission, bash и task отличаются от V2 permissions, shell и subagent. Сначала установите поколение приложения и реальный формат, чтобы правка вообще относилась к действующей системе разрешений ([OpenCode V2 Permissions](https://opencode.ai/v2/docs/permissions)).

## Практический маршрут

Определите точное запрещённое действие и ресурс задачи. Откройте активный opencode.jsonc и изучите permissions по порядку, включая правила выбранного агента. Для просмотра Git широкое правило shell с ask может предшествовать узкому allow для git status *. Запрет нужной запрещённой операции размещайте после широких разрешений. Не заменяйте всю политику на allow ради одной команды. Для изменения нескольких файлов изучите каждую цель и границу external_directory отдельно ([OpenCode V2 Config](https://opencode.ai/v2/docs/config)).

## Разобранный пример

Пользователь ожидает свободный git status, но поставил широкое shell ask после специального разрешения status. Последнее совпадение выигрывает, поэтому действует широкая строка. Разместите нужное исключение после общего правила и повторите действие только для чтения. В отдельной правке нескольких файлов один запрещённый путь всё равно способен остановить всю операцию, даже если первый путь разрешён. Эти случаи объясняются разными частями документированного решения.

| Проверка | Запись |
| --- | --- |
| Действие | Фактически проверяемое разрешение V2, например shell либо edit. |
| Ресурс | Нормализованный путь или строка команды, полученная анализатором приложения. |
| Порядок | Последнее совпадающее эффективное правило с учётом дополнений выбранного агента. |

## Как правильно прочитать сбой

doom_loop и lsp не являются текущими действиями разрешений V2 Core: старые примеры не объясняют нынешний запрет shell. Разрешение приложения также не расширяет права операционной системы. Команды сохраняют доступ учётной записи компьютера; сопоставление правил не является системной песочницей и не меняет владельца запущенного процесса или доступных ему ресурсов ([OpenCode V2 introduction](https://opencode.ai/v2/docs/)).

## Что завершает проверку

Исправление должно объяснять конкретное действие в эффективной упорядоченной политике. Рабочий провайдер и разрешённый инструмент являются отдельными условиями; общее разрешение всего скрывает различие и убирает полезные границы исходной задачи.

Связанные материалы: [Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/), [LLM для кода на 12 ГБ VRAM: модель, контекст и запас](/ru/journal/coding-llm-12gb-vram/).