Support OpenCode V1 and V2 from one plugin export - #9016

All contributors have signed the CLA. Thank you! ✅
_{Posted by the CLA Assistant Lite bot.}

I have read the CLA Document and I hereby sign the CLA

Proof of life of the feature working:

Follow-up on this branch: the first patch made one export load on OpenCode 1 and 2. Using it against OpenCode 2.0.16 showed the V1 pipeline still receiving V2 shapes.

This commit translates chat messages and events into the V1 info/parts and properties shapes, and fills the client methods the tools call: agents, providers, models, skills, config, and session create, prompt, list, status, children, and todos. Parent links are stored by the adapter because V2 create has no parentID. Todos and toasts are stored by the adapter because OpenCode 2 has no todo API and the server context has no toast. Manual compaction asks to continue once on the next idle; automatic compaction does not send a second prompt. The TUI claims the sidebar slot, the CLI uses the V2 session API when the server is V2, and an OpenChamber extension publishes toasts and incomplete todos.

On an isolated OpenCode 2.0.16 server, the plugin loaded, a prompt completed, and session_list returned a session that existed before the plugin loaded. The log had none of the previous failures: v2 hook failed, app.agents is not a function, or client has no equivalent.

Proof of life of the feature working:

what is this IDE / GUI you are using? which seems to detect OMO agents

What is the set of things to do, for making v1 tools to become v2 compatible? Cus a lot of other OpenCode context management tools need migration

I update this to latest dev here:
dev...maurerle:oh-my-openagent:feat/opencode-v1-v2-plugin

It works well with opencode v2.

Thanks for this work @SwarmStorm. A heads-up on direction: we're consolidating OpenCode V2 support on one additive dual-host shape (a separate src/v2/ entry exporting { id, setup, server } next to the V1 code, V1 behaviour untouched), landing as small reviewable slices with a runtime parity matrix as automated tests. The plan is in #9389, where @fazulfi offered a complete, production-tested port.

This PR explores the same single-export, dual-host direction, so you'd be very welcome to review the slices or co-author one. Where your work is reused, it will be credited in the changelog. I'm leaving this PR open for now; once the first slice lands we'll compare what this covers and close it with a pointer if it's fully covered.

Bug report + fix for this branch's V2 hook bridge: SwarmStorm#1.

writeHookMessagesBack (src/v2/message-shape.ts) writes the edited V1 view back to the V2 context messages by index. Any messages.transform hook that inserts a message (team-mode status, monitor status and team mailbox injectors all do) shifts every later message's parts into its neighbour. When the latest user-role message sits between two tool steps (an instruction file pulled in by a read), the assistant's reasoning + tool-call parts land in a tool message, and OpenCode 2.0.28 rejects the request on every provider (… tool messages only support tool-result content for now, logged as Failed to drain Session) until the next user prompt.

The PR maps each view back to the message it came from (WeakMap) and adds tests that fail before the change. Reproduced from a real session's stored history; details in the PR.

The adapter as written removes user-registered namespaced MCP tools matching V1 false rules (including grep_app_*) from the shared registry for every agent, so even the librarian's explicit allow cannot recover them: #10237. Fix proposal and regression details: #10237 (comment).

The proposed guard uses native registered.options.namespace metadata to preserve shared namespaced registrations under both exact and wildcard false rules—not a name-spelling exception. Unnamespaced plugin/native removal stays unchanged, and MCP execution remains subject to host permissions; translating V1 defaults into per-agent V2 deny rules is a separate policy decision.

Since the V2 adapter is not on dev yet, I'm happy to open a focused PR against your branch if you'd prefer that to applying the change yourself.

@SwarmStorm I checked your head 502a4f0f against current dev 2e41a503 in an isolated clone. The merge conflicts are only package.json and bun.lock, not adapter source. Upstream moved the old root runtime entries into devDependencies; the resolution retains that layout/current dependency graph and adds the external runtime @opencode/plugin: 2.0.16, then regenerates the lock with lifecycle scripts disabled.

I prepared a rebased copy in my fork, preserving your two commits, authorship and messages. Cherry-picks, in order: 36a21a96, a8d435b6. No extra adapter fixes are folded in; the non-manifest/lock source patch is unchanged. Your branch was not modified; nothing was force-pushed.

Verification: export/V2-host/V2-CLI tests 16 pass, 0 fail, and root typecheck passes. The additional TUI/state/SQLite group has two Windows EBUSY fixture-cleanup failures plus a leaked-temp teardown failure; the SQLite code is unchanged, but I have not rerun the original-head baseline. No build, full-suite or live-runtime validation claimed.

I know the additive dual-host slices in #9389 are the intended direction. Please use the branch/cherry-picks if useful; happy to help adapt the rebase to those slices or keep the #10237 registry follow-up separate.