Skip to content

Wire the in-session provider connect flow to actually connect - #397

Merged
TheGreatAxios merged 1 commit into
mainfrom
cl-5602-adding-new-models-doesnt-work
Aug 8, 2026
Merged

Wire the in-session provider connect flow to actually connect#397
TheGreatAxios merged 1 commit into
mainfrom
cl-5602-adding-new-models-doesnt-work

Conversation

@TheGreatAxios

Copy link
Copy Markdown
Collaborator

Summary

  • onConnectProvider in the running TUI was a stub that told the operator to restart or reconnect via onboarding
  • Now runs the existing inline connect flow, rebuilds the provider catalog from disk plus Codex/xAI credential stores, and pushes it into the mounted host so new providers/models are usable without a restart
  • Fixes OAuth "connect" rows to prefix-match per-account provider names (codex/<profile>, xai/<profile>) instead of exact-id matching, so a signed-in account correctly clears the row

Test plan

  • `bun run typecheck`
  • `bun run build`
  • `bun run test` (4152 pass, 0 fail)

Selecting "connect" for an unauthorized provider from the running TUI
used to be a stub that told the operator to restart or reconnect via
onboarding. It now runs the existing inline OAuth/API-key connect
flow, rebuilds the provider catalog from disk plus the Codex/xAI
credential stores, and pushes it into the mounted host so the new
provider's models are selectable without a restart.

OAuth choices are also matched more precisely: a signed-in Codex/xAI
account lands in the catalog as a per-account provider name, so
"connect" rows need prefix matching, not exact-id matching, to clear
after a successful login.
@linear-code

linear-code Bot commented Aug 8, 2026

Copy link
Copy Markdown

CL-5602

@TheGreatAxios
TheGreatAxios merged commit c33d528 into main Aug 8, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant