After enrolling into Advanced Account Security (to keep access to Daybreak Blue), codex app is stuck in login-logout loop

[pkqs90]

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.61809

What subscription do you have?

20x Pro

What platform is your computer?

MacOS Darwin 25.6.0 arm64 arm

What issue are you seeing?

Endless logout loop. Codex app is not usable at all after enabling into Advanced Account Security

What steps can reproduce the bug?

1. Enable Advanced Account Security
2. Open Codex app
3. Automatically logs out after 5 seconds
4. Login again, still logs out after 5 seconds.

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• Codex Desktop loses ChatGPT access token and returns to sign-in after enabling Advanced Account Security #39581
• Windows Stable: opening a thread immediately invalidates fresh OAuth refresh token with Advanced Account Security enabled; Beta works #39696
• Windows Desktop app repeatedly logs out after sending one message when Advanced Account Security is enabled (401 Missing valid access token or actor biscuit) #39685

Powered by Codex Action

[pkqs90]

To provide more context, after I disabled "Advanced Account Security", I am still stuck in the endless logout loop.

[danielchristiancazares]

What I had to do was buy a VPN, clear my cache, restart my PC, and then go into Incognito mode and use the exact same login method (Apple) to login.

For some reason that worked and I have no idea why. IDK if that'll work for you and I'd try the without a VPN purchase but maybe try restarting your router? I'm not too sure what exactly allowed it to work.

[bigs]

Had this exact same issue. The fix was just to re-authenticate via an incognito browser as well. Would say the VPN is overkill. Thanks @danielchristiancazares, this was driving me nuts. @pkqs90 worth a try.

[danielchristiancazares]

Had this exact same issue. The fix was just to re-authenticate via an incognito browser as well. Would say the VPN is overkill. Thanks @danielchristiancazares, this was driving me nuts. @pkqs90 worth a try.

Glad I could help.

[Zome59]

I can reproduce this on a newer ChatGPT/Codex desktop build, and the failure is blocking access to all existing Codex conversations.

Environment

• ChatGPT desktop app: 26.820.60940
• Platform: macOS
• Browser used for desktop OAuth handoff: Chrome 151
• Subscription: ChatGPT Pro
• Account: TAC / Daybreak Blue access
• Advanced Account Security: enabled in response to the OpenAI security requirement
• Hardware authenticators: 2 × Yubico Security Key C NFC (FIDO2/WebAuthn), both registered successfully

What happens

Hardware-key authentication itself succeeds. The browser reports a successful login, OpenAI sends a “New sign-in” notification for App: Codex, and a fresh Codex session appears under ChatGPT → Settings → Security and Login → Active Sessions.

The desktop app then opens normally and shows my projects/conversation list. A fresh/new-chat surface can remain open. However, the moment I open any existing Codex conversation, the conversation starts to load briefly and the desktop app immediately switches back to “Sign in to ChatGPT”.

I reproduced this with multiple unrelated existing conversations, including conversations in different project contexts, so it is not isolated to one thread/project.

Clean reproduction performed

1. Enabled Advanced Account Security and registered two physical FIDO keys.
2. Verified both hardware keys independently can authenticate successfully in the web flow.
3. Quit ChatGPT desktop completely and rebooted macOS.
4. In ChatGPT Web, removed every old ChatGPT/Codex session individually, leaving only the current known-good web session.
5. Launched ChatGPT.app and selected Continue to sign in.
6. Completed the browser authentication using the Yubico hardware key (PIN + physical touch).
7. Browser reported successful authentication and handed control back to ChatGPT.app. Because “always allow chatgpt.com to open this app” had already been enabled, the final app handoff happened automatically.
8. Confirmed a new Codex session was created server-side in Active Sessions.
9. Left the desktop app idle: it remained open and appeared authenticated.
10. Opened an existing Codex conversation.
11. The conversation began loading, then the app immediately returned to the sign-in screen.
12. Repeated with a different existing conversation outside that project: same result.

This was also reproduced in an earlier clean login attempt; each successful browser/FIDO login created a new Codex session, but opening an existing conversation still caused the desktop UI to lose authentication.

Expected behavior

After a successful Advanced Account Security / FIDO authentication, the desktop app should keep the authenticated Codex session and allow existing conversations to open normally.

Actual behavior

Successful FIDO login → fresh server-side Codex session created → desktop appears authenticated → opening any existing Codex conversation → immediate return to sign-in screen.

Troubleshooting already completed

• Full macOS restart
• Verified both primary and backup Yubico keys independently
• Confirmed both keys are registered in ChatGPT security settings
• Removed all stale ChatGPT/Codex sessions and reproduced from a clean server-side session state
• Repeated browser → app authentication several times
• Confirmed web ChatGPT remains usable
• Confirmed the failure is not specific to one conversation/project
• No separate legacy Codex.app is installed/running; the current unified ChatGPT.app is being used

Impact

Productivity-blocking. I use existing Codex desktop sessions for active development work. After following OpenAI’s recommended/required Advanced Account Security migration for TAC/Daybreak Blue access, the desktop app can no longer open any of those existing sessions. Web ChatGPT still works, and CLI may be usable as a fallback, but it does not replace the desktop workflow/session continuity.

This looks closely related to #39803 and #39162, but in my case the trigger is specifically reproducible immediately after enabling Advanced Account Security with physical FIDO keys, matching this issue (#40611).

I can provide sanitized desktop logs/screenshots if maintainers need them. No recovery codes, FIDO PINs, tokens, account IDs, or other authentication secrets are included here.

[Zome59]

Additional diagnostic result: the issue reproduces identically on a completely separate mobile/cellular network.

Mobile hotspot isolation test

• Disabled the Mac's normal LAN/Ethernet path.
• Disconnected from the usual FRITZ!Box Wi‑Fi/router network.
• Connected the Mac to an iPhone Personal Hotspot using the phone's mobile/cellular data connection.
• Reauthenticated successfully with the Yubico FIDO key.
• OpenAI again sent a successful App: Codex sign-in notification; the approximate location changed, confirming the login used the separate mobile network path.
• ChatGPT.app opened successfully and appeared authenticated.
• I then used a new chat, submitted a simple test prompt, and received a response indicating the agent was ready.
• Immediately afterward, the desktop app again switched to “Sign in to ChatGPT”.

So the failure is not limited to my normal router/Wi‑Fi/LAN network and is reproducible over an independent cellular hotspot as well.

This also broadens the trigger observed in my case: it is not only opening an existing conversation. After a fresh successful login, a new-chat interaction can complete and then the app loses authentication immediately afterward.

No visible error code or error text is shown before the redirect.

[Zome59]

Additional workaround test: re-authentication through Chrome Incognito did not resolve the desktop auth loop on my macOS setup.

Incognito test performed

1. Fully quit ChatGPT.app.
2. Opened a fresh Chrome Incognito window.
3. Re-authenticated successfully to ChatGPT/OpenAI in that Incognito session using the same physical Yubico FIDO key.
4. Confirmed the Incognito browser session was authenticated successfully.
5. Opened https://chatgpt.com/codex/open-app?source=login&app_brand=chatgpt from the authenticated Incognito session.
6. Browser displayed: “You are signed in and can close this tab” with the Open ChatGPT button.
7. Clicking Open ChatGPT brought ChatGPT.app to the foreground, but the desktop UI remained on “Sign in to ChatGPT / Continue to sign in” and did not accept/attach the authenticated Incognito session.

So, for this affected account/build, the Incognito re-authentication workaround reported by other users in this thread is not sufficient. The browser is authenticated, but the desktop app still does not establish/retain the corresponding authenticated state.

[Zome59]

Sanitized desktop-log confirmation from the affected macOS machine:

Environment confirmed in logs

• macOS 15.7.7 (arm64)
• ChatGPT Desktop 26.820.60940
• Build 7119
• Bundle ID com.openai.codex

Repro log sequence (existing conversation)

The desktop app is initially authenticated and the thread resumes successfully, then the auth state collapses immediately after an account-settings request:

chatgpt-account-lookup ... authenticatedAccountPresent=true authMethod=chatgpt result=succeeded
AppServerConnection ... method=thread/resume ... errorCode=null
desktop_fetch_auth_401 hadToken=true target="GET https://chatgpt.com/backend-api/accounts/[REDACTED]/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 ... "Missing valid access token or actor biscuit" ... status=401
chatgpt-account-lookup ... authenticatedAccountPresent=false failureType=account_info_token_unavailable result=failed
desktop_fetch_auth_401 hadToken=false skipRetryReason=no_token_attached ... willRetry=false
sa_server_request_failed ... "Unauthorized" ... status=401

This sequence is repeated multiple times in the logs when existing conversations are opened.

New-chat reproduction is also captured

During the separate mobile-hotspot test, the logs show a new turn starting/completing, then the same authentication collapse:

Received turn/started for unknown conversation
Received turn/completed for unknown conversation
desktop_fetch_auth_401 hadToken=true target="GET https://chatgpt.com/backend-api/accounts/[REDACTED]/settings" ... willRetry=true
app_server_connection.auth_status_result ... hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
chatgpt-account-lookup ... authenticatedAccountPresent=false failureType=account_info_token_unavailable
sa_server_request_failed ... "Missing valid access token or actor biscuit" ... status=401

Additional clue

An earlier log entry from the same desktop client shows the account-settings endpoint returning:

HTTP 401: "Must use workspace account for this operation"

against /accounts/{account_id}/settings.

This is very close to the failure described in #39189: a personal Pro account receives a workspace-only settings 401, after which the unified desktop client drops/detaches the otherwise valid ChatGPT auth state.

No tokens, account IDs, conversation IDs, local usernames, FIDO secrets, or recovery material are included in this comment.