iPAI Radar
← Chinese edition
CODING AGENT · DOCUMENTATION REVIEW

OpenCode: models, permissions and safety

A provider-flexible coding agent deserves an evaluation of its permission boundaries, not just its popularity.

English edition published . This adapts our Chinese project review; migration and security sources were rechecked on that date.

Evidence boundary: This is a documentation-based review, not a hands-on test or a V2 benchmark. The Chinese edition's original October 15 editorial score has not been revalidated for V2. We do not turn GitHub stars into a quality or search-demand claim.

Configure OpenCode permissions before a first task

Checked October 29, 2026 against the OpenCode 1 permission guide; not tested on V2. Back up the project-root opencode.json and merge:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": "ask"
}

In a disposable project, request a small file edit and verify approval appears. Reject once and inspect the file. Avoid --auto during this check: it approves requests that would ask. If prompts are absent, inspect overrides using the configuration precedence guide. This is a proposed check, not an executed test.

What should you evaluate?

Our existing project review focuses on OpenCode's provider choice and coding workflow: reading a repository, making changes and invoking tools. Provider flexibility is useful only if the models you intend to use work with your actual tasks and budget.

Do not interpret the software's license as a promise of free model usage. Check the terms and pricing of the provider you connect, decide which repository data may leave the machine, and record those choices before a trial. This page does not provide a current price comparison.

Before installation: distinguish OpenCode 1 from 2

The official migration guide says both generations use the same command name and are not installed side by side by default. An installation can replace the earlier binary. Identify the existing installation and follow the matching official instructions rather than mixing tutorials.

  • Keep a readable copy of your working configuration before migrating.
  • Review plugins, server integrations and terminal configuration: these have breaking changes.
  • Validate models, credentials, permissions and MCP connections after migration.
  • Do not point V1 at configuration converted to V2-only formats.

These are migration checks, not a claim that we performed the migration on your operating system. The upstream guide is the authority for version-specific details.

Approval prompts are not a sandbox

The project's published security model states that the agent is not sandboxed. Approval prompts do not provide process, filesystem or network isolation. For isolation, the project recommends a container or virtual machine.

  • Server mode: when enabling it, configure authentication and restrict network exposure. The security document identifies OPENCODE_SERVER_PASSWORD as the password setting.
  • Model providers: their own policies govern data sent to them.
  • External MCP servers: assess their behavior and data handling separately; they are outside the project's core trust boundary.

Our practical recommendation: use a disposable repository without secrets for a first trial. A container with broad host mounts is not automatically an adequate boundary; review what access you actually grant.

A small trial you can reproduce

The following is our proposed evaluation procedure, not a report of completed testing. Keep the same task and acceptance criteria when comparing runs.

  1. Write down the setup. Record the installed version, operating system, chosen model, provider and permission configuration. Never publish API keys.
  2. Choose a bounded change. Use a disposable copy of a small repository with a known passing test command. Save its initial revision and test result.
  3. Ask for an explanation first. Check whether the agent identifies the relevant files and constraints before permitting edits.
  4. Allow one change. Review the proposed commands and resulting diff. Record unexpected file changes and approval requests.
  5. Run the same tests. Keep the actual output, including failures. A confident answer is not evidence that the task works.
  6. Check recovery and cost. Confirm you can restore the disposable copy, inspect provider usage, then decide whether to expand access.

A useful result contains the task, before-and-after diff, test output, failures and measured cost. Until those artifacts exist, treat claims about speed, reliability and value as unverified.

Sources and limitations

We have not measured task success rate, operating-system compatibility or V2 performance. This English URL contains static English content and does not require JavaScript or a saved language preference to read.