fix(auth): never roll back OAuth credentials on failed post-login model refresh

[flora131]

Summary

Restores upstream pi's invariant that a completed OAuth login can never be undone by the model-catalog refresh that follows it. This fixes a Linux-reported trap where /login always failed with Model refresh aborted after OAuth login and every send then failed with invalid_grant ("Refresh token not found or invalid").

Root cause

After a successful OAuth login, Atomic ran a full catalog refresh (hard 15 s timeout) and treated an aborted or partially failed result as a login failure, rolling the freshly persisted tokens back to the previous credential (rpc-provider-auth.ts:persistOAuthAndRefresh) or throwing after commit (interactive-auth-login.ts:completeProviderAuthentication). Providers rotate refresh tokens, so the rollback could re-install a server-side-invalidated credential — a permanent invalid_grant that no re-login could escape, since each re-login was rolled back the same way. Any machine with a slow route to catalog endpoints (e.g. pi.dev) hit this deterministically. Upstream pi ignores the refresh outcome after login (ModelRuntime.login), so it cannot enter this state.

Changes

• rpc-provider-auth.ts: persist the credential, run the post-login refresh best-effort, drop the rollback and the aborted/per-provider-error classification. A thrown refresh still propagates but no longer unpersists tokens.
• interactive-auth-login.ts: drop the provider-error and refresh-aborted throws after a completed login; models fall back to the cached snapshot.
• Regression tests updated in rpc-oauth-login.test.ts and interactive-auth-login.test.ts: credentials survive provider-error, thrown, and aborted refreshes; added an aborted-refresh interactive case.
• Changelog entry under [Unreleased].

Notes

• Verified with bun run typecheck, bun run lint, bun run check:file-length, and bunx vitest --run test/rpc-oauth-login.test.ts test/interactive-auth-login.test.ts (21/21 pass).
• Not addressed here (possible follow-up): failed catalog fetches never set lastModified, so they bypass the 4-hour revalidation window and retry on every refresh — identical to upstream, but it keeps /model slow on machines with unreachable catalog endpoints.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

Greptile Summary

This PR preserves newly acquired OAuth credentials when the post-login model-catalog refresh fails.

• Treats returned provider errors and aborted refresh results as non-fatal in interactive and RPC login flows.
• Removes credential rollback after the RPC credential commit.
• Updates regression coverage for provider-error, thrown-error, and aborted-refresh outcomes.
• Documents the behavior change in the coding-agent changelog.

Confidence Score: 3/5

This PR should not merge until RPC cancellation during the post-commit refresh is distinguished from a successful login without rolling back the rotated credential.

An abort during model refresh resolves as an aborted result, but the changed RPC path ignores that result and returns cancelled false, allowing one login request to produce both a successful cancellation acknowledgment and a successful login response.

Files Needing Attention: packages/coding-agent/src/modes/rpc/rpc-provider-auth.ts

T-Rex Logs

What T-Rex did

• Verified the cancellation flow by executing the real RPC command with the OAuth harness, pausing ModelRegistry.refresh after credential persistence, and confirming cancel_login_provider returned success before the refresh aborted, while the correlated login_provider response showed success with cancelled: false and the OAuth credential remained stored.
• Observed the test run completed with exit code 0, duration 5.918s, and all Vitest tests passing (2/2 files, 21/21 tests) according to the run log, with no additional setups or services started.

_{Ran code and verified through T-Rex}

Important Files Changed

Filename	Overview
packages/coding-agent/src/modes/rpc/rpc-provider-auth.ts	Preserves committed OAuth credentials across refresh failures, but now reports success when cancellation arrives during the post-commit refresh.
packages/coding-agent/src/modes/interactive/interactive-auth-login.ts	Makes returned provider errors and aborted refresh results non-fatal after interactive authentication.
packages/coding-agent/test/rpc-oauth-login.test.ts	Updates credential-survival regression cases but does not cover cancellation after credential persistence.
packages/coding-agent/test/interactive-auth-login.test.ts	Verifies interactive login completion for provider-error and aborted refresh results.
packages/coding-agent/CHANGELOG.md	Documents that post-login catalog refresh outcomes no longer roll back OAuth credentials.

Sequence Diagram

sequenceDiagram
  participant Client
  participant RPC as RpcProviderAuth
  participant Store as Auth Storage
  participant Registry as Model Registry
  Client->>RPC: login_provider
  RPC->>Store: Persist new OAuth credential
  RPC->>Registry: refresh(signal)
  Client->>RPC: cancel_login_provider
  RPC->>Registry: Abort signal
  Registry-->>RPC: "{ aborted: true }"
  RPC-->>Client: Login success, cancelled: false

Loading

Prompt To Fix All With AI

### Issue 1
packages/coding-agent/src/modes/rpc/rpc-provider-auth.ts:136-137
**Cancellation reports login success**

When `cancel_login_provider` arrives after the credential is persisted but during the catalog refresh, `refresh()` returns an aborted result normally and this path continues to report `cancelled: false`. The client consequently receives both a successful cancellation acknowledgment and a successful login response.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(auth): never roll back OAuth credent..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Cancellation reports login success

When cancel_login_provider arrives after the credential is persisted but during the catalog refresh, refresh() returns an aborted result normally and this path continues to report cancelled: false. The client consequently receives both a successful cancellation acknowledgment and a successful login response.

Artifacts

Repro: focused Vitest race harness using the real RPC command handler

• Evidence file captured while the check ran.

Repro: Vitest configuration used to execute the focused artifact test

• Evidence file captured while the check ran.

Repro: verbose execution trace showing refresh start, successful cancellation acknowledgement, aborted refresh, and login success with cancelled false

• The full command output behind this check.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/coding-agent/src/modes/rpc/rpc-provider-auth.ts
Line: 136-137

Comment:
**Cancellation reports login success**

When `cancel_login_provider` arrives after the credential is persisted but during the catalog refresh, `refresh()` returns an aborted result normally and this path continues to report `cancelled: false`. The client consequently receives both a successful cancellation acknowledgment and a successful login response.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[flora131]

Valid race on this branch, resolved in the stacked #2064 which rewrites this file for the ModelRuntime migration: loginOAuth now re-checks controller.signal.aborted after modelRuntime.login() returns and reports cancelled: true for a cancel landing during the post-persist catalog refresh. The persisted tokens are deliberately kept in that window — rolling them back is the invalid_grant trap this PR removes (providers rotate refresh tokens, so a rollback can strand a server-side-invalidated credential). Fixing it here separately would conflict with the stacked rewrite for an identical end state, so it lands via #2064.