Repeated sign-in screen appears after completing a response or opening an existing session

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

• #39718
• #39695
• #39684
• #39685
• #39716

Powered by Codex Action

Update: the issue is no longer reproducing, but the sequence that resolved it suggests an account/onboarding-state interaction rather than corrupted local app data.

Before the issue disappeared, I performed a full clean reinstall and launched the app with none of the previous settings, conversations, databases, or caches restored. The affected account still reproduced the same sign-in loop in that completely fresh state. This makes restored local Codex data unlikely to be the direct cause.

The following sequence resolved the issue:

1. I had recently enabled TAC through https://chatgpt.com/cyber on the affected account.
2. In the desktop app, I switched to another sub-account/profile that did not have TAC enabled.
3. A tutorial/onboarding page appeared for that account, and I completed it.
4. I then switched back to the originally affected account.
5. After that, completing a response or opening an existing conversation no longer caused the desktop app to display the sign-in screen.

There was no additional reinstall, cache reset, or data restoration between steps 2 and 5.

This is only a correlation, not a confirmed root cause, but it suggests that the problem may involve a mismatch between TAC entitlement activation, an incomplete or undisplayed onboarding state, and desktop account-state synchronization. Completing the tutorial through the non-TAC account may have initialized shared desktop state or triggered a server-side account-state update.

It may also be related to why the account-settings request returning 401 caused the desktop authentication state to transition to auth_token_missing, even though the same account remained authenticated and usable through web, mobile, and Codex CLI.

It would be helpful to investigate:

• Whether enabling TAC creates an onboarding or entitlement transition that must be completed.
• Why the required tutorial was not displayed for the affected TAC-enabled account.
• Whether completing onboarding for one account updates shared desktop or server-side state used by other accounts.
• Why a 401 from the account-settings endpoint results in token detachment and a repeated sign-in loop instead of credential recovery.

The original logs and affected session context were submitted through in-app feedback:

01a02106-db17-74c3-8ec3-ae1542802c94

Current status: resolved through the workaround above on this device, but the underlying product issue and root cause are not confirmed.

Related Issue: #39162

I can reproduce the exact same issue on Windows.

The failure sequence is also identical:
desktop_fetch_auth_401 hadToken=true
GET /backend-api/accounts/:param/settings
→ auth_token_missing
→ Unauthorized

Codex CLI remains authenticated and works normally.
Reinstalling the desktop app and updating to the latest available version did not resolve it.

100% what is happening to me, as I use Daybreak and am being forced to set up passkeys, I did so yesterday, and I am now in a login loop. As soon as I start a new chat or read an old one, I get logged out. It is fine in the classic app (not good for Codex) , mobile and browser. Also fine if I use Codex on a different machine. As per usual, OpenAI support has been useless.

This is what i sent to Support:

Codex Desktop on Windows signs me out whenever I create a new conversation. The issue began after moving my OpenAI account to passkey authentication.

All active OpenAI sessions have been revoked and Advanced Account Security has been disabled for troubleshooting.

Codex application state has been fully reset, including the Electron profile and MSIX local state. Native Codex authentication state was also reset by removing and regenerating ~/.codex/auth.json and cap_sid.

A fresh auth.json is successfully generated after login, confirming that authentication itself completes successfully.

Creating a new Codex conversation immediately causes the client to lose authentication again.

Codex logs show repeated requests to /backend-api/wham/tasks/list failing with HTTP 401 and specifically:

desktop_fetch_auth_401 hadToken=false

skipRetryReason=no_token_attached

tokenSource=cached

willRetry=false

followed by:

errorMessage={“detail”:“Unauthorized”}

There are no CODEX_ACCESS_TOKEN or OPENAI_API_KEY environment variables configured.

This appears consistent with the existing Codex Desktop authentication bridge issue where valid ChatGPT authentication exists on disk but the desktop client fails to attach the access token to ChatGPT backend requests.

Affected Codex package: OpenAI.Codex_26.818.2441.0_x64__2p2nqsd0c76g0

Windows platform, x64.

Same issue. Daybreak Red + TAC = Login screen loop/cli works just fine

Installed the Beta app and it works.

Additional reproduction detail from another affected macOS user:

• Codex/ChatGPT Desktop stays authenticated as long as no Codex conversation is opened in the desktop UI.
• ChatGPT mobile Remote Control can continue to control the same Mac/Codex session normally during this time.
• The forced logout is triggered specifically when an existing Codex conversation is opened/resumed in the desktop UI.
• This suggests the underlying Codex app-server/session and Remote Control path remain healthy, while a desktop-only request during thread resume/rendering triggers the auth collapse.
• The same ChatGPT account works normally on another Mac at work, while the home Mac consistently reproduces the issue even after updating to the latest available Desktop build.

This appears consistent with the observed sequence in related reports: thread resume succeeds first, then a desktop account/settings request returns 401, followed by auth_token_missing and forced sign-out.

A useful A/B control here is: leave Desktop open but do not open any thread -> Remote Control remains usable; open a thread in Desktop -> logout occurs.

Additional data point from a newer macOS build:

ChatGPT desktop 26.818.41705, released Aug 22, 2026.

The issue is still reproducible.

One potentially useful difference in my logs is that the first observed auth-state transition was triggered by /wham/tasks/list while the client still reported hadToken=true:

2026-08-22T19:35:00.967Z warning [electron-fetch-wrapper] desktop_fetch_auth_401 hadToken=true skipRetryReason=null target="GET https://chatgpt.com/backend-api/wham/tasks/list" tokenSource=cached willRetry=true

2026-08-22T19:35:01.244Z warning [AppServerConnection] app_server_connection.auth_status_result authMethod=chatgpt hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

2026-08-22T19:35:01.557Z info [electron-message-handler] [chatgpt-account-lookup] completed authenticatedAccountPresent=false authMethod=chatgpt failureType=account_info_token_unavailable result=failed

After signing in again, login and account lookup succeeded, but about 8 seconds later /accounts/{account_id}/settings returned 401 and produced the already-reported hadToken=true → auth_token_missing → authenticatedAccountPresent=false sequence.

One other observation may help distinguish the affected layers:

While the ChatGPT desktop GUI on this Mac is showing the login screen, a remote Code session hosted by this same Mac remains fully operational.

In fact, I performed this entire diagnostic investigation remotely from the ChatGPT iPhone app through that Code session. It was able to access the Mac filesystem, read the local logs under /Users/<username>/Library/Logs/com.openai.codex/, inspect multiple log files, and correlate the failure sequence above while the desktop GUI considered the account unauthenticated.

So the Mac-hosted Code/remote-execution layer remains functional at the same time that the desktop account/UI layer reports no authenticated account.

I have not cleared Keychain or local Codex/Work state. macOS unified logs showed Keychain reads around the incident, but no logged SecItemDelete or SecItemUpdate.

I can provide additional sanitized log excerpts if useful.

Additional macOS reproduction with a possible Advanced Account Security correlation.

Environment:

• ChatGPT Desktop 26.818.41705 (build 6971)
• macOS 26.3 (25D125)
• Apple Silicon / arm64
• Subscription: ChatGPT Pro
• ChatGPT authentication
• Advanced Account Security was enabled immediately before the issue first occurred

The issue has reproduced repeatedly from August 21 through August 23, including after:

• removing and regenerating ~/.codex/auth.json
• clearing the ChatGPT/OpenAI desktop cookies
• fully quitting and restarting the desktop app
• completing a fresh browser OAuth login
• testing with VS Code completely quit

A fresh login initially succeeds and the account is shown as authenticated. Opening or resuming an existing Codex thread then causes the desktop app to return to the sign-in state.

Sanitized sequence from the latest reproduction on 2026-08-23 (UTC):

09:13:06.221 thread/resume completed with errorCode=null
09:13:06.745 desktop_fetch_auth_401 hadToken=true
                 GET /backend-api/accounts/:account_id/settings
09:13:07.088 Failed to refresh token: 401 Unauthorized
                 code=refresh_token_invalidated
09:13:07.124 hasToken=false nullReason=auth_token_missing refreshToken=true
09:13:10.713 status=401
                 Missing valid access token or actor biscuit

As a control test immediately after a fresh login, the same unexpired access token received:

• HTTP 200 from the models endpoint
• HTTP 200 from the usage endpoint
• HTTP 401 from /backend-api/accounts/:account_id/settings

This suggests that the account-settings 401 is causing the desktop client to discard an otherwise usable authentication state and then immediately attempt a refresh that fails with refresh_token_invalidated.

The timing strongly suggests a correlation with Advanced Account Security: the authentication loop began immediately after it was enabled.

Disabling Advanced Account Security is not a viable workaround because the account UI warns that doing so will remove access to some advanced models.

This appears closely related to #39696, but is reproducible on the current macOS production build 6971.

Reverting to version ChatGPT-26.810.7004.0 restores normal functionality; the cause of the login loop issue remains unclear.

I am experiencing the same issue on macOS with ChatGPT desktop version 26.818.41509 (build 6962).

The latest reproduction occurred on August 24, 2026 at approximately 00:42 China Standard Time (UTC+8). The desktop logs show Failed to retrieve authentication token, status 432, and account_info_token_unavailable. The app displayed the sign-in screen while Codex tasks continued running. After fully quitting and reopening the app, it recovered immediately without requiring another login.

I also observed multiple duplicate Codex login sessions in ChatGPT web settings. Signing out all sessions and signing in again did not prevent the issue from recurring.

In-app feedback ID: 01a02e09-6311-7433-8199-0f27a30a7d0c

Having exactly same issue after enabling advanced security as required by OpenAI by Sep 1st in order to stay compliant to retain access to "DayBreak Blue".

But as soon as advanced security is enabled, my MacOS codex desktop app (latest as of 8/24/2026) ended up in repeated authentication loop as soon as I click on an existing codex thread, note that authentication flow can complete normally in the advanced security flow using security key, the issue only surfaces when I try to click on a codex session.

Issue persists after clean reinstall which suggests the issue at openAI server end.

also, As soon as I disable advanced security, this issue is gone...

OpenAi pls fix this issue asap before Sep 1st, so that we can stay compliant as you requested, otherwise if I enable advanced security, my desktop codex turns un-usable because of the endless login loop.

Thanks.

same issue. please upvote OP

One additional data point that may help narrow the suspected Advanced Account Security correlation:

This affected account is not enrolled in Advanced Account Security. In the desktop app I can only see its status; in online account management the available action is to Enroll, which I have not done.

So in my case, the login loop occurred while AAS was disabled/not enrolled. That suggests AAS may be a trigger for some affected accounts, but it is not a prerequisite for the bug and may not be the root cause.

Additional macOS reproduction:

• ChatGPT Desktop 26.818.41509 (build 6962)
• macOS, Apple Silicon
• The UI unexpectedly switched to the sign-in screen while the desktop process remained running.
• Both the bundled and standalone Codex CLI continued to report Logged in using ChatGPT; the local authentication file remained present.

Sanitized sequence:

desktop_fetch_auth_401 hadToken=true tokenSource=cached willRetry=true
GET /backend-api/accounts/:account_id/settings
status=401 detail="Must use workspace account for this operation"

Timed out waiting for MCP response to getAuthStatus
Failed to retrieve authentication token
status=432

The app was also repeatedly reconnecting to an unavailable Remote Control environment when getAuthStatus began timing out.

No account/login, browser-launch, or refresh_token_reused event appeared in the affected window. No authorization URL reached the default browser, so the displayed sign-in UI could not begin a supported browser login.

This supports a desktop auth-bridge/UI-state failure rather than credentials actually being absent. A workspace-only settings 401 or unavailable remote connection should not replace an otherwise authenticated desktop session with the sign-in screen.

Raw logs are intentionally not attached because they contain account, device, thread, and environment identifiers.

Additional reproduction on the current macOS desktop release:

• ChatGPT Desktop 26.818.61809 (build 7019)
• ChatGPT Plus
• macOS
• The issue started immediately after changing the OpenAI account password.
• Browser OAuth completes successfully and creates a new Codex active session.
• The desktop app initially opens normally, but sending the first Codex message consistently returns the app to the sign-in screen.
• Reproduction rate: 100%.

Sanitized log sequence after login:

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

Earlier logs also showed a revoked Remote Control token:

remote control auth recovery failed
HTTP 401 Unauthorized
code=token_revoked

To rule that out, I:

1. Disabled all Remote Control and SSH connections.
2. Deleted the persisted rows from remote_control_enrollments.
3. Removed the Remote Control keys from .codex-global-state.json.
4. Verified SELECT COUNT(*) FROM remote_control_enrollments; returned 0.

After that cleanup, the Remote Control token_revoked errors stopped, but the main desktop login loop remained with auth_token_missing.

Other troubleshooting already completed:

• Logged out all ChatGPT sessions.
• Fully quit and restarted the desktop app.
• Rebooted macOS.
• Uninstalled and reinstalled the current desktop app.
• Removed/recreated local authentication state.
• Tried the original older standalone Codex desktop app, but that version is no longer accepted/usable.
• Each repeated OAuth login creates another Codex entry under ChatGPT active sessions.

This confirms the current failure is not caused by the persisted Remote Control enrollment or a stale app installation. A successful login is being converted to auth_token_missing as soon as the first Codex conversation request is made.

I’m seeing what appears to be the same issue on macOS, ChatGPT Desktop 26.818.61809.

In my case, Home, Chat, Settings, and the Work home screen remain stable. However, opening an existing Work thread or starting a new Work causes authentication to fail within seconds.

The relevant log sequence is:

desktop_fetch_auth_401 hadToken=true ... /accounts/:param/settings
hasToken=false nullReason=auth_token_missing refreshToken=true
failureType=account_info_token_unavailable
Subsequent requests have hadToken=false.

Possible trigger / workaround: I had “Prevent sleep while running” enabled when this started happening. After disabling that setting, Work threads are currently stable again and the repeated sign-in loop has stopped.

I have not re-enabled the setting to confirm causality because the login loop makes Work effectively unusable for me, so I’m treating this as a suspected trigger rather than a confirmed root cause.

Each re-authentication also created a new Codex / macOS entry under ChatGPT Active Sessions.

Update: still stable after ~17 hours and multiple Work threads with “Prevent sleep while running” disabled.

Adding a data point — feedback ID no-active-thread-01a03e9b-3c8e-7183-8c24-8f4d2f274e87, macOS, app 26.820.60940.

Captured the renderer console on the bounce. Opening a conversation fires:
GET /backend-api/accounts/{id}/settings → 401 "Missing valid access token or actor biscuit"
→ auth_status_result nullReason=auth_token_missing
→ chatgpt-account-lookup: authenticatedAccountPresent=false, failureType=account_info_token_unavailable
→ conversation view unmounts to sign-in.

Deminified client fetchAuthToken() shows the app-server returns {authMethod:'chatgpt', authToken:null}
— it can't produce the account-scoped token; the client caches null and the newer builds gate the
conversation view on it. auth.json is never cleared (token stays valid on disk).

May not affect all accounts — could correlate with an account carrying some
non-default server-side entitlement flags.
(Details are attached to the feedback ID above if someone from OpenAI wants to check.)

26.810.52044 works; 26.814.41407, 26.818.x, and 26.820.60940 all broken with the identical chain.
Ruled out locally: fresh login, env vars, config.toml/MCP, and every remote (SSH + cloud) connection — no change.
Downgrade to 26.810 is the only fix I've found.

Also, I tried disabling all keep-awake like settings, closed and re-opened the app and that did not resolve my issue unfortunately.

Data point on the AAS theory: my account is enrolled in Advanced Account Security and still hits this — combined with the earlier non‑enrolled report, AAS looks orthogonal, not causal. Common factor across reports is the app version (26.814+), not an account flag.

On Monday I rolled back to 26.803.81509 which fixed everything and was less painful then installing the beta build others recommended. It's been working fine ever since so if you're using MacOS use this build for now.

• Apple silicon, arm64: https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-arm64-26.803.81509.zip
• Intel, x64: https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-x64-26.803.81509.zip

Try the steps mentioned in [this issue](https://github.com/openai/codex/issues/40541):

1. Fully quit Codex Desktop.
2. Sign out of ChatGPT in your browser.
3. Delete ~/.codex/auth.json.
4. Reopen Codex Desktop and sign in again.
5. Complete the OAuth authentication flow.

It worked for me and stayed stable.

macOS 26.6.2, ChatGPT 26.820.60940

Logging out of all sessions via "Settings > Security and login > Sesstions > Active sessions > Log out all" on chatgpt.com resolved the issue.