Repository navigation
desktop: custom-provider dialog writes V1 provider keys that the V2 server ignores - toast says provider not available on this server #58533
Description
Summary
The OpenCode Desktop 2.1.4 "add custom provider" dialog persists the provider in the V1 config shape (provider, npm, options) into ~/.config/opencode/opencode.jsonc, but the V2 server does not understand those keys. Selecting a model from the newly added provider then fails with a toast ("provider not available on this server"), and requests fail server-side with AI.Error: Invalid API key / Missing ClientApiKey.
Environment
- opencode version: 2.1.4 (OpenCode Desktop, latest channel)
- OS: Windows 11 (Windows_NT 10.0.26300, win32 x64)
- Install/channel: desktop installer, latest channel
- Active plugins: none found in config
Reproduction
- Open the providers page → add a new custom provider via the dialog (name/ID, base URL of an OpenAI-compatible endpoint, models, headers, API key).
- Save ("إرسal" / submit).
- Try to select one of its models / send a message.
- Failure toast appears; the model is not usable.
Expected Behavior
Either the dialog writes V2 keys (providers with package: "@opencode/ai/providers/openai-compatible" and settings.baseURL) so the V2 server loads the provider immediately, or there is a server API the dialog actually uses to persist config.
Actual Behavior
The dialog writes the retired V1 keys. The running V2 server ignores them, so the provider never appears on /api/provider and model selection fails with "provider not available on this server".
Additional Context
- Confirmed by manual fix: rewriting the same provider in the file to the V2 shape —
providers.<id>withpackage,settings.baseURL,models— makes it load instantly on the same running server (verified viaGET /api/provider). So the failure is purely the obsolete keys written by the dialog. - Observations on the server API in 2.1.4:
GET /api/configis read-only;PATCH /api/experimental/configaccepts only{ "shell": ... }(Config.Patch,additionalProperties: false) — i.e. there is currently no server endpoint for persisting provider config, so the dialog appears to write the config file itself, in the V1 shape. - The provider connection step (API key) also feels disconnected from the provider the dialog creates, which makes it hard to tell whether the failure is auth-related or config-related. Consider unifying both flows.
- File-watcher
provider.updatedevents do fire after the dialog save, so hot-reload works — the config shape is the problem.
Activity
opencode-agent commentedon Oct 23, 2026
Thanks for the detailed report! I think this is a duplicate of #50650.
In 2.1.4, the save handler in the desktop custom-provider dialog (
packages/app/src/providers/credentials/dialog.tsx) is still a stub. It always throwsprovider.custom.unavailable("Custom providers are unavailable on this server") and doesn't write anything toopencode.jsonc. So the V1-shapedprovider/npm/optionsblock in your config most likely came from somewhere else, such as an older v1 setup or a manual edit. The toast you saw comes from the stubbed save, which #50650 tracks. Open PR #57997 would make the dialog write a V2providers.<id>entry (package: "@opencode/ai/providers/openai-compatible",settings.baseURL,models) and store the API key through the credential API.Until that lands, the workaround you found works: write the provider in the V2 shape yourself.
Possible duplicates and related issues, ordered by likelihood:
/modelsdialogThe bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different, for example if you can show that the dialog itself wrote those V1 keys.
opencode-agent commentedon Oct 24, 2026
We haven't heard back since the duplicate notice, so I'm closing this as a duplicate of #50650. In 2.1.4 the desktop custom-provider save always fails with "Custom providers are unavailable on this server", and #50650 tracks that. Open PR #57997 would make the dialog save the provider in the V2
providers.<id>format. Until it lands, your workaround of writing the provider into the config file in the V2 shape still works.If your problem turns out to be different, for example if you can show the dialog itself wrote those V1 keys, please reply here with the details and we can reopen it. Thanks for the thorough report!