Permission model

Each run generates a complete ephemeral OpenCode configuration, passes it through OPENCODE_CONFIG_CONTENT, and runs under its own generated agent. Your opencode.json is never read for permissions, never edited and never left changed.

--standalone is mandatory and load-bearing: without it, opencode run attaches to the already-running background service that was started with your configuration, and the generated profile is silently ignored. The run also disables project-level config, so an opencode.json inside the repository being reviewed cannot re-enable plugins, MCP servers or permissions for its own review — and the profile declares no plugins, no MCP servers and no extra skills.

Reviewer and inspector

Deny everything by default, then allow exactly:

• reading files (except *.env)
• glob, grep, list, LSP
• a fixed read-only git allowlist (git status*, git diff*, git log*, git show*, …)

Editing, writing, patching, committing, pushing, running builds or tests, web access, subagents, skills and anything outside the repository are denied.

Builder

Allows edits and normal shell work inside the repository, runs with --auto paired with explicit denials, and blocks every history- or publication-affecting git command, forge and publish tools, privilege escalation, destructive system commands, network access, and anything outside the repository. After a delegated build the runner re-reads HEAD and fails the run if the builder moved it.

What this does not cover

• A permission profile is not an operating-system sandbox. Use a disposable worktree for delegated builds.
• The plan, and for inspection the diff, are sent to whichever provider OpenCode is configured with. That is the point of an external review — but it is a disclosure, so choose deliberately.
• read on *.env is denied to reduce incidental exposure. That is not a secret-scanning guarantee.
• Run artifacts hold prompts, plans and possibly private code. They are written outside the repository, and the runner refuses an artifacts path inside it. Don't commit them and don't paste them into issues unsanitized.

To report a vulnerability, see SECURITY.md. Never open a public issue for one.