Codex re-auth updates managed credentials but matching system account keeps using revoked token

[Nek-12]

Summary

On CodexBar 0.58.0 (141), a saved Codex account that also matches the system Codex login stays at Needs re-auth after repeated successful reauthentication through CodexBar settings.

Reauthentication produces a valid credential in CodexBar's managed account home, but the visible account continues using the revoked credential in ~/.codex/auth.json. Selecting OAuth API as the quota usage source does not resolve the mismatch.

Environment

• macOS, Apple Silicon; CodexBar 0.58.0 (141).
• Two saved OpenAI/Codex accounts; only the account matching the system login is affected.
• Advanced Account Security enabled on the affected account. This is context, not an established cause: its freshly authenticated credential successfully fetched usage.

Reproduction observed

1. Have a saved Codex account also represented by the system Codex login.
2. The system credential becomes invalid/revoked.
3. Re-authenticate that account through CodexBar account settings.
4. Authentication succeeds, but usage continues showing Needs re-auth.
5. Repeat authentication and explicitly select OAuth API; the failure persists.

Diagnostic evidence

The saved account snapshot used selectionSource.kind = liveSystem, with a different credential fingerprint from the managed account's fresh login.

Read-only GET requests to https://chatgpt.com/backend-api/wham/usage, using the respective existing credentials and the same account header, returned:

Credential	Result
System ~/.codex/auth.json	HTTP 401, token_revoked: Encountered invalidated oauth token for user, failing request
Fresh CodexBar managed account auth.json	HTTP 200 with usage data

The system access token was issued September 1, 2026 and expired September 11. The managed credential was issued September 11 and expires September 21. No refresh-token redemption was attempted during this comparison.

Relevant implementation

In Sources/CodexBarCore/Providers/Codex/CodexVisibleAccountProjection.swift, the matching live-system account replaces the managed account draft with selectionSource: .liveSystem and the live credential fingerprint, while retaining the saved account ID and reauthentication capability.

ManagedCodexAccountService.authenticateManagedAccount authenticates into a new managed home and updates the stored account. This appears to leave the visible account reading a different credential than the one just renewed.

The live-system projection preference is also present in the v0.59.0 source; runtime reproduction was on v0.58.0 only.

Expected behavior

After successful reauthentication of a visible account, its usage fetch should use the newly authenticated credential. If repairing the system login requires separate consent, the UI should explain that and offer the appropriate action instead of repeatedly renewing an unused credential.

Verified local repair

After backing up the system auth file, replaced it atomically with the already-working managed auth file for the same account. CodexBar CLI usage with --provider codex --source oauth then succeeded, and the user confirmed the menu recovered.

No security setting changes or additional sign-in were necessary.

Potentially related: #3523 / #3534 concern renewal guidance, but this report specifically concerns reauthentication updating one credential while the visible account continues using another.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 11, 2026, 1:05 PM ET / 17:05 UTC.

Summary
Current main still contains the reported credential mismatch. The report establishes a distinct recovery bug; the merged diagnostic fix does not address it, and automatic renewal work does not resolve which credential manual reauthentication updates.

Reproducibility: yes. at source level: combine a saved account with the same system identity but different credentials, then invoke Reauthenticate; Settings renews the managed home while reconciliation and usage retain liveSystem. No runtime reproduction or artifact-producing tests were executed.

Root-cause cluster
Relationship: canonical
Canonical: #3558
Summary: This report identifies a distinct mismatch between manual reauthentication and the credential source used by the merged account row.

Members:

• adjacent_distinct: Managed Codex workspace has no automatic renewal path when native OAuth expires (0.56.8) #3523 - Concerns managed-workspace renewal availability rather than renewing a credential the visible row does not use.
• adjacent_distinct: Fix misleading Codex credential recovery guidance #3534 - Merged wording correction explicitly preserved credential ownership and reauthentication behavior.
• partial_overlap: Refresh managed Codex credentials without losing workspace scope #3379 - Open automatic-renewal work handles stale or rejected native credentials, but does not establish a repair for the manual source mismatch.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Maintainer decision needed

Question	Recommendation
Should a merged saved/system row repair its system login with explicit consent, or should successful managed reauthentication change that row's credential source?	Repair the selected system login: Make the system effect explicit and route recovery through the credential-owning CLI in the intended home, preserving workspace checks.

Why: Both can restore usage, but they have different effects on system credentials and established source-selection behavior; VISION.md requires provider-auth sign-off.

Next step
Obtain provider-auth sign-off on the recovery target before commissioning a focused repair; the repository profile also disables automatic cleanup.

Security
None.

Review details

Best possible solution:

Provide an explicit in-product Repair system login action for merged rows, scoped to the intended home and account, that preserves CLI credential ownership and refreshes usage from the repaired source.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: combine a saved account with the same system identity but different credentials, then invoke Reauthenticate; Settings renews the managed home while reconciliation and usage retain liveSystem. No runtime reproduction or artifact-producing tests were executed.

Is this the best way to solve the issue?

Unclear until the credential-owner choice is approved. Source-aware recovery is narrower than changing global account deduplication or silently copying auth files.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Automatically copying managed credentials into the system home could interfere with the CLI's credential ownership or selected workspace.
• The reported runtime failure was observed on v0.58.0; current-main confirmation is source-based, without executing authentication or provider probes.

Codex review notes: model internal, reasoning medium; reviewed against 1c4650d1b421.

Label changes

Label changes:

• add P0: The reported in-product account recovery repeatedly succeeds without restoring access, and the verified workaround required manual credential-file replacement.
• add impact:auth-provider: Usage requests keep selecting revoked system credentials after managed reauthentication succeeds.
• add impact:ux-release-blocker: The affected account has no effective recovery through its Reauthenticate action; demonstrated recovery required technical intervention.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P0: The reported in-product account recovery repeatedly succeeds without restoring access, and the verified workaround required manual credential-file replacement.
• impact:auth-provider: Usage requests keep selecting revoked system credentials after managed reauthentication succeeds.
• impact:ux-release-blocker: The affected account has no effective recovery through its Reauthenticate action; demonstrated recovery required technical intervention.

Evidence reviewed

What I checked:

• Current-main identity: The checkout and GitHub main both resolve to the recorded review SHA; the working tree was clean. (1c4650d1b421)
• Reauthentication selects the managed credential owner: A visible row with storedAccountID enters the managed-login branch before the live-login branch, then refreshes usage without changing the selected credential source. (Sources/CodexBar/PreferencesProvidersPane.swift:293, 1c4650d1b421)
• Matching row retains system credentials: The projection retains the saved account ID and reauthentication capability while replacing its selection source and fingerprint with the matching live-system account. Identity matching can preserve this choice despite different credential fingerprints. (Sources/CodexBarCore/Providers/Codex/CodexVisibleAccountProjection.swift:201, 1c4650d1b421)
• Successful login updates a separate home: Managed authentication creates a new managed home, logs in there, and persists that home and its fingerprint in the saved account; this path does not update the system credential. (Sources/CodexBar/ManagedCodexAccountService.swift:243, 1c4650d1b421)
• Usage follows the projected source: Per-account usage supplies account.selectionSource to the fetch context. ProviderRegistry resolves that source into CODEX_HOME, so choosing OAuth API does not switch this row to its fresh managed credentials. (Sources/CodexBar/UsageStore+TokenAccounts.swift:838, 1c4650d1b421)
• Existing tests deliberately preserve system selection: The merged-row test expects both the active-source resolver and visible projection to choose liveSystem. Merely selecting the saved account again is therefore not a repair. (Tests/CodexBarTests/CodexAccountReconciliationTests.swift:492, 1c4650d1b421)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Ratul Sarna: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Fixed in #3560. The merged saved/System row now uses the System Codex login flow for Re-auth, matching the credential source used by its usage fetch. Managed rows continue to renew their own private homes; CodexBar does not copy tokens between them. The action also rejects a row whose source or workspace changed before dispatch.

The regression tests reproduced the wrong-runner behavior, and focused/full tests, signed synthetic UI proof, independent review and CI passed. This is on main and recorded for 0.59.1 Unreleased. Thanks for the precise comparison of the two credential sources.