providers: connected catalog providers stay inactive, only Console providers resolve #54064

Summary

Connected third-party providers (Poe via OAuth, DeepSeek/LongCat/Xiaomi via API key) stay inactive: their credentials are stored, but none of their models appear in /models, Desktop, opencode models, and any run --model <provider>/<model> fails with Model unavailable. Only Console-managed providers (opencode, opencode-go) resolve.

Environment

• opencode version: v2.0.26 (CLI and background service, previously 2.0.20/2.0.23 — same symptom)
• OS: Microsoft Windows NT 10.0.26200.0 (Win32NT)
• Terminal: TERM_PROGRAM=Orca, TERM=xterm-256color, COLORTERM=truecolor
• Shell: C:\Windows\system32\cmd.exe (interactive shells: pwsh)
• Install/channel: release, latest
• Active plugins: oh-my-openagent (cli.json); MCP servers memory, codegraph (local, global opencode.json). No provider-disabling plugins.

Reproduction

1. TUI: run /connect, select Poe, complete OAuth (browser shows success page).
2. TUI /connect again: Poe shows ✓ with saved account. opencode auth list shows Poe / Poe / stored.
3. Run /models (or open Desktop Settings → 模型, or opencode models): only opencode/* and opencode-go/* models listed (~50). No poe/* entries.
4. Run opencode run --model poe/<any-model> 'hi' (also tried deepseek/deepseek-chat, a static catalog model): fails immediately with Error: Model unavailable: poe/<model>.
5. Repeat after opencode service restart, CLI upgrade to match service version, opencode auth switch <integration> 'API key', account delete + fresh OAuth re-login, and a project-level providers: { "deepseek": {} } override (verified loaded via debug config + reload): symptom unchanged.

Expected Behavior

A provider with a stored, active credential should be usable: its catalog models listed in /models and selectable for sessions/runs (per Providers docs: "connect an account first, then select a model").

Actual Behavior

Provider stays inactive despite stored credential. Affects every non-Console provider tested: poe (OAuth, active=1), deepseek / longcat / xiaomi-token-plan-cn (API-key accounts; LONGCAT_API_KEY also present in environment). opencode (Console kon credential) and opencode-go (API key) work fine.

Additional Context

• Consistently reproducible, including after full service restart (which also auto-updated service 2.0.23 → 2.0.26) and fresh OAuth credentials.
• No workspace attached (workspace table empty, location events show workspaceID=undefined); no experimental.policies in any config layer; no policy entries in server KV store. So not a provider.use deny.
• models.dev catalog cache in server DB contains all 225 providers, including poe (137 models, @ai-sdk/openai-compatible, https://api.poe.com/v1), deepseek (4 models), longcat, xiaomi-token-plan-cn. Same npm runtime package as the working Console providers.
• Stored credentials verified present and well-formed (typed objects, non-empty) via DB inspection of backup copy and auth export (values not pasted here).
• Global config contains "providers": { "opencode": {}, "opencode-go": {} } (empty overrides) — project-level override test rules out allowlist semantics.
• Server log shows no provider errors around credential creation, model listing, or boot; only recurring $.model normalization warning (global config has "model": "", skipped as malformed) and intermittent Failed to fetch models.dev / failed to load OpenCode provider config transport errors (network is flaky, but static catalog models should not need network; api.poe.com reachable with 403 on base path, api.deepseek.com times out from this machine).
• auth list hides one legacy credential (mint, not in current catalog — likely V1 leftover), suggesting the old API-key rows may date from V1→V2 migration; but Poe OAuth was created fresh on V2 and fails identically.
• Screenshots: OAuth success page, Providers page (only Go/Console), Models page (only Go/Console), TUI /connect (Poe ✓), TUI /models (only OpenCode entries).