OpenCode & Goose (ACP)
OpenCode and Goose are not two adapters. They are two presets on one generic Agent Client Protocol adapter — a single implementation that speaks ACP and carries per-runtime configuration for the differences that actually matter.
This is the shape Helmora wants for new runtimes: adding one should be a preset row plus a verification pass, not another codebase.
Requirements
Section titled “Requirements”| Runtime | Executable | Authentication |
|---|---|---|
| OpenCode | opencode |
Free Zen models work without signing in; other providers use opencode auth login |
| Goose | goose |
A provider configured via goose configure or environment variables |
Both register as machine agents with folder facets — one registration per machine, with per-folder rows underneath.
What the ACP adapter supports
Section titled “What the ACP adapter supports”Sessions. Create, list, load, and resume, with tail-window pagination when you scroll back through a long transcript.
Streaming tools. Tool calls and their output stream into the transcript as they happen, and file edits render as diffs.
Questions. Ask-the-user requests render as the same choice cards used across Helmora, and pending questions are rebuilt after a reconnect.
Interrupt and queue. Stop works; queued prompts work.
Steering — abort semantics. ACP runtimes cannot inject a redirect into a live turn. Steering declines any parked question, aborts the current turn, and sends your redirect as a fresh one. The composer shows that mode explicitly rather than implying an injection that isn’t happening.
Models. The model list is read from the runtime. Setting a model through Helmora is not available on this path today — pick it in the runtime’s own configuration.
Permission modes. Mapped through ACP session modes, using each runtime’s own vocabulary. Because ACP applies configuration at prompt time, Helmora durably queues your change and applies it on the next prompt.
Provider-declared controls. Anything the runtime advertises as a safe configuration option — including an effort-like scale, when it exposes one — appears as a control in the app. Rows show up because that runtime declared them, not because Helmora hard-coded a list.
External-session mirroring — OpenCode only. Sessions you start in the
opencode CLI appear in Helmora, because the adapter tails OpenCode’s own
session store. Goose has no equivalent store to tail, so Goose sessions
started outside Helmora do not appear.
Known boundaries
Section titled “Known boundaries”These are real gaps, not untested corners, and the app deliberately does not render controls for them:
- No compaction. ACP exposes neither a compact operation nor a provider-authored compaction lifecycle, so the gauge action and the transcript marker are absent for OpenCode and Goose.
- No plan usage. Context usage is reported; subscription-plan usage is not.
- No project browsing, no MCP management, no tools catalog, no configuration form, no diagnostics tab, no slash-command palette, no sub-agent grid, no background-task sheet, no session rename.
- No in-app sign-in. OpenCode’s free models need none; Goose points you at its own configuration.
Adding another ACP runtime
Section titled “Adding another ACP runtime”The generic core is what makes a new ACP runtime cheap, but “cheap” is not “automatic”. Each new runtime still gets a preset and a verification pass before it ships, because ACP leaves enough to the implementer that protocol conformance alone does not predict a good session. We evaluate them case by case — tell us which one you want.
The app renders only what the active adapter declares — see Architecture.