CLI · Coding agents · Anomaly
OpenCode
Use a configurable terminal agent to explore code and prepare changes, with model choice and permission settings made explicit.
Project access becomes model context. Files and tool output may be sent to the selected provider. Keep credentials and unrelated private material outside the task, and check that provider's data policy.
Understand the tool
What it does.
OpenCode is a coding agent that runs in a terminal and can connect to different model providers. It can inspect a project, propose edits and use tools according to its configuration. The evaluation here pins the official v1.19.3 binary; upstream also advertises a separate v2 line with different installation instructions.
Why use it?
Useful when you want model choice and a terminal workflow you can configure. Start with a small repository and explicit permissions so the first session answers a specific question. Provider choice, project access and allowed commands matter more than the name of the agent.
A useful fit for
- Explaining an unfamiliar code path
- Preparing a small change for human review
- Teams that need explicit model and tool configuration
From need to output
Ways to put it to work.
These are suggested workflows based on the documented capabilities. They are not recorded runtime results.
Use case 01
Trace one feature through a repository
A developer needs to understand where a request is validated before changing it.
- Choose the intended project directory and inspect its configuration.
- Allow only the reads needed for the task and ask for file references explaining the request path.
- Check those references against the source before using the explanation.
Intended outputA code map you can verify before editing.
Use case 02
Prepare a bounded patch
A small bug has a clear reproduction and an existing test.
- Select a model and review the applicable provider data policy.
- Set tool permissions, give the reproduction and limit the requested change.
- Inspect the diff and test results before committing.
Intended outputA reviewable proposal with a defined scope; correctness still needs verification.
A concrete starting point
Inspect available agents before a session
For the documented v1 CLI, list configured agents before choosing one. This illustrative command was not part of the runtime probes.
opencode --pure agent listWhat this can change
Reads agent configuration and prints metadata; it does not ask a model to edit the project. Check the installed version because v2 uses a separate product line.
This example has not been executed for this review. Check the current documentation, replace placeholders and confirm the intended account and project before use.
Before you start
Setup and access.
What you’ll need
- An installed OpenCode version matched to its documentation
- A project directory you are authorized to expose to the selected model
- A supported provider or local model setup for agent tasks
- Authentication
- Provider-specific credentials or an eligible service account may be required for model calls. Local configuration inspection does not require a provider login.
- Can read
- Project files allowed by the configured tools
- Agent configuration and enabled integrations
- Can write or change
- Project edits, shell effects and session files according to allowed tools
- Network and data flow
- Selected model provider
- Configured integrations and package or model metadata services
- Approval and control
- Review permission settings before starting. Most documented v1 permissions default to allow; a resolved deny setting is not a substitute for verifying actual tool enforcement.
Check your environment
Compatibility, costs and license.
Compatibility notes
- Windows, macOS and Linux options; upstream recommends WSL for its Windows workflow
- The tested native Windows baseline binary is v1.19.3; do not treat these results as v2 coverage
Costs and account requirements
The repository uses MIT terms. Model-provider usage and optional hosted services have their own prices and limits.
Current pricing or plan information ↗MIT
Applies to the source; model services and third-party integrations have separate terms.
Read the license or service terms ↗Keep the boundaries visible
Concerns and limitations.
Project access becomes model context
Files and tool output may be sent to the selected provider. Keep credentials and unrelated private material outside the task, and check that provider's data policy.
Permissions and integrations change the effects
Shell tools, edits and plugins can act with the user's operating-system access. Review local configuration and third-party code before allowing it.
A server needs a boundary
The local server should bind only where needed and use a password. One successful localhost authentication check does not establish safe public exposure.
Where it may fall short
- This review evaluates v1.19.3. Upstream v2 and its @opencode/cli installation are a separate target.
- Model availability, quality, context limits and cost depend on the configured provider.
Observed behavior · 2026-10-18
Runtime and security findings.
The v1.19.3 binary resolved explicit deny settings, rejected an invalid permission value and enforced a password on the tested localhost configuration endpoint. No model or agent task was run.
These checks cover the conditions below. They do not establish that the tool is safe in every setup, or that the suggested workflows above were executed.
What we found
Observed in this evaluation
Deny settings resolved, but tool enforcement remains untested
The configuration command returned permission={"*":"deny"} and disabled sharing. This establishes configuration parsing, not whether every agent tool obeys those settings.
In practice: Inspect resolved settings and verify intended permission prompts in a disposable project before granting broader access.
Observed in this evaluation
Password protected the tested local endpoint
The same /config endpoint returned 401 without authentication and 200 with the synthetic password. Only this endpoint and the loopback listener were exercised.
In practice: Keep the server on loopback unless remote access is required; configure authentication and review any remote deployment separately.
Documented concern · medium severity under stated conditions
Default permissions deserve attention
The v1 permission documentation allows most actions by default, with specific exceptions and safeguards. Plugins and model providers introduce additional code and data boundaries.
In practice: Choose explicit permissions and review provider and plugin configuration before using a private repository.
Version, environment and fixture
- Version or deployment
- 1.19.3
- Tested target
- https://github.com/anomalyco/opencode/releases/download/v1.19.3/opencode-windows-x64-baseline.zip
- Artifact identity
- SHA-256 0d59113484bfe8d6dc146fc981f5c33faa8318303c183711b7a9387060b289e8 of the downloaded ZIP archive. Recorded to identify the tested artifact; no independent signature or provenance audit was performed.
- Environment and fixture
- Windows 11 x64; Python 3.12.10 harness. Raw timestamps use UTC.
- Fresh per-tool home, config, cache and temporary directories. Child environments used allowlisted OS/runtime paths without inherited account credentials. Only synthetic local files were used.
- Configuration isolation is a test control, not an operating-system sandbox.
- Auto-update, default plugins, model metadata fetching, LSP downloads and imported external agent configuration were disabled for the probes.
Checks and results
5 recorded checks. Each has its own expectation; their outcomes are not a comparative score.
Pinned binary versionMet expectation
- Method
In an empty fixture directory, use fresh HOME/USERPROFILE and XDG config/cache/data/state paths. Set OPENCODE_DISABLE_AUTOUPDATE, OPENCODE_DISABLE_DEFAULT_PLUGINS, OPENCODE_DISABLE_LSP_DOWNLOAD, OPENCODE_DISABLE_CLAUDE_CODE and OPENCODE_DISABLE_MODELS_FETCH to true. Set OPENCODE_CONFIG_CONTENT to {"permission":"deny","share":"disabled"}. Command argument array: ["opencode", "--version"].- Expected
- Print version 1.19.3.
- Observed
- Exit 0. 1.19.3
Resolve explicit permissionsMet expectation
- Method
In an empty fixture directory, use fresh HOME/USERPROFILE and XDG config/cache/data/state paths. Set OPENCODE_DISABLE_AUTOUPDATE, OPENCODE_DISABLE_DEFAULT_PLUGINS, OPENCODE_DISABLE_LSP_DOWNLOAD, OPENCODE_DISABLE_CLAUDE_CODE and OPENCODE_DISABLE_MODELS_FETCH to true. Set OPENCODE_CONFIG_CONTENT to {"permission":"deny","share":"disabled"}. Command argument array: ["opencode", "--pure", "debug", "config"].- Expected
- Resolve deny permissions and disabled sharing.
- Observed
- Exit 0. Resolved configuration included permission={"*":"deny"}, share="disabled", plugin=[], command={} and username="unknown".
Reject an invalid permission valueMet expectation
- Method
In an empty fixture directory, use fresh HOME/USERPROFILE and XDG config/cache/data/state paths. Set OPENCODE_DISABLE_AUTOUPDATE, OPENCODE_DISABLE_DEFAULT_PLUGINS, OPENCODE_DISABLE_LSP_DOWNLOAD, OPENCODE_DISABLE_CLAUDE_CODE and OPENCODE_DISABLE_MODELS_FETCH to true. Set OPENCODE_CONFIG_CONTENT to {"permission":"deny","share":"disabled"}. Replace OPENCODE_CONFIG_CONTENT with {"permission":"not-a-permission"}. Command argument array: ["opencode", "--pure", "debug", "config"].- Expected
- Reject the invalid permission value.
- Observed
- Exit 1. Configuration validation reported Expected PermissionActionConfig for the invalid value.
Local server authentication boundaryMet expectation
- Method
In an empty fixture directory, use fresh HOME/USERPROFILE and XDG config/cache/data/state paths. Set OPENCODE_DISABLE_AUTOUPDATE, OPENCODE_DISABLE_DEFAULT_PLUGINS, OPENCODE_DISABLE_LSP_DOWNLOAD, OPENCODE_DISABLE_CLAUDE_CODE and OPENCODE_DISABLE_MODELS_FETCH to true. Set OPENCODE_CONFIG_CONTENT to {"permission":"deny","share":"disabled"}. Set OPENCODE_SERVER_PASSWORD to the synthetic fixture value ionbin-synthetic-password. Start opencode --pure serve --hostname 127.0.0.1 --port 50950; GET http://127.0.0.1:50950/config without an Authorization header. Stop the owned server after both requests.- Expected
- Return HTTP 401.
- Observed
- HTTP 401. Response body was empty. Owned server process tree was stopped after the test; cleanup exit 0.
Local server authenticated requestMet expectation
- Method
In an empty fixture directory, use fresh HOME/USERPROFILE and XDG config/cache/data/state paths. Set OPENCODE_DISABLE_AUTOUPDATE, OPENCODE_DISABLE_DEFAULT_PLUGINS, OPENCODE_DISABLE_LSP_DOWNLOAD, OPENCODE_DISABLE_CLAUDE_CODE and OPENCODE_DISABLE_MODELS_FETCH to true. Set OPENCODE_CONFIG_CONTENT to {"permission":"deny","share":"disabled"}. Set OPENCODE_SERVER_PASSWORD to the synthetic fixture value ionbin-synthetic-password. Start opencode --pure serve --hostname 127.0.0.1 --port 50950; GET http://127.0.0.1:50950/config with HTTP Basic username opencode and that synthetic password. Stop the owned server after both requests.- Expected
- Return HTTP 200.
- Observed
- HTTP 200. Returned configuration included permission={"*":"deny"}, share="disabled" and plugin=[]. Owned server process tree was stopped after the test; cleanup exit 0.
Practical caveats
- The tested artifact is the official v1.19.3 Windows baseline release. Current upstream material also advertises v2 and @opencode/cli; these results do not transfer to that runtime.
- No model requests were made. Configuration output and two HTTP responses do not establish coding quality, prompt-injection resistance or complete server authorization.
What this evaluation does not establish
- Model calls, generated-code quality, tool execution, prompt-injection resistance and enforcement of deny permissions during an agent session.
- Provider authentication, paid usage, plugins, MCP servers, remote exposure and the separate OpenCode v2 runtime.
The basis for this review
Why it’s in the collection.
Adds a configurable terminal-agent option after the original ten entries, with model choice and explicit permission controls as its distinguishing workflow. The pinned v1 evaluation does not rank coding quality or cover v2. The original catalog order is preserved; this is an editorial position, not a measured adoption or security rank.
The number is an editorial starting order within the cli tools collection. It does not measure popularity, speed, reliability or safety.
Why we added it
Adds an active open-source terminal-agent option with configurable model providers; complements the existing vendor-specific agent reviews.
Selection evidence checked .
- Repository interest
- 216,678 GitHub stars at this snapshot ↗
Interest in the source repository; not a count of verified users or installations.
- Repository activity
- Last push reported by GitHub: . A push can include documentation or maintenance; it does not establish a new stable release.
- Release signal
- v1.19.3 ↗ · published . This selection signal can differ from the exact runtime tested above.
- A single dated repository-interest/release snapshot; not measured adoption, growth, effectiveness or security.
- Repository interest and release activity do not establish reliability, model quality or safety. The evaluation names the exact version and conditions tested.
What we reviewed
- Official documentation, repository, license and release identity
- Practical access boundaries and a separate bounded runtime evaluation
The evaluation above lists the current runtime coverage and untested behavior.
Reviewed Oct 18, 2026. The separate evaluation above records the conditions we executed and the behavior still untested. Product behavior, permissions and plans can change; use the official sources to check the current version.
Follow the evidence
Official sources.
- OpenCode repository and version transition ↗github.com
- CLI commands and configuration flags ↗opencode.ai
- Permission configuration ↗opencode.ai
- Local server authentication ↗opencode.ai
- MIT license ↗github.com
- Evaluated v1.19.3 release ↗github.com