OpenAI models disappear when OpenCode Zen or Go is connected #52363

Activity

1. github-actions

   assigned

   nexxeln

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

   

   github-actionsBot

   on Sep 30, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • #16927: ChatGPT OAuth models not visible in the model list.
3. wadalin commented on Sep 30, 2026

   

   wadalin

   on Sep 30, 2026

   Author

   More actions

   Additional data point — this is not ChatGPT-plugin-specific:

   After removing the ChatGPT OAuth credential and connecting OpenAI with a plain API key (opencode auth login openai → "Manually enter API Key"), and a full opencode service restart:

   • credential stored: integrationID=openai type=key active=true
   • /api/integration/openai shows the key method + active connection
   • but GET /api/provider still lists only opencode-go and opencode
   • GET /api/provider/openai → still 404 ProviderNotFoundError
   • opencode models | grep ^openai/ → still 0

   So even the plain models.dev-catalog + API-key path fails to add the openai record to provider state on this install. That strengthens the suspicion in the original report: models.dev snapshot provider records aren't materializing in the registry at all (only the console-provided opencode / opencode-go show up), and the ChatGPT plugin's providers.get("openai") guard is just where it becomes user-visible.

   Environment recap: opencode 2.0.20 (latest), no opencode.json anywhere, no env overrides, opencode service restart repeatedly, models.dev reachable (curl HTTP 200).
4. wadalin commented on Sep 30, 2026

   

   wadalin

   on Sep 30, 2026

   Author

   More actions

   Even config-declared providers are affected:

   Created ~/.config/opencode/opencode.json with:

   {
     "$schema": "https://opencode.ai/config.json",
     "providers": { "openai": { "models": { "gpt-5.5": { "name": "GPT-5.5" } } } }
   }

   • opencode debug config shows the document is loaded (and the server logs a config.updated event)
   • but the provider still does not register: /api/provider unchanged, opencode run -m openai/gpt-5.5 ... → Error: Model unavailable: openai/gpt-5.5
   • same for a config model: "openai/gpt-5.5" (falls back to a default model instead)
   • sanity check: -m anthropic/claude-model errors identically (no models.dev providers materialize on this install)

   So on v2.0.20, no provider definition reaches the registry here — not credential-based (OAuth key or API key), not config-declared. Only opencode-go and opencode work, which suggests the channel that provisions console providers succeeds while everything routed through the provider/config transform pipeline is silently dropped. Happy to run one-repro traces (OPENCODE_LOG_LEVEL=DEBUG, fresh run= window grep) on request.
5. wadalin commented on Oct 1, 2026

   

   wadalin

   on Oct 1, 2026

   Author

   More actions

   Another finding that narrows this down: OpenAI works perfectly when it is the only connected provider. Removing both OpenCode Zen and OpenCode Go makes all OpenAI models appear and work. Adding back either Zen or Go makes the OpenAI models disappear again.

   For context, my current OpenCode Zen configuration has “Free models” and “New models” turned off. The only enabled models are glm-5.3-flash and deepseek-v4.1-flash.

   This revises my earlier suspicion: OpenAI provider registration works in isolation. The failure appears to be triggered by coexistence with Zen or Go, rather than by the OpenAI credentials or models.dev catalog alone.
6. wadalin

   changed the title [-]openai: ChatGPT OAuth connects but provider never registers — models not selectable[/-] [+]OpenAI models disappear when OpenCode Zen or Go is connected[/+] on Oct 1, 2026
7. AlexJoaquimPereira commented on Oct 9, 2026

   

   AlexJoaquimPereira

   on Oct 9, 2026

   More actions

   I've been facing the same issue on 1.18.35 too now
8. shadowrootdev commented on Oct 20, 2026

   

   shadowrootdev

   on Oct 20, 2026

   More actions

   Cross-referencing #57458 — we hit the same thing on 2.1.1 and can now reproduce it deterministically, which may help narrow this down.

   The provider registry is populated from a live fetch of https://models.opencode.ai/api.json. With the network to that host blocked, a fresh server reports zero providers:

   HTTPS_PROXY=http://127.0.0.1:9 HTTP_PROXY=http://127.0.0.1:9 opencode serve --port 46003
   opencode api --server http://127.0.0.1:46003 provider.list   # -> {"data":[]}

   The locally cached catalog (models-dev:catalog in the kv table, 231 providers, written by that same service) does not seed the registry, so a failed fetch leaves it empty. On the same install, ANTHROPIC_API_KEY=dummy opencode models | grep -c '^anthropic/' returns 0, while the console-provided opencode-go keeps its 29 models — consistent with "no models.dev provider materializes".

   Also relevant for the if (!item) return bail quoted above: github-copilot has the same shape. Its plugin only calls h.add() when the model sync succeeded, and that sync uses a hard-coded AbortSignal.timeout(5000):

   if (l.models) { h.add({ info: S.provider, models: ..., sourceConnection: l.connection }); return }
   for (let F of S.models.keys()) h.models.update(...)  // else: only rewrites packages, never adds the provider

   The Copilot timeout itself is tracked in #57264, and the same symptom with a Go/Zen credential stored in #55082.
9. neriousy commented on Oct 23, 2026

   

   neriousy

   on Oct 23, 2026

   Member

   More actions

   Preserving the deterministic reproduction from #55516: on v2.0.32, connecting OpenCode Console caused the available OpenAI models to drop from 16 to 0; disconnecting restored all 16 while OAuth remained valid. The report also contains managed-configuration and rollback observations that may help isolate the provider-removal path.
10. neriousy

    marked v2: OpenAI OAuth credential saved but provider never materializes (ProviderNotFoundError) #55516 as a duplicate of this issue on Oct 23, 2026
11. opencodejr commented on Oct 28, 2026

    

    opencodejrBot

    on Oct 28, 2026

    Contributor

    More actions

    Thanks for the detailed report and the follow-up findings. I couldn't reproduce this here: it only happens once an OpenCode Console (Zen) or OpenCode Go account is connected, and this sandbox has no such account. #55516 (closed as a duplicate of this issue) has a clear reproduction on 2.0.32: OpenAI showed 16 models, connecting the Console dropped it to 0, and disconnecting brought them back.

    There is a likely lead in the code, but I haven't confirmed it. OpenCode applies provider.use policies from the config that a Console connection supplies, including any enabled_providers allow-list. A denied provider is removed with only a debug-level log line, which would match the silent ProviderNotFoundError you see.

    If you can, it would help to restart the service with debug logging while Zen/Go is connected. Then check the log for a line saying providers denied by policy and post what it lists. A maintainer with a Console account will need to take it from there.

    Related:

    • v2: OpenAI OAuth credential saved but provider never materializes (ProviderNotFoundError) #55516: same problem, reproduced on 2.0.32, with a regression window of 2.0.23 → 2.0.26
    • providers: connected catalog providers stay inactive, only Console providers resolve #54064: same pattern with Poe/DeepSeek while opencode/opencode-go are connected
    • core: all models.dev providers disappear when the catalog fetch fails #57458: all providers missing when the models.dev fetch fails (different trigger)
12. opencodejr

    added

    severity:high

    on Oct 28, 2026
13. wadalin commented on Oct 30, 2026

    

    wadalin

    on Oct 30, 2026

    Author

    More actions

    Quick update: I can't reproduce this on 2.2.4 anymore. Same OpenAI OAuth credential and Console workspace, and openai is back in /api/provider with 19 models. /api/provider/openai returns 200 and points at the Codex backend, so the plugin transform is running.

    I also did a quick isolated 2.0.20 vs 2.2.4 comparison with models.dev blocked. On 2.0.20 the provider list comes up empty at startup and the app keeps showing it empty. On 2.2.4 the full list is there immediately. Looks like the startup race is gone.

    Unless someone still hits this on 2.2.x, I think it can be closed as fixed.
14. deltacat commented on Nov 1, 2026

    

    deltacat

    on Nov 1, 2026

    More actions

    17. Quick update: I can't reproduce this on 2.2.4 anymore. Same OpenAI OAuth credential and Console workspace, and openai is back in /api/provider with 19 models. /api/provider/openai returns 200 and points at the Codex backend, so the plugin transform is running.
    I also did a quick isolated 2.0.20 vs 2.2.4 comparison with models.dev blocked. On 2.0.20 the provider list comes up empty at startup and the app keeps showing it empty. On 2.2.4 the full list is there immediately. Looks like the startup race is gone.
    Unless someone still hits this on 2.2.x, I think it can be closed as fixed.

    2.2.5, same problem. see #60997
15. AlexJoaquimPereira commented on Nov 11, 2026

    

    AlexJoaquimPereira

    on Nov 11, 2026

    Last edited by AlexJoaquimPereira

    More actions

    It happened again on 2.2.7 for me #63296. provider.use shows "resource": "*", "effect": "deny" too as attached from opencode debug config:

    [
      {
        "type": "document",
        "info": {
          "policies": [
            {
              "action": "provider.use",
              "resource": "*",
              "effect": "deny"
            },
            {
              "action": "provider.use",
              "resource": "console-deepseek",
              "effect": "allow"
            },
            {
              "action": "provider.use",
              "resource": "opencode",
              "effect": "allow"
            },
            {
              "action": "provider.use",
              "resource": "opencode-go",
              "effect": "allow"
            }
          ],
    ...
    

    Short-term solutions are:

    1. Connect the other providers through OpenCode Console BYOK (Console -> Providers). I connected my DeepSeek API as shown above.
    2. Add the following code in opencode.jsonc (global/local):

    "policies": [
      {
        "action": "provider.use",
        "resource": "*", // can replace * with the exact provider slug for granular control
        "effect": "allow"
      },
    ],