#33 OpenCode as an eighth agent runner, and why its containment has to live in an agent of its own

[Anonymous]

Originally created by: imshaikot

The side panel runs on whichever agent CLI you already have logged in — seven so far. OpenCode (anomalyco/opencode, MIT, npm i -g opencode-ai) is the obvious next one: open source, provider-agnostic — Anthropic, OpenAI, Google, local models and a dozen more behind one CLI — and with a documented headless mode, opencode run --format json.

It is worth adding for reach as much as coverage: someone who has settled on OpenCode to keep their choice of model has no way to put it behind the side panel today.

What a runner needs, and what OpenCode offers

What a runner needs	OpenCode 1.18
Streaming	run --format json — one event per line: step_start, text, tool_use, step_finish (with token counts), error. No closing event, so endsOnExit
Per-run MCP server	mcp.<name> in an inline config passed as OPENCODE_CONFIG_CONTENT, with environment for the run id
System prompt	instructions, a list of files appended to OpenCode's own prompt
Resume	--session <id>; every event carries sessionID
Per-run tool rules	an agent defined in that same config, with a permission ruleset ("*": "deny", then allows by name) — run with --agent <name>
Model / effort	--model provider/model, --variant <name>

Everything is per invocation and nothing needs writing into the user's own config, which is the best position any runner has started from.

The traps

Each of these is a way the obvious adapter would be wrong, so each needs a test, not a comment:

1. The config is not inert. OpenCode expands {env:VAR} and {file:path} anywhere in its config, and a unicode escape does not stop it. The run's system prompt carries page text — the focused element, fetched data, file reports — so a page that says {file:~/.ssh/id_rsa} would get that file read into the prompt. The prompt has to be a file the config points at; instruction files are read verbatim.
2. An agent of the same name is merged, in the user's key order. Rules are last-match-wins. If the user already has an agent called browsentic with {"*": "allow", "bash": "allow"}, their "*" keeps its place and their bash lands after our deny. The run's agent needs a name nobody picks by accident, and the reader should stop a run in which a tool outside the browser actually ran.
3. Plugins run inside OpenCode and can add tools or answer its permission prompts, so --pure is load-bearing — and it has to cover local plugin files, not only npm ones.
4. Sharing. A user's "share": "auto" publishes every session to a public link. OPENCODE_DISABLE_SHARE must be set.
5. opencode run reads stdin to EOF and appends it to the message. With stdin left open it hangs silently at start-up.
6. Defaults that would hurt a browsing run: MCP calls time out at 60 s (an approval card can wait longer), tool results are cut at 50 KB into a file the model is told to Read, every new session spends a model call on a title, and every folder outside git shares one session list with the user's own work.
7. Scoped reads for one-shots are matched against the path relative to the project root, which is / outside git.

Known limitation

OpenCode Zen's free models will not serve a contained run. They answer only requests carrying OpenCode's own built-in tools (403 FreeTierError: free tier can only be used from within OpenCode), and a Browsentic run offers the browser's alone. That is their policy, and working around it would mean loosening containment, so the runner should instead report needs setup until OpenCode is signed in to a provider (opencode auth login) or declares one in its config.

Done means

• src/daemon/agent/runners/opencode.ts, one line in RUNNERS, a catalog entry and a CONTAINMENT entry — no extension changes beyond the vendor mark.
• vetPlan can see the containment even though it lives in an environment variable, and refuses a plan that lost the deny, --pure, the agent name or the share switch.
• Fixtures recorded from the real CLI, and the traps above each pinned by a test.
• Beta in the picker and the docs until a real model has driven a real page and resumed a follow-up turn.
• The docs and the agent tables updated, and the README icon once the site has one.

Not to be confused with driving Browsentic from OpenCode over MCP, which already works — that is MCP clients. This is about what runs the side panel.

[Anonymous]

Ticket changed by: imshaikot

• status: open --> closed