Repository navigation
app: custom provider dialog always fails with "Custom providers are unavailable on this server" #53843
Description
Description
On 2.0.24 desktop (bundled local V2 service), Settings → Providers → "Custom Provider" opens a form that always fails on submit with Custom providers are unavailable on this server (i18n key provider.custom.unavailable, zh: 此服务器上无法使用自定义提供商). It fails the same way regardless of server: in the web bundle shipped with the 2.0.24 service, the form's submit handler is an unconditional stub:
mutationFn: async (e) => { throw Error(t("provider.custom.unavailable")) }The bundled 2.0.24 server has no API to create providers either (/api/provider is GET-only), so nothing can succeed from this dialog. The message reads like a server-side restriction, but the server is the app's own bundled local service, and defining the same provider in opencode.jsonc works fine — which makes the error misleading to debug.
On dev, packages/app/src/components/dialog-custom-provider.tsx has the real implementation, but it is gated to v1 servers (#38651: if ((await serverSDK().protocol) !== "v1") throw new Error(...)) and the settings row is hidden for non-v1 servers (settings-v2/providers.tsx wraps it in <Show when={protocol() === "v1"}>). The stable 2.0.24 build has none of that: the entry is still shown and submit is still the unconditional stub, so V2 users get a dead-end dialog.
Suggestion: hide or disable the "Custom Provider" entry when it can't work (with a pointer to the provider config docs), and/or make the form work on the V2 server.
Plugins
None.
OpenCode version
2.0.24 (desktop app, latest channel; bundled local service also 2.0.24)
Steps to reproduce
- Start the desktop app on 2.0.24 with its bundled local service (V2 protocol).
- Open Settings → Providers; the "Custom Provider" row is listed.
- Click Connect, fill in provider ID, display name, base URL, API key, and at least one model.
- Submit → error toast "Custom providers are unavailable on this server"; no config is written.
Screenshot and/or share link
None — can add if useful.
Operating System
Windows 10 (10.0.19045)
Terminal
Desktop app (Electron) — n/a
Activity
opencode-agent commentedon Oct 8, 2026
Thanks for the detailed report and for tracing it to the submit stub in the 2.0.24 bundle.
I think this is a duplicate of #50650, which reports the same problem: the Custom Provider form's submit handler always throws
provider.custom.unavailable, even against the app's own bundled server.Possible duplicates and related issues, ordered from most to least likely:
provider.custom.unavailablestub in the desktop custom provider dialog (2.0.14; comments confirm it on later versions)As you found, defining the provider in
opencode.jsoncworks in the meantime. Confirming that it still happens on 2.0.24, plus your suggestion to hide or disable the entry with a link to the config docs, would be useful as a comment on #50650.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
opencode-agent commentedon Oct 9, 2026
Closing this as a duplicate of #50650, as mentioned yesterday. It reports the same problem: the Custom Provider dialog's submit always fails with
provider.custom.unavailable, even on the app's bundled local server.If you'd like, add a comment on #50650 saying it still happens on 2.0.24, along with your suggestion to hide or disable the entry and link to the provider config docs. Until it's fixed, defining the provider in
opencode.jsoncworks. Thanks for the detailed report! If your problem turns out to be different, reply here and we can reopen this issue.