Web UI: Settings → Providers shows "No connected providers" while the server reports 28 connected

Settings → Providers shows "No connected providers" while the server reports 28

Version: 0.0.0-beta-202608061256
Setup: self-hosted opencode web --hostname 127.0.0.1 --port 4096, reverse-proxied
over a Cloudflare tunnel. Linux x64 (WSL2), Node v24.18.0.

Summary

On a server with 27 authenticated providers and 28 reported as connected, the web
UI's Settings → Providers panel renders the empty state, "No connected providers",
and offers only "Custom provider" under Popular providers. Models remain fully
usable elsewhere — the CLI lists 1,345.

The data reaches the browser. A HAR capture of the page load shows every request
succeeding; nothing 4xx/5xx, nothing blocked, and the payloads contain the providers.

Evidence from the HAR (129 entries, statuses: 127×200, 2×0)

The two zero-status entries are a Cloudflare Access login redirect and a blocked
cloudflareinsights.com beacon — neither is an app API call.

Relevant requests, all 200:

GET /provider                              4679901 B
GET /provider?directory=/opt/AuditPack     4679901 B
GET /global/config                           12410 B
GET /config?directory=/opt/AuditPack         72081 B

Their contents, verified server-side at the same time:

• /provider → { all: 182, connected: 28, default: {…} }, e.g.
  connected: ["deepseek","alibaba","alibaba-coding-plan", …]
• /global/config → the user config, provider = 5 blocks
  (meta, openrouter, tokenrouter, cloudflare-workers-ai, cloudflare)
• auth.json holds 27 providers (api and oauth types)

So the panel has both a server-computed connected list of 28 and a config-derived
provider map, and still renders empty.

Expected

Providers reported by /provider.connected (or those present in the config /
credential store) appear under "Connected providers".

Actual

"No connected providers".

Ruled out

• Server-side config — /config/providers (no params) returns 200 with 28
  providers, 998 KB.
• Reverse proxy / Cloudflare Access — an authenticated request to the public
  hostname returns byte-identical output (998577 B) to localhost.
• Version skew — the served UI bundle and the server binary are the same build.
• Request failures — see the HAR status distribution above.

Secondary, unrelated to the above

GET /config/providers?workspace=… returns 500 for client-input errors, where a
4xx would be correct:

$ curl -s -o /dev/null -w '%{http_code}\n' 'localhost:4096/config/providers?workspace=x'
500     # log: Expected a string starting with "wrk", got "x"
        #      src/server/routes/instance/httpapi/middleware/workspace-routing.ts:169:9
$ curl -s 'localhost:4096/config/providers?workspace=wrk_01ABC…'
Workspace not found: wrk_01ABC…   # also 500

Malformed should be 400, unknown-but-well-formed should be 404. The web UI never
sends this parameter (confirmed in the HAR), so this is not the cause of the panel
being empty — noting it only because it surfaced while investigating.