[Discussion] OpenCode V2 Plugin Support

[CasualDeveloper]

Hey @makeittech - I opened this to coordinate OpenCode V2 support and avoid duplicating work.

Current Status

I completed a plugin v3 implementation for OpenCode V2 on my fork’s beta branch. The current implementation is in 3af03f6.

It uses a native OpenCode LanguageModelV3 adapter over Cursor AgentService. OpenCode owns transcript reconstruction, credentials, permissions, tool execution, persistence, and compaction. A Cursor Run remains alive only while resolving its exact tool-result loop, then it is discarded.

The native path retains private Composer models, live model and variant discovery, image input, cancellation, parallel tools, tool-error propagation, phase-aware stall watchdogs, bounded worker capacity, usage accounting, OAuth refresh, and HTTP/2 pooling.

npm run verify passes with 36 tests, typecheck, build, packed-package validation, and the OpenCode V2 loader smoke test.

Proposed Release Structure

• main: OpenCode V1 maintenance, plugin v2.x, npm latest.
• beta: OpenCode V2 implementation, plugin 3.0.0-beta.N, npm beta.
• Eventually promote beta to main; preserve OpenCode V1 support through tags or a maintenance branch.

Implementation Scope

The OpenCode V2 branch removes:

• The OpenCode V1 Hooks/plugin-function entrypoint
• config, provider.models, chat.headers, chat.params, and legacy auth hooks
• OpenCode V1 config generation, documentation, compatibility tests, and dependency surface
• The localhost OpenAI/SSE proxy, retained Cursor checkpoints, conversation mutexes, and session-routing headers

It retains and adapts:

• Cursor OAuth and refresh
• Live model discovery and normalization
• AgentService and private-model transport
• Exact model and variant routing
• Ephemeral tool-loop continuity while OpenCode executes tools
• Security, lifecycle, cancellation, capacity, and stall hardening

These pieces are integrated through OpenCode V2’s Plugin.define, ctx.integration, ctx.catalog.transform, ctx.aisdk, and ctx.session APIs.

Next Step

Since upstream currently has no beta branch, I have not opened a PR against main. If you create an upstream beta branch for OpenCode V2, or prefer another integration target, I can open the plugin v3 PR against it.

Relevant OpenCode V2 documentation:

• https://opencode.ai/v2/docs
• https://opencode.ai/v2/docs/providers
• https://opencode.ai/v2/docs/migrate-v1#plugins
• https://opencode.ai/v2/docs/build/plugins

[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.

[makeittech]

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