Provider-flexible coding agent
How to use
OpenCode.
Using plan, build, exploration, and custom agents across repositories while controlling models, commands, edits, external directories, web access, skills, and subagents.
OpenCode is a open-source AI coding agent for terminal, desktop, and editor workflows. Using plan, build, exploration, and custom agents across repositories while controlling models, commands, edits, external directories, web access, skills, and subagents. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to OpenCode
Get into the official OpenCode experience with the right account and a setup you understand.
- 01
Start at https://opencode.ai/ and confirm the domain before entering account or payment information.
- 02
Availability: OpenCode provides terminal, desktop, and editor interfaces, supports many hosted and local model providers, and offers configurable primary agents, subagents, skills, and granular permissions.
- 03
The official application or CLI, an approved model provider or local model, a project checkout, and reviewed provider credentials and permission configuration.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful OpenCode session
Learn the interaction loop using a small task with a clear outcome.
- 01
Install OpenCode, connect one approved provider, and confirm how its credentials and session data are stored.
- 02
Open a clean repository branch and use a planning agent to inspect the task without edits.
- 03
Configure ask or deny rules for risky actions before switching to a build agent.
- 04
Review the complete action history, diff, tests, and provider usage before committing or sharing.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of OpenCode output
Turn generated code into a change you would put your name on in review.
- 01
Restate the intended behaviour and the acceptance criteria before reading a single generated line.
- 02
Read the diff rather than the chat summary; the summary describes intent, the diff describes what actually changed.
- 03
Run the test suite, then write a test that would fail if the change were wrong, and confirm it passes for the right reason.
- 04
Check the edges the model tends to skip: error paths, null and empty cases, concurrency, and migration or rollback behaviour.
- 05
Trace every new dependency, network call, and file write, and confirm each one is genuinely required.
- Review the diff, never the description of the diff.
- A passing test suite proves the tests pass, not that the change is correct.
- Keep changes small enough that a human can actually review them.
Privacy & permissions
Use OpenCode safely
Give the tool enough repository access to help, and no more than that.
- 01
Decide what the tool may read and what it may write before connecting a repository.
- 02
Scope tokens and integrations to the narrowest repository, branch, and permission set that still works.
- 03
Keep secrets out of the context window: use environment variables and secret stores, never inline credentials.
- 04
Require review before generated code touches authentication, payments, permissions, migrations, or deletion paths.
- 05
Audit what the integration retained after the session, and revoke access that is no longer needed.
- Provider terms, credential storage, agent definitions, permission syntax, and defaults can change across versions. Pin the version and current documentation, deny secrets and external directories by default, keep shell, edits, web access, skills, MCP tools, and subagents least-privileged, review saved approvals, avoid auto mode on untrusted repositories, bound iterations and cost, and independently verify every change.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use OpenCode for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Separate read-only investigation from implementation and enforce explicit permission boundaries for the transition.
↓ 02 WorkflowCreate a read-only OpenCode review agentConfigure a specialized agent that can inspect a diff and run safe diagnostics but cannot modify the repository.
↓Workflow 01
Complete a repository change with OpenCode plan and build agents
Separate read-only investigation from implementation and enforce explicit permission boundaries for the transition.
Outcome: Produce a tested, scoped diff with a clear record of planning, actions, provider use, and human approval.
- 01
Open the intended checkout on a clean branch, record status and baseline checks, and confirm the active provider, model, version, and project configuration.
- 02
Use the plan agent to inspect relevant code and state acceptance criteria, architecture constraints, non-goals, and required validation without edits.
- 03
Review the plan, then configure ask or deny rules for shell commands, edits, external directories, web access, skills, and subagents before using build.
- 04
Monitor every action and changed file, reject scope or dependency drift, and run focused tests while keeping pushes and destructive commands blocked.
- 05
Run trusted checks independently, inspect the full diff and session record, and commit or publish only through the normal human-reviewed workflow.
What good use looks like
- Separate planning from editing.
- Deny external directories by default.
- Keep push and destructive commands blocked.
Workflow 02
Create a read-only OpenCode review agent
Configure a specialized agent that can inspect a diff and run safe diagnostics but cannot modify the repository.
Outcome: Add repeatable AI-assisted review without letting the reviewer silently fix, execute, or publish code.
- 01
Define the review scope, threat model, severity rubric, allowed evidence, safe commands, provider, maximum steps, and required output format.
- 02
Create a project-scoped review agent whose edit, external-directory, network, skill, MCP, and subagent permissions are denied unless explicitly justified.
- 03
Allow only read operations and specific diagnostic commands, keeping broad shell patterns, environment files, credentials, pushes, and package installation blocked.
- 04
Test the agent on known defects, false positives, hostile comments, generated files, secrets, large diffs, and requests to bypass its permissions.
- 05
Require exact file evidence and reproduction steps, verify consequential findings manually, and version the agent configuration with owner review.
What good use looks like
- Deny edits in the reviewer.
- Allowlist exact diagnostics.
- Manually verify high-severity findings.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.