You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
doesnt seem to work in opencode 1.18.3, models dont show up in provider list #30
I hit the same issue on opencode 1.18.0 with plugin 0.0.9 and tracked down the root cause.
Diagnosis
The plugin populates models via a side effect inside the auth.loader hook (dist/index.js:54 — provider.models = buildCursorProviderModels(...)). That pattern worked on opencode 1.14.x, but opencode 1.18 split model registration into a separate provider hook on the v2 catalog. From @opencode-ai/plugin/dist/index.d.ts:167-170 (bundled in the plugin's own node_modules):
The plugin only exports auth, never provider, so opencode's v2 catalog shows the cursor provider with an empty models field and opencode models / /models show nothing.
Evidence
opencode debug v2 → cursor provider registered with api.type: "native", empty settings, no models
opencode providers list → cursor oauth credential present
opencode models cursor → Error: Provider not found: cursor
Running getCursorModels(token) directly in Bun (same runtime opencode uses) returns 117 models including composer-2.5-fast — discovery + auth are fine; the catalog just never sees them
opencode debug config shows the provider.cursor stub is parsed correctly; plugin origin resolves to ~/.cache/opencode/packages/opencode-cursor-oauth
Suggested fix
Return a provider hook alongside auth from CursorAuthPlugin, e.g.:
This duplicates the auth-loader logic — the existing loader could probably be refactored to share a getModelsAndPort(auth) helper so both auth.loader and provider.models use the same code path.
Reproduced on: opencode 1.18.0, opencode-cursor-oauth 0.0.9, macOS.
Root cause was exactly what @kipyin diagnosed: opencode 1.18 builds its v2 provider catalog before auth loaders run, and auth.loader only receives a deep copy of the provider — so the provider.models = ... mutation never reached the catalog.
The plugin now registers models through two paths:
a config hook that injects the cursor provider and the discovered model list into the config before the catalog is built (works even though cursor is not in models.dev, which would have made the provider hook alone a no-op — the hook loop skips providers missing from the catalog database)
a provider hook as suggested, for catalogs that already know the provider
Bonus: the manual provider.cursor stub in opencode.json is no longer required — the plugin registers it automatically.
Verified on opencode 1.18.9: opencode models cursor lists all discovered models and completions run end to end.
fwiw I did have to manually delete everything from ~/.cache/opencode/packages/opencode-cursor* because there were now two separate entries in there and opencode would crash on open.
Activity
kipyin commentedon Jul 20, 2026
I hit the same issue on opencode 1.18.0 with plugin 0.0.9 and tracked down the root cause.
Diagnosis
The plugin populates models via a side effect inside the
auth.loaderhook (dist/index.js:54—provider.models = buildCursorProviderModels(...)). That pattern worked on opencode 1.14.x, but opencode 1.18 split model registration into a separateproviderhook on the v2 catalog. From@opencode-ai/plugin/dist/index.d.ts:167-170(bundled in the plugin's ownnode_modules):The plugin only exports
auth, neverprovider, so opencode's v2 catalog shows thecursorprovider with an emptymodelsfield andopencode models//modelsshow nothing.Evidence
opencode debug v2→cursorprovider registered withapi.type: "native", emptysettings, nomodelsopencode providers list→cursoroauth credential presentopencode models cursor→Error: Provider not found: cursorgetCursorModels(token)directly in Bun (same runtime opencode uses) returns 117 models includingcomposer-2.5-fast— discovery + auth are fine; the catalog just never sees themopencode debug configshows theprovider.cursorstub is parsed correctly; plugin origin resolves to~/.cache/opencode/packages/opencode-cursor-oauthSuggested fix
Return a
providerhook alongsideauthfromCursorAuthPlugin, e.g.:This duplicates the auth-loader logic — the existing loader could probably be refactored to share a
getModelsAndPort(auth)helper so bothauth.loaderandprovider.modelsuse the same code path.Reproduced on: opencode 1.18.0, opencode-cursor-oauth 0.0.9, macOS.
fix(provider): allow provider hook for non-catalog providers
fix: register cursor provider and models on opencode 1.18+ (#30)
ephraimduncan commentedon Jul 29, 2026
Fixed in 3396152 (v0.1.0).
Root cause was exactly what @kipyin diagnosed: opencode 1.18 builds its v2 provider catalog before auth loaders run, and
auth.loaderonly receives a deep copy of the provider — so theprovider.models = ...mutation never reached the catalog.The plugin now registers models through two paths:
confighook that injects thecursorprovider and the discovered model list into the config before the catalog is built (works even thoughcursoris not in models.dev, which would have made theproviderhook alone a no-op — the hook loop skips providers missing from the catalog database)providerhook as suggested, for catalogs that already know the providerBonus: the manual
provider.cursorstub in opencode.json is no longer required — the plugin registers it automatically.Verified on opencode 1.18.9:
opencode models cursorlists all discovered models and completions run end to end.joepetrakovich commentedon Jul 30, 2026
thank you!
fwiw I did have to manually delete everything from ~/.cache/opencode/packages/opencode-cursor* because there were now two separate entries in there and opencode would crash on open.