v2: no credential path for custom provider IDs breaks adding custom providers from GUI clients #51527

Activity

1. github-actions

   assigned

   nexxeln

   on Sep 26, 2026
2. github-actions commented on Sep 26, 2026

   

   github-actionsBot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • V2 Unable to use /connect for custom providers #40752: reports that v2 /connect cannot find configured custom providers, preventing users from entering their API keys.
   • desktop: custom provider save always throws "unavailable on this server" #50650: reports that the Desktop custom-provider form cannot save/connect on the bundled server.
3. keponk commented on Oct 21, 2026

   

   keponk

   on Oct 21, 2026

   More actions

   @chenyuhao0628 did you find a workaround? my custom provider works great on cli, but there's no way to access it via desktop. I keep getting:

   "error": {
       "type": "provider.error",
       "message": "Unauthorized: Unauthorized"
     }
   
4. chenyuhao0628 commented on Oct 21, 2026

   

   chenyuhao0628

   on Oct 21, 2026

   Author

   More actions

   @chenyuhao0628 did you find a workaround? my custom provider works great on cli, but there's no way to access it via desktop. I keep getting:

   "error": {
       "type": "provider.error",
       "message": "Unauthorized: Unauthorized"
     }
   

   You could try having the AI directly help you modify the configuration sheet and just use another AI to do the configuration - that's one way
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed write-up, @chenyuhao0628.

   On v2 (dev), custom providers can already get credentials through the integration API, but only after the provider is in config:

   • packages/core/src/config/plugin/provider.ts registers a key method ("Manually enter API Key") for every provider under providers.<id>. It also adds an env method when env is set.
   • So the working order is: write the provider to config first, then, once the config has reloaded, call integration.connect.key with that ID.
   • Integration not found: <id> is what the server returns for an ID that isn't registered yet. That fits a client sending the key before the provider exists in config.

   Your actual request is something different: let integration.connect.key accept any provider ID and store a credential before any config exists, or at least document the config-then-key order for third-party clients. I've recorded this as a feature request for maintainers to consider.

   About the desktop part: the files you mention (packages/opencode/src/.../control.ts with auth.set, and packages/app/src/components/dialog-custom-provider.tsx) are v1 code, and stable desktop 1.2.x is v1. v1 only gets critical fixes. If adding custom providers fails on v2 even with the provider already in config, please reply with the version and the steps, and we'll look at it as a bug.