›_ Codex Issues
Codex Issues / #41044

[macOS] Codex Desktop auth loop persists on 26.820; rollback to 26.810.52044 fixes it

Open 💬 4 comments Opened Aug 27, 2026 by linhbv94
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Affected versions tested:

  • 26.818.61809
  • 26.820.xxxxx (exact patch version not recorded before uninstalling)

Last known-good version on the same machine:

  • 26.810.52044

What platform is your computer?

macOS on Apple Silicon (arm64)

What issue are you seeing?

Codex Desktop repeatedly loses authentication and returns to the ChatGPT sign-in screen when opening an existing conversation or starting/using a new Codex conversation.

Important control tests:

  • ChatGPT web works normally with the same account.
  • Codex CLI works normally with the same account and can execute prompts.
  • A newly started Codex task can still execute and modify code even while the Desktop UI loses authentication.
  • Reinstalling the latest official Desktop app does not fix the issue.
  • Clearing caches and resetting Codex Application Support/preferences does not fix the issue.

The strongest A/B test is version-specific:

  • 26.818.61809 -> broken
  • rollback to 26.810.52044 -> works normally
  • update to 26.820.xxxxx -> still broken
  • rollback again to 26.810.52044 -> works normally again

This strongly suggests a Desktop authentication regression in newer builds rather than an account, network, project, or local conversation-data issue.

Relevant log sequence

Sanitized log sequence from the affected Desktop build:

desktop_fetch_auth_401 hadToken=true ... target="GET https://chatgpt.com/backend-api/accounts/:param/settings" tokenSource=cached willRetry=true

app_server_connection.auth_status_result authMethod=chatgpt hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

sa_server_request_failed ... errorMessage="{\"detail\":\"Missing valid access token or actor biscuit\"}" ... status=401

# subsequent requests
desktop_fetch_auth_401 hadToken=false skipRetryReason=no_token_attached ... willRetry=false

Subsequent /wham/* requests return Unauthorized because the Desktop no longer attaches a token.

Steps to reproduce

  1. Install/update Codex Desktop to 26.818.61809 or a 26.820.x build on macOS Apple Silicon.
  2. Sign in with ChatGPT successfully.
  3. Open an existing Codex conversation, or start a new conversation and submit a task.
  4. The task may still execute successfully in the underlying Codex runtime.
  5. The Desktop UI loses authentication and returns to the sign-in screen.
  6. Sign in again; the loop reproduces.
  7. Roll back only the Desktop app to official signed/notarized 26.810.52044 while keeping the same machine, account, network, and project data.
  8. Observe that Codex Desktop works normally again.

Troubleshooting already performed

  • Quit/restarted the app
  • Signed out/in again
  • Cleared system/app caches
  • Renamed/reset Codex Application Support directories and preferences
  • Reinstalled the latest official Desktop app
  • Verified ChatGPT web works on the same account
  • Verified Codex CLI works on the same account
  • Verified the issue reproduces on newer Desktop versions and disappears immediately after rollback to 26.810.52044

Possibly relevant account history

Shortly before noticing the issue, I changed my ChatGPT password. I also accidentally signed Codex Desktop into a different ChatGPT account, then signed out and switched back to my primary account. I do not know whether either event is related or merely coincidental.

Expected behavior

Codex Desktop should remain authenticated after opening or running a conversation. A 401 from /accounts/{account_id}/settings should not collapse an otherwise valid authenticated state into auth_token_missing and force a login loop.

The fact that the same account and CLI continue working, and that rollback to 26.810.52044 fixes the issue immediately, suggests the regression is specific to newer Desktop authentication handling.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 day ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #41010
  • #39803
  • #40842
  • #39718
  • #39695

Powered by Codex Action

omribz156 · 4 hours ago

I can reproduce this as well, with a strong link to Advanced Account Security.

Environment

  • macOS, Apple Silicon (arm64)
  • Codex/ChatGPT Desktop: 26.820.60940 (build 7119)
  • Advanced Account Security enabled immediately before the problem started
  • Account protected with passkey + YubiKey/security key

What happened

  1. I enabled Advanced Account Security and added a passkey/YubiKey.
  2. As expected, this signed me out of existing sessions.
  3. I can sign back into ChatGPT successfully in the browser, and the iPhone app works normally.
  4. In Codex Desktop, browser authentication completes successfully and returns me to the app.
  5. The app initially appears authenticated: my existing projects/threads are visible.
  6. As soon as I open any existing Codex thread, the app immediately loses authentication and sends me back into the sign-in flow.
  7. Re-authenticating succeeds in the browser again, but the same loop repeats when opening a thread.

This is therefore not a failed passkey/YubiKey challenge: the browser authentication itself succeeds. The Desktop session appears to be invalidated only when authenticated Codex content is accessed.

I have not downgraded or reset local Codex data, so this is still reproducing on the original 26.820.60940 installation. Local conversation data is intact. I also have a screen recording showing the full successful browser auth -> return to Desktop -> open thread -> immediate logout loop if useful for debugging.

Given that this began directly after enabling Advanced Account Security, this may be useful as another reproduction of the newer Desktop auth regression with the new account-security flow.

brzvsk · 4 hours ago

Additional reproduction from another macOS / Apple Silicon user.

The issue started immediately after a ChatGPT account security cleanup: password changed, old active sessions revoked, and a passkey added.

Reproduction:

26.814.41407 — login succeeds; opening an existing Codex conversation logs the app out after ~3–5 seconds.
26.818.41509 — same behavior.
Removing the passkey did not change the behavior.
ChatGPT Web and iOS remained authenticated and worked normally.
If Codex Desktop stays idle on the new-session screen, it remains logged in; opening an existing conversation is what triggers the logout.
Rolling back only the Desktop app to 26.810.52044 (build 6662) fixes the issue, with the same account and local data.

This seems consistent with a regression in Desktop refresh-token / 401 handling after account credentials or sessions have been invalidated, rather than a general account authentication problem.

omribz156 · 26 minutes ago

Follow-up on my reproduction above: the default-browser workaround also worked for me.

Environment remains the same:

  • macOS / Apple Silicon (arm64)
  • Codex/ChatGPT Desktop 26.820.60940 (build 7119)
  • Advanced Account Security enabled
  • passkey + YubiKey/security key configured

My normal macOS default browser is Brave. I fully quit Codex, temporarily changed the macOS default browser to Safari, reopened Codex, and completed the ChatGPT re-authentication flow through Safari.

After that, Codex Desktop started working normally again and I was able to open existing conversations without being immediately logged out.

I did not downgrade the app, reset ~/.codex, remove the passkey/YubiKey, or change local conversation data. The only meaningful change was using a different default browser/auth session for the re-authentication.

So this is another independent confirmation that switching the default browser before re-authenticating can clear the logout loop, including from Brave -> Safari on build 26.820.60940. This still looks like a session/auth handoff workaround rather than a confirmed product fix.