desktop: custom provider form always fails with "Custom providers are unavailable on this server" #52438

Summary

The Custom provider dialog in the desktop app cannot save any provider. The form renders correctly and all validation works, but submitting always fails with the message "Custom providers are unavailable on this server". The submit handler is a stub that throws unconditionally, so the feature is completely non-functional rather than conditionally unavailable.

Environment

• opencode version: 2.0.21 (desktop app and bundled CLI, both 2.0.21)
• OS: Windows_NT 10.0.26200.9550 (win32 x64)
• Terminal: Not applicable — reproduced in the OpenCode desktop app (Electron), not the TUI. The spawning shell reported TERM=xterm-256color, ComSpec=C:\WINDOWS\system32\cmd.exe.
• Shell: C:\WINDOWS\system32\cmd.exe
• Install/channel: latest release (auto-updater reported latest version: 2.0.21, allowPrerelease: false) — no newer version available to compare against
• Active plugins: none found in config (no plugins key; no ~/.config/opencode/plugin/ or plugins/ directory)

Reproduction

1. Launch the OpenCode desktop app (2.0.21) and let the background service start.
2. Open the provider/model selector and choose the Custom OpenAI-compatible provider entry.
3. Fill in Provider ID, Display name, Base URL, at least one model ID/name, and optionally an API key and headers.
4. Click the save/confirm button.

The form is fully interactive and validation passes. Submission then fails every time, for every input, with the "unavailable" notice.

Expected Behavior

The provider is written to configuration and becomes selectable in the model list, consistent with the documented custom-provider recipe in the V2 provider docs.

Actual Behavior

Submission always fails with: "Custom providers are unavailable on this server" (i18n key provider.custom.unavailable).

The cause is visible in the packaged renderer bundle. The form component builds and validates a complete provider config, but its mutation function is an unimplemented stub that throws:

// out/renderer/assets/... (imports main-BWAE7f7e.js)
mutationFn: async e => {
  throw Error(r.t(`provider.custom.unavailable`))
},
onSuccess: e => { /* toast */ },
onError: e => { /* toast */ }

Notably, the surrounding code is complete and correct — it constructs exactly the shape the docs specify:

config: {
  npm: '@ai-sdk/openai-compatible',
  name: n,
  ...a ? { env: [a] } : {},
  options: { baseURL: r, ...(headers ? { headers } : {}) },
  models: h,
}

This strongly suggests the feature was built and the persistence call was never wired up before shipping, rather than the feature being intentionally disabled.

Additional Context

• 100% reproducible, not intermittent. Every attempt fails, regardless of provider ID, base URL, or model list contents.
• No server-side errors. ~/.local/share/opencode/log/opencode.log and the desktop main.log / renderer.log contain no provider or config errors. The failure occurs entirely in the renderer process before any request is made, so logs give no hint that a feature is broken.
• Server capabilities are not the issue. The bundled CLI is the same version as the app (2.0.21) and the service is healthy. Manually writing an equivalent provider into ~/.config/opencode/opencode.json is picked up immediately by the running server and the models work end-to-end, which confirms the backend fully supports custom providers and that only the desktop UI path is broken.
• Workaround: define custom providers in opencode.json (e.g. providers.<id> with package, settings.baseURL, and models) instead of using the dialog. The server hot-reloads the file, so no restart is needed. This works, but it is not a discoverable path for users who expect the dialog to function.
• Related surface: the dialog.provider.custom.label entry ("Custom OpenAI-compatible provider") is still shown in the provider list, so the app advertises a feature that cannot be completed.
• Possible secondary issue (lower confidence, may be by design): the dialog's help link points at https://opencode.ai/docs/providers/#custom-provider, which is the V1 docs path. The V2 equivalent is https://opencode.ai/v2/docs/providers#custom.

Nothing about this issue depends on a specific provider, key, or account; it reproduces with any values.