[Discussion] OpenCode V2 Plugin Support

[CasualDeveloper]

Describe the enhancement you want to request

Support Cursor models in OpenCode V2, including private models, exact variants, images, and OAuth login. OpenCode should manage history, permissions, tools, and compaction.

Use beta for the V2-only package and keep main as the existing release line. Publish reviewed 3.0.0-beta.N versions under the npm beta tag. The channel name identifies V2 compatibility, not a lower quality bar.

Current status

Hey @makeittech, #33 has merged and #35 is ready for review. I closed #34 as superseded because its changes are included in #35.

The amended implementation is 4932ff9 on feat/opencode-v2-host-owned-cursor. It targets released @opencode/* 2.0.6 and the provider/model API. OpenCode owns history, permissions, tools, and compaction while the adapter preserves the live Cursor catalog and exact variants.

This update keeps incomplete catalog discovery retryable instead of caching a partial inventory as complete. It also derives checkpoint occupancy without double-counting generated output and keeps terminal Run counters in provider metadata. Cursor receives the SDK's MCP tool-family allowlist, native shell streams complete, unsupported exec requests receive explicit replies, and native StrReplace stays declined.

npm run verify passes locally with 95 tests and the pinned-host acceptance gate. Bounded live host-tool checks passed with Composer and Grok; one earlier tool-less turn was not reproduced, so its exact cause is still unverified. CI status for this head is on #35. The acceptance report records remaining live checks for instruction priority with images, opaque reasoning, and sustained compaction.

Please keep this issue open through publication and release checks. Code review continues in #35.

[CasualDeveloper]

Thanks for picking this up in #32, @makeittech. I pulled the current upstream refs and compared them with 3af03f6. The native V2 transport is largely intact, and preserving V1 through the ./v1 export makes sense.

I think this issue should remain open for now. There is no beta release on npm yet, and the planned release acceptance is not complete.

I also noticed that #32 said it must not merge into main yet, but it was merged there. origin/main and origin/beta currently contain identical trees. Was that intentional?

Before publishing 3.0.0-beta.2, I think these regressions need attention:

• The CI workflow that ran npm run verify was removed. The release workflow now runs only the legacy smoke tests and build, skipping the V2 tests, package validation, and V2 loader smoke test.
• The release workflow cannot advance 3.0.0-beta.2 to 3.0.0-beta.3. Its default bump produces 3.1.0, while a patch bump attempts arithmetic on 0-beta.2.
• A dry run still commits, tags, and pushes changes.
• BridgePool now spawns untracked overflow workers after reaching its configured maximum. Its kill() path also stops notifying active readers, which can leave V2 requests waiting during transport shutdown. The regression tests for these cases were removed.
• OPENCODE_CURSOR_DEFAULT_CONTEXT_WINDOW and OPENCODE_CURSOR_DEFAULT_MAX_TOKENS remain documented, but the implementation now ignores them and uses hardcoded values.

I recommend fixing these before publishing the beta. I can prepare a narrow follow-up PR against the new dual-version layout if that would help.

[sdziupin]

Thanks @CasualDeveloper! This is exactly the direction I'd like to take.

I accidentally merged #32 into main while preparing the V2 work - wrong target on my side. I'm reverting that from main and preserving the V2 state on a new beta branch instead.

So the structure will be:

main: OpenCode V1 / plugin 2.x maintenance
beta: OpenCode V2 / plugin 3.x beta

Your proposed separation makes much more sense, especially while the V2 plugin API is still moving.

Once beta is in place, please feel free to target the V2 work there. Thanks for coordinating this and for the work!

[CasualDeveloper]

Thanks @makeittech. I opened #33 against beta with the release, CI, bridge-capacity, and configuration fixes discussed above.

The full local npm run verify gate passes, and the upstream verify check is green. The PR is ready for review:
#33

[CasualDeveloper]

@makeittech I opened #34 as a small follow-up to your non-blocking observations on #33. It documents the reviewed manual -beta.N bump and exact-artifact release flow, and clarifies why the constants test intentionally launches Bun through process.execPath.

I left the permissive Number() parsing unchanged because strict decimal-only configuration is not currently required. The full local npm run verify gate and the upstream verify check are green.