Validate a provider credential before onboarding reports it configured

An empty API key on a key-required preset was written as keyless:
true, and resolveProvider skips the missing-key check entirely once
keyless is set, so a config that should have failed validation loaded
as configured and only broke on the first real send. The submit
funnel now rejects an empty key on any preset that isn't genuinely
keyless-capable (the custom/manual endpoint), instead of downgrading
it.

The "save anyway" escape hatch had the same failure shape one step
further along: a credential that failed its connection test still
got persisted, indistinguishable from a verified one. It's now marked
verified: false, and the running session surfaces a plain-language
startup notice instead of letting the first send fail with a raw
adapter error.

Both bugs existed twice over: first-run onboarding and the mid-session
"connect a new provider" flow each reimplemented the same submit
logic, so a fix to one alone would have left the other silently
broken. The submit logic moves into its own module and both callers
now share it.

verified defaults to trusted (absent, not false) so this doesn't
retroactively flag every existing user's already-working setup; only
a path that persists a credential without testing it sets it false.
The OAuth submit path is exempt from the same marking on purpose — a
completed OAuth login is a stronger signal than a pasted key (the
provider's own server just issued it), though it doesn't confirm the
resulting token carries API scope, which is tracked as a separate
follow-up rather than faked here.

Author: TheGreatAxios

src/config/settings.ts

@@ -47,6 +47,12 @@ export type ProviderSettings = {
   // test (e.g. the onboarding "save anyway" bypass). Absent/true means either
   // the test passed or the provider is exempt from it by design. Read once at
   // startup to warn the operator instead of surfacing a raw auth error.
+  //
+  // Deliberately defaults to trusted: this field did not exist before it was
+  // introduced, so every provider in an existing settings.json has no value
+  // for it, and that must not retroactively flag every current user's
+  // already-working setup as unverified. Only paths that persist a
+  // credential without testing it write `false` explicitly.
   verified?: boolean;
 };
 

src/tui-opentui/provider-setup.test.ts

@@ -271,6 +271,19 @@ async function mountLogin(opts: {
   return { done, harness }
 }
 
+describe("runProviderSetup renderer ownership", () => {
+  test("does not destroy a caller-supplied renderer on cancel", async () => {
+    const { done, harness } = await mountSetup()
+    harness.pressKey("Ctrl+C")
+    expect(await done).toBe(false)
+
+    // A caller-owned renderer must still be usable for whatever mounted it
+    // in the first place (a live session resuming its own UI after a
+    // mid-session reconnect), not torn down out from under it.
+    expect(harness.renderer.isDestroyed).toBe(false)
+  })
+})
+
 describe("runProviderSetup sign-in", () => {
   test("a subscription provider signs in in place and persists the selection", async () => {
     const seen: ProviderFormValues[] = []

src/tui-opentui/provider-setup.ts

@@ -605,6 +605,10 @@ const RAMP_TICK_MS = 120
 export async function runProviderSetup(
   config: ProviderSetupConfig,
 ): Promise<boolean> {
+  // A caller-supplied renderer (a headless test harness, or a live session's
+  // renderer reused for a mid-session reconnect) is owned by that caller —
+  // teardown here must not destroy it out from under them.
+  const externalRenderer = config.createRenderer !== undefined
   const renderer = config.createRenderer
     ? await config.createRenderer()
     : await createCliRenderer({
@@ -1075,10 +1079,12 @@ export async function runProviderSetup(
     } catch {
       // already unmounted
     }
-    try {
-      renderer.destroy()
-    } catch {
-      // already destroyed
+    if (!externalRenderer) {
+      try {
+        renderer.destroy()
+      } catch {
+        // already destroyed
+      }
     }
   }
 

src/tui/provider-setup-submit.ts

@@ -29,6 +29,15 @@ export function buildProviderSubmitHandler(
     // tokens are already in the home-level auth store, and config load
     // projects that store into the provider catalog. Only the selection is
     // persisted here — the same two files /model writes when switching.
+    //
+    // Unlike a pasted key, this credential was just issued by the real
+    // provider's own OAuth server completing a PKCE round-trip, so the
+    // "unverified" concept the API-key path uses doesn't apply the same way
+    // — there is no separate probe step to skip. What a completed login
+    // does not confirm is that the resulting token actually carries API
+    // scope (vs. e.g. a chat-only subscription), which can still surface as
+    // a first-send auth error; tracked separately rather than faked here
+    // with a flag this path has no real signal for.
     if (oauth !== undefined) {
       setPhase("saving");
       const base = existing ?? { providers: {} };

src/tui/runner.ts

@@ -442,7 +442,7 @@ export async function runTUI(initialConfig: Config): Promise<number> {
   // connection test — warn now instead of a bare adapter error on first send.
   if (config.verified === false) {
     startupPluginNotices.push(
-      `Provider "${config.providerName}" was saved without a passing connection test. If the first message fails with an auth error, run onboarding again to reconnect it.`,
+      `We couldn't confirm your "${config.providerName}" key works. If your first message fails with an auth error, double-check the key.`,
     );
   }
   // Mutable list so trusting a project/path plugin can replace a metadata-only stub