OpenCode V2 responds but a tool is denied

When OpenCode V2 answers but denies a tool, inspect the effective permission rules rather than changing the local model provider. V2 uses an ordered permissions array; the last matching rule wins, and agent rules are applied after global rules.

The concrete application boundary

Each V2 rule has action, resource, and effect fields. Effects are allow, deny, or ask. Matching uses whole-value wildcards, so a path or command pattern must match the resource actually being checked. The documentation loads lower-priority configuration first, then global rules, then agent rules. A later broad rule can therefore override an earlier specific exception. Some operations check several resources: any deny blocks the operation, otherwise any ask requests a decision. Default policies also participate, so do not infer the effective result from one isolated rule. V1 names such as permission, bash, and task differ from V2 permissions, shell, and subagent (OpenCode V2 Permissions).

A practical route

Identify the exact denied action and resource shown for the task. Open the active opencode.jsonc and inspect permissions in order, including the selected agent’s rules. For a routine Git inspection, a broad shell ask rule can precede a narrower allow for git status *. Keep a deny for a prohibited operation after broader allowances. Do not replace the whole policy with allow merely to make one command work. If an edit touches multiple files, inspect each target and any external_directory boundary separately (OpenCode V2 Config).

A worked example

A user expects git status to run without prompting but adds a broad shell ask rule after the specific status allowance. Because the last match wins, the broad rule takes effect. Reorder the intended exception after the broad rule and retry the read-only action. In a separate multi-file edit, one denied target can still block the whole operation even if the first target is allowed.

Check	Record
Action	The V2 permission action actually checked, such as shell or edit.
Resource	The normalized target path or scanner-produced command being matched.
Order	The last matching effective rule, including agent-level additions.

Reading the failure correctly

doom_loop and lsp are not current V2 Core permission actions, so old examples for them do not explain a present shell denial. An application allow also does not expand operating system authority. Shell commands still run with the host user’s filesystem and process access; policy matching is not an operating system sandbox (OpenCode V2 introduction).

What completes the check

The repair should explain one intended action under the effective ordered policy. A working provider and a permitted tool are separate conditions; broadening every permission obscures that distinction and removes useful task boundaries.