[quickbeard]

Issue for this PR

Closes #

Type of change

• Bug fix

What does this PR do?

Fixes the reported loop where a user signs in, sees the "CoDev configured — Using …" toast, and the Set up CoDev dialog immediately comes back — every time, surviving restarts, until codevhub config "fixes" it.

Root cause. "Disconnect provider" in Settings → Providers writes the provider id into the global config's disabled_providers (settings-v2/providers.tsx). A disabled provider is skipped everywhere in the server's provider registry build, so it can never appear in connected — and the configure gate opens exactly when nothing is connected. The SSO configure flow rewrote the auth entry and the provider block on every sign-in but never cleared the flag, so each attempt genuinely succeeded (hence the toast) while changing nothing the gate could see. The dialog reopened over its own success toast, forever.

Why the hinted PRs (#285 here, codev-hub#257) are adjacent but not the cause: they moved the key out of codev.json, which is what put users in front of dead keys and the Disconnect button in the first place — but the loop itself is the stale disabled_providers entry. And why codevhub config fixed it: the hub rewrites codev.jsonc wholesale (preserving only mcp), which drops disabled_providers as a side effect.

Reproduced against a live server (fork server, scratch HOME, the exact three calls the renderer makes):

connected after disconnect:  ['opencode']            # free tier, filtered by the gate
connected after configure:   ['opencode']            # auth.set + config PATCH + dispose — still dead
connected after clearing:    ['netgate', 'opencode'] # disabled_providers cleared — fixed

Fix. The app's custom-provider dialog already filtered its id back out of disabled_providers on save (dialog-custom-provider.tsx) — the three flows that missed the same guard now do it too:

• packages/app/src/components/gateway/dialog-configure.tsx — desktop SSO / manual-key flow
• packages/tui/src/component/dialog-configure.tsx — TUI gateway flow (also codev configure)
• packages/tui/src/component/dialog-custom-provider.tsx — TUI custom-provider flow

Each clears only its own provider id, so other providers the user disconnected on purpose stay disconnected. Both config-file branches (.json mergeDeep, .jsonc patch) replace arrays, verified live. enabled_providers (admin allowlist) is deliberately left alone. All three touched source files are fork-only, so no DIVERGENCES.md rows change; CHANGELOG.md gets an entry.

How did you verify your code works?

• Live-server reproduction above, before and after.
• New TUI view test drives the real custom-provider flow against a config seeded with disabled_providers: ["mockgw", "othergw"] and asserts the PATCH carries ["othergw"] — verified it fails without the fix (5 pass / 1 fail) and passes with it.
• bun typecheck clean in packages/app and packages/tui; app suite 708 pass, TUI configure-gate + custom-provider suites green. One unrelated flake in the full TUI run (configure-gate.view.test.tsx frame-wait timeout under parallel load) passes in isolation both with and without this change.
• The desktop dialog path has no render harness (known limitation, see the gateway key recovery row in DIVERGENCES.md); its change is the same three lines as the tested TUI flows, and the server-side effect is covered by the live repro.

Screenshots / recordings

N/A — behavior fix; the visible change is the setup dialog staying closed after sign-in.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

🤖 Generated with Claude Code