OpenCode support?

[Chuhan-Mateo]

Wouldn't it be great to support OpenCode? And it would be better if I could choose which OpenCode agent to use including the agents that is from OpenCode plugin

[mvschwarz]

Thanks for the idea. OpenCode isn't supported today. OpenRig currently runs Claude Code, Codex and Pi seats, plus plain terminal seats.

The closest related thread is #43, about making harnesses pluggable so adding one like OpenCode takes less work. Your point about choosing the OpenCode agent per seat, including plugin agents, is a useful detail for that. Which agents would you want to run, and would they need to talk to each other the way OpenRig seats do?

— dev-planner@v-openrig-build, on behalf of @mvschwarz

[Chuhan-Mateo]

I usually use the plugin agent from Oh-My-Openagent, they usually have multi agent inside each session but it won't be bother if it put into openRig because openRig is cross session multi agent while omo is in session.

[mvschwarz]

That helps, thanks. So each OpenCode session would bring its own Oh My OpenAgent team, and OpenRig would coordinate across sessions, with one OpenRig seat per OpenCode session. That fits how OpenRig treats a seat.

OpenCode support would come through the harness work in #43, which is the place to follow it. A contributor also has an early OpenCode adapter in PR #32. We've asked them to split out the smaller fixes so those can land first. There's no date yet.

— dev-planner@v-openrig-build, on behalf of @mvschwarz

[mvschwarz]

One more pointer: there's an open community pull request, #32, that includes OpenCode (and Muse) adapters. It isn't merged, so it's not supported yet, but it's the closest existing work to what you're asking for, and comments there on how you'd want to pick the OpenCode agent per seat would be useful.

— dev-planner@v-openrig-build, on behalf of @mvschwarz

[Chuhan-Mateo]

Also, as oh my openagent became a standalone CLI tool instead of a plugin for OpenCode(the omo native), I wish that omo native could also be supported in the future.

[mvschwarz]

Thanks, noted. Oh My OpenAgent's native CLI would be a harness in its own right, and we've recorded it as input for the harness presets work (#43), next to OpenCode. It isn't scheduled, so there's no date.

— dev-planner@v-openrig-build, on behalf of @mvschwarz

[lab1207]

Yes — this is in flight as a scope ask, not just a wish. Issue #517 ('OpenCode as a community runtime') has a working implementation on a fork: KevinUnk/openrig branch feat/opencode-runtime, built by mirroring the pi adapter's discipline — runner protocol contract, one persistent opencode run session per seat with the session id captured from the NDJSON stream and reused, sidecar + markers as the daemon's source of truth, deny-by-default env allowlist.

Current MVP limits (from that issue): no resume token yet (restore = honest fresh launch), fork refused with an explicit error, send via pane stdin. Including choosing which OpenCode agent to use: the branch is about the runtime/transport; per-agent selection would ride on top once the runtime is accepted.

What decides it now is maintainer scope (it's labeled a scope ask), not technical feasibility — the code exists and is described as live-tested. If you want to help it land: test the fork branch against your setup and report back on #517 — user evidence is what moves scope asks.

[mvschwarz]

Thanks, @lab1207. To add to that for @Chuhan-Mateo: #517 already has a yes in principle, so it's waiting on the shared adapter path being designed in Discussion #43, not on a scope decision. OpenCode fits as a community adapter on that path, and new adapter PRs, #517's included, wait for it. Testing feedback on #517 and design input on #43 are the most useful help right now.