OpenCode Shows the Real Boundary of... | Support

Marker: opencode-terminal-agent-canonical-source

OpenCode Shows the Real Boundary of Terminal Coding Agents

Terminal coding agents can look like chat boxes with a shell prompt attached. That is the wrong mental model. The real question is what authority the agent holds inside a repo: what it can read, edit, execute, call, delegate, export, and automate.

OpenCode is useful to Starkslab because its docs and selected source surfaces make that boundary stack visible. This is not an OpenCode adoption review. It is a source-read support note for operators who want to understand what a modern terminal agent exposes before trusting it with a real codebase.

Short version: OpenCode shows that a terminal agent is not just a CLI. It can be a local workflow runtime made of a terminal client, local server, project rules, permissions, agents and subagents, MCP/plugins, SDK/web surfaces, provider routing, and GitHub automation boundaries.

Trust Block

Boundary	Status
Source/docs read	Yes. Based on the accepted Starkslab research memo and official OpenCode docs/source surfaces read in that pass.
Runtime validation	No. No OpenCode command was run, no install was performed, and no provider/auth flow was tested.
Adoption verdict	No. This note does not recommend adopting OpenCode.
Security, sandbox, benchmark, privacy, provider, package, or GitHub automation claim	Not validated. Treat those as blocked claims until a separate runtime/source pass proves them.

Source-read boundary: Source-read-only. No OpenCode command was run, no provider/auth flow was tested, and no security, runtime, benchmark, sandbox, package, GitHub automation, or adoption claim was validated.

Audio deferred: source-read support note; no approved Starkslab audio generation was requested for this source-placement contract.

This note covers:

what OpenCode is, based on source and docs;
why the terminal client/local server split matters;
how project rules become part of the workflow boundary;
why agents and subagents are delegation boundaries;
how permissions decide blast radius;
why MCP, plugins, SDK, provider routing, and GitHub automation expand authority;
what Starkslab would steal;
what not to conclude from a source read;
how this supports the AI Agent Tools and Build AI Agent clusters.

What OpenCode Is, Based On Source And Docs

OpenCode is an open source coding-agent product with terminal-first roots and additional client, server, SDK, web, provider, rules, permission, extension, and automation surfaces. The relevant point is not that another coding assistant exists. The point is that OpenCode's public docs and source pages expose how a terminal agent can become a local workflow runtime.

The accepted Starkslab source-read artifact found these source-visible surfaces:

terminal/TUI interaction;
non-interactive opencode run;
local server and client architecture;
opencode serve, web, attach, SDK/OpenAPI, export/import, and stats surfaces;
project rules through AGENTS.md;
configurable primary agents and subagents;
tool permissions and external directory rules;
MCP servers and plugins;
provider routing;
GitHub automation commands.

That makes OpenCode useful for the AI Agent Tools cluster because it gives Starkslab concrete evidence for a broader claim: terminal coding agents should be evaluated by control surfaces, not by trend heat or model-brand theater.

Proof basis:

Accepted research artifact: starkslab/research/2026-05-22-opencode-terminal-agent-workflow-boundary-dissection.md
Accepted keyword brief: starkslab/keyword-data/briefs/2026-05-22-opencode-terminal-agent-brief.md
Accepted outline: starkslab/content/outlines/2026-05-26-opencode-terminal-agent-outline.md

If you want the broader source-reading discipline behind this kind of claim, read How Agent Tool Radar Scores Open-Source AI Agent Tools.

The Boundary Stack: Terminal Client, Local Server, And Other Surfaces

The terminal UI is only one boundary. The important source-visible shape is a terminal client over a local server, with extra non-interactive, web, SDK, attach, export, stats, and automation surfaces around it.

terminal/TUI -> local OpenCode server -> sessions/messages/tools/providers
                    |-> run / serve / web / attach / SDK / export / stats

That server/client split matters because it changes the operator problem. A terminal agent is no longer just a conversation in a shell. It can become a session system with API surfaces, stored state, model/provider routing, tool execution, machine-readable output, and integration points that another process can call.

For Starkslab, this is the same kind of question handled by The Coding Agent Harness Layer: where does the native tool end, where does the wrapper begin, and where does the operator contract live?

The safe claim is narrow:

OpenCode's source/docs show a terminal-agent architecture with client, server, CLI, SDK, and automation surfaces.

The blocked claims are broader:

the server model is safe;
the server model is production-ready;
auth, host, CORS, SDK, or attach behavior is secure in every environment;
Starkslab tested this runtime.

Those claims need a separate runtime and security pass.

Project Rules Are Part Of The Workflow Boundary

OpenCode's AGENTS.md and rules system matter because instruction supply is not just context. It shapes what the agent thinks the repo wants before permissions, review, or validation enter the loop.

The source-read found a project-rule surface around AGENTS.md, /init, global rules, and compatibility fallbacks. That creates several operator questions:

Where does the agent read project rules?
Are those rules committed with the repo or stored globally?
Do global or personal rules quietly affect project behavior?
Are compatibility files imported from other coding-agent systems?
Can a reviewer inspect the exact instructions that shaped the run?

This is where Starkslab should be strict. A useful coding-agent workflow is not "the model read some context." It is "the agent had a visible instruction source, a target artifact, a bounded lane, and validation commands."

That is why Starkslab issue bodies name target artifact paths instead of relying on conversational intent. If you want the broader planning, execution, validation, and review loop, read AI Coding Agent Workflow: Guardrails, Delegation, Review.

Agents And Subagents Are Delegation Boundaries, Not Just Labels

OpenCode's Build, Plan, General, Explore, and Scout vocabulary is useful because it separates execution, planning, broad delegation, code exploration, and external dependency research into named roles.

From the accepted source-read:

Build is the default development-oriented primary agent.
Plan is a planning/analysis-oriented primary agent, with mutation-oriented behavior constrained by permissions and prompts.
General, Explore, and Scout are subagent categories for multistep work, codebase exploration, and external dependency research.
Custom agents can be defined through JSON or Markdown, including prompt, mode, model, temperature, step limits, permissions, hidden status, and task permissions.

The operator lesson is simple: a "subagent" is not just a persona. It is a delegation boundary. It decides what context, tools, permissions, model settings, task limits, and result channels can be used away from the main interaction.

This is also where source-read evidence must stay careful. The accepted dissection noted public issue traffic around task/subagent permission inheritance. That is a caution source, not proof that a current bug exists and not proof that the behavior is fully fixed. The safe public phrasing is:

OpenCode has had public issue traffic around task/subagent permission inheritance, so subagent permissions should be verified against the exact version before an operator relies on them.

Do not say Plan mode is safe. Do not say subagent permissions are bypass-proof. Do not say delegation is isolated unless a later runtime pass proves it.

Permissions Decide The Blast Radius

The useful question is not whether OpenCode has permissions. The useful question is which actions are allowed, asked, or denied for each tool class and agent role.

The predecessor research identified allow, ask, and deny permission actions, with global rules, tool-specific overrides, object syntax, command/path patterns, home expansion, external directory rules, and per-agent overrides. It also noted broad defaults for many permissions, external directory and doom-loop ask posture, and .env read denial by default except examples.

That gives the note one central operator rule:

Prompts are not a permission model. A terminal agent needs separate controls for read, write, execute, network, external directory, credentials, and delegated work.

Operator permission checklist:

Can file reads be separated from file writes?
Are edit/write/apply-patch tools gated differently from search tools?
Are shell commands controlled by command pattern?
Are web fetch/search and network-like surfaces explicit?
Are external directories blocked, asked, or narrowly allowed?
Are .env files and secrets protected?
Are MCP and plugin tools handled as separate grants?
Do per-agent permissions override or inherit global rules?
Can a subagent use tools the primary agent could not use directly?
Is the permission result inspectable after the run?

The adjacent Starkslab control-plane page is What Is a Coding-Agent Control Plane? Skills, MCP, Config, and Safety Gates, because that page owns the broader language around skills, MCP, config, permissions, sessions, and safety gates.

MCP, Plugins, SDK, And GitHub Automation Expand Authority

Extension surfaces are authority grants. MCP servers, plugins, SDK clients, web/server modes, and GitHub automation widen what the agent can see, call, install, mutate, or export.

OpenCode's source/docs surfaces give several useful proof rows:

MCP servers can add external tools and context.
Plugins can live locally or globally, and npm plugins can be declared in config.
Plugins can hook events, create tools, inject environment variables, protect .env, log, and affect compaction.
SDK/OpenAPI and server modes expose integration paths beyond the terminal UI.
Provider routing moves trust into account, model, billing, and data-handling boundaries.
GitHub automation is a separate repo-mutation surface, not a harmless chat feature.

built-in tools -> MCP -> plugins -> SDK/web/server -> GitHub automation -> provider/account boundary

That is the Starkslab anti-hype point. "Extensible" is not automatically good. It means the agent has more ways to receive context, call tools, install code, pass data, and mutate repos. Each expansion needs a reason, a scope, and a review path.

Blocked claims:

MCP servers are safe by default.
npm plugins are supply-chain safe.
SDK/server mode is safe to expose outside localhost.
GitHub automation is production-ready.
provider routing preserves privacy or cost expectations in every mode.
Starkslab tested any of the above.

If you want a first-party local agent membrane example, read OpenClaw ACP: Running Codex and Claude Code Through a Structured Control Plane.

What Starkslab Would Steal

Starkslab should steal the boundary vocabulary, not the adoption claim.

Useful patterns:

Terminal client over local server as a clear architecture model.
Named Plan/Build/read-only/delegated roles.
allow, ask, and deny as public-friendly permission language.
Per-agent permissions instead of one global trust blob.
Project rule files as visible instruction supply.
MCP and plugins as reviewed authority expansion paths.
SDK, web, export, and stats surfaces as factory integration points.
Provider/share/export caveats as explicit data-boundary language.

The Starkslab translation is stricter than the product feature list. These patterns only compound when tied to target artifact paths, lane scopes, validation commands, review ownership, no-public-action boundaries, and source/public mutation gates.

That is the reason this note belongs to the AI Agent Tools cluster, with Build AI Agent and OpenClaw as support clusters. It helps readers inspect agent-tool control surfaces, then routes builders toward designing better membranes instead of chasing the newest CLI name.

What Not To Conclude From This Source Read

Source docs can show the shape of a workflow boundary. They cannot prove the boundary is safe, reliable, private, benchmark-strong, or worth adopting.

Blocked claims:

OpenCode is safe.
OpenCode is private by default in every mode.
OpenCode's sandbox or permissions are sufficient for sensitive repos.
OpenCode's Plan mode prevents dangerous work.
OpenCode permissions are complete, bypass-resistant, or current-version validated.
OpenCode is better than Claude Code, Codex, Gemini CLI, Qwen Code, Forge, OpenDev, or OpenClaw.
OpenCode works well with every provider.
OpenCode GitHub automation is production-ready.
Starkslab recommends adopting OpenCode.
Starkslab tested OpenCode runtime behavior.

This section should remain in any public version. It prevents a source-read support note from drifting into a review, tutorial, benchmark, or endorsement.

Operator Checklist For Evaluating OpenCode-Style Terminal Agents

Use OpenCode as a concrete inspection model for any terminal agent:

Is the terminal UI only a client over a server or daemon?
What commands expose non-interactive, server, web, SDK, export, or attach modes?
Where do project rules live, and what takes precedence?
Can planning stay read-only without relying on prompt wording?
Are file reads, writes, shell, web, external directories, and secrets separate permission classes?
Are permissions global, per tool, per path, per command, and per agent?
Can subagents inherit or isolate context, tools, permissions, and results?
Which MCP servers, plugins, skills, or extensions widen the tool surface?
Are provider credentials, model routing, and hosted services explicit?
Is share/export behavior a data boundary?
Does GitHub automation have a separate token, branch, PR, and review path?
What evidence can a supervisor inspect after the run?

If a tool cannot answer those questions clearly, the problem is not just documentation. It is operator risk.

Where This Fits In Starkslab

OpenCode is external source evidence for Starkslab's larger thesis: terminal agents are useful only when their authority becomes inspectable, bounded, and reviewable.

AI Agent Tools:

Compare tools by control surfaces, not by hype.
Use OpenCode as one source-visible example of a terminal-agent boundary stack.
Keep adoption and ranking claims blocked until stronger evidence exists.

Build AI Agent:

Design workflows with explicit runtime, tool, permission, provider, extension, and review boundaries.
Treat headless output, SDKs, and server surfaces as factory integration points, not incidental features.

OpenClaw:

Use first-party Starkslab proof to show why local/operator-owned agents need membranes around files, credentials, tools, delegation, and review.
Route readers to OpenClaw and Symphony only where the next question is about operator contracts, not as a forced brand loop.

The immediate next publish path is straightforward: a later live-publish ticket should verify the public route, notes API truth, sitemap membership, keyword-ledger row, and Search Console indexing handoff before this becomes a live Starkslab page.