Repository navigation
[macOS][26.814.41407] Opening an existing conversation invalidates ChatGPT auth and redirects to sign-in #39162
Description
What version of the Codex App are you using?
26.814.41407 (build 6720), macOS arm64 production build.
The last known-good version on the same machine is 26.810.52044 (build 6662).
What subscription do you have?
ChatGPT account authentication. Exact tier omitted because the failure is in the desktop authentication bridge and reproduces before any model request.
What platform is your computer?
- MacBook Pro (Mac16,8)
- Apple M4 Pro
- macOS 26.5.2 (25F84)
- arm64
What issue are you seeing?
Immediately after the automatic update to 26.814.41407, opening any existing conversation redirects the desktop app to the "Log in to ChatGPT" screen.
At launch, the app initially appears authenticated and shows the conversation list. Selecting an existing conversation successfully resumes the local thread, but within about 400 ms the desktop shell receives HTTP 401 from the ChatGPT account settings endpoint. The app then reports that the auth token is missing, changes the account state to unauthenticated, and displays the login screen.
Quitting and reopening the app temporarily shows the authenticated UI again. Selecting an existing conversation immediately repeats the failure.
Manually signing out also produced a full-screen "Oops, an error has occurred" page.
Sanitized log sequence from 26.814.41407:
chatgpt-account-lookup ... authenticatedAccountPresent=true authMethod=chatgpt result=succeeded
AppServerConnection ... method=thread/resume ... errorCode=null
electron-fetch-wrapper ... desktop_fetch_auth_401 hadToken=true ... /accounts/:param/settings ... willRetry=true
AppServerConnection ... authMethod=chatgpt hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
chatgpt-account-lookup ... authenticatedAccountPresent=false failureType=account_info_token_unavailable result=failed
electron-message-handler ... status=401 ... Missing valid access token or actor biscuit
electron-message-handler ... status=401 ... Unauthorized
No account IDs, conversation IDs, token values, or local paths are included above.
What steps can reproduce the bug?
- Be signed into ChatGPT in Codex/ChatGPT Desktop on macOS.
- Update the desktop app from 26.810.52044 (build 6662) to 26.814.41407 (build 6720).
- Launch the app. It initially appears signed in and lists existing conversations.
- Select any existing conversation.
- Observe that the thread resumes locally, then the app immediately redirects to the ChatGPT login screen.
- Quit and relaunch the app. It appears signed in again until an existing conversation is selected, after which the same redirect occurs.
What is the expected behavior?
Opening an existing conversation should preserve the authenticated account state and load the conversation normally.
Additional information
Troubleshooting completed:
- Disabled and fully quit AdGuard: no change.
- Quit and relaunched the desktop app repeatedly: no change.
- Signed out and performed a fresh ChatGPT device authorization: login succeeded, but selecting an existing conversation still triggered the same 401 and
auth_token_missingsequence. - Cleared and rebuilt the Electron cookies, local storage, and session storage after making backups: no change.
- Verified the bundled CLI reports ChatGPT authentication configured and provider/WebSocket reachability healthy.
- Tested both the bundled app-server and stable Codex CLI 0.147.0: no change.
- Rolled back only the desktop app to the official signed and notarized 26.810.52044 build while preserving the same account, local thread data, and network environment.
Rollback result:
- Existing conversations resumed successfully.
- The authenticated account remained present.
- The
desktop_fetch_auth_401andauth_token_missingevents disappeared. - The app became usable immediately without changing AdGuard, account, or network configuration.
This makes the regression strongly specific to desktop build 26.814.41407 rather than the account, local conversation data, or network path.
Related but not identical reports:
- Codex Desktop OAuth token_exchange_failed immediately after automatic update to 26.810.41047 on macOS #38482 — macOS authentication/token exchange failure immediately after automatic update.
- /status shows "Limits data not available yet" and /usage asks to sign in despite ChatGPT authentication #39139 — CLI reports ChatGPT authentication while account-dependent commands still ask the user to sign in.
User feedback: Linux Mint shows the same sign-in loop when opening chats
- Source: Codex Desktop keeps logging me out and require re-login #39218 (comment)
- Source: Codex App: infinite sign-in loop — app never receives a chatgpt.com session cookie, so backend-api calls 401 ("Missing valid access token or actor biscuit") #40029 (comment)
- Type: external
- User reports:
- On Linux Mint 22.3, after an in-app update, navigating to “any of my in progress chats” sent the app “into a logout state and forced a relog”; the process repeated every time they went to a chat.
- On Linux Mint 22.3 with the official OpenAI DEB, “Opening an existing conversation then causes the app to return to the sign-in screen.”
- The same reporter says “The bundled CLI still reports: Logged in using ChatGPT” and fresh browser login did not resolve the desktop problem.
Activity
kent8192 commentedon Aug 18, 2026
Confirming this reproduction on another machine (macOS arm64).
com.openai.codex), version 26.814.41407 (build 6720), Apple Siliconauth_mode = chatgpt)Observed (matches this issue's log sequence exactly): at launch the app appears signed in and lists conversations; selecting an existing conversation resumes the thread, then within ~2s:
desktop_fetch_auth_401 hadToken=true … /accounts/:param/settings … willRetry=truesa_server_request_failed … "Missing valid access token or actor biscuit" … /accounts/{account_id}/settings … status=401getAuthStatus … hasToken=false nullReason=auth_token_missingAfter that the app drops the cached token (
hadToken=false skipRetryReason=no_token_attached) and/wham/tasks/listreturns 401 every ~60s, driving the sign-in redirect loop.Already attempted (no fix): deleted/regenerated
~/.codex/auth.jsonand did a fresh device login — OAuth refresh now succeeds (refresh_token_invalidatedno longer appears), but the settings-endpoint 401 and loop still recur.Workaround: rolling back to 26.810.52044 (build 6662); will report back whether it clears the loop here too.
AndreRobitaille commentedon Aug 18, 2026
Same problem here. Same platform.
mattdorman commentedon Aug 19, 2026
Confirming here as well, with an OS data point: this also reproduces on the macOS 27.0 developer beta (build 26A5416b), Apple Silicon (arm64) — so it doesn't appear specific to any one macOS release; the app build is the common factor.
desktop_fetch_auth_401appears 16 minutes later (13:19:56Z) —hadToken=trueon/accounts/:param/settings, thenhadToken=false skipRetryReason=no_token_attached tokenSource=cachedfor everything after, same sequence @kent8192 posted above.~/Library/Logs/com.openai.codex/: 0 occurrences across Aug 5–17 logs, 196 since the update.account_login_completedlogged 30 times since the update — sign-ins via passkey and hardware security key both complete every time, but the token never reaches the fetch layer, so the next/backend-api/wham/tasks/listcall 401s and the sign-in sheet reappears.Codex Safe Storage) and cookie stores verified intact.codexCLI on the same machine is unaffected —~/.codex/auth.jsonrefreshes normally (it was last refreshed by the desktop app mid-loop, so OAuth itself is healthy).Happy to provide fuller logs if useful.
excessbaggage commentedon Aug 19, 2026
same issue. Macbook air m5
nengong commentedon Aug 19, 2026
Another reproduction on macOS 26.6 / M1 Max, sanitized logs below.
[macOS][26.814.41407] Sign-in loop after update: fresh OAuth token rejected (actor biscuit 401)
Environment: Codex desktop 26.814.41407 (build 6720), updated from 26.810.52044 on Aug 19 ~11:54 local; macOS 26.6 (25G72), M1 Max; ChatGPT account auth.
Summary: Since the update, the app loops: OAuth completes, chat UI shows ~2 s, then bounces back to sign-in, indefinitely. Same account/network/config worked before.
Reproduce: Update to 26.814.41407 → ChatGPT sign-in succeeds → chat UI appears, previous conversation restores → within ~2 s back to the login screen.
Log sequence (~/Library/Logs/com.openai.codex/2026/08/19, UTC; app refreshed auth.json at 04:01:45, so OAuth itself is healthy):
The fresh token never reaches backend-api requests, so the app treats the session as unauthenticated.
Timeline (local logs): Aug 17 and Aug 19 morning on 26.810.52044: app fully working, zero auth errors in logs. Updated to 26.814.41407 on Aug 19 ~11:54 local → hard loop within seconds: 8× actor-biscuit, 8× auth_token_missing in ~10 min.
Tried (no effect): 3 web re-authorizations (each completes); 6 restarts; reinstall from newly downloaded DMG (same build).
Refs: identical to #39162 (same build/logs, multiple confirmations); related #38482.
Request: prioritize a patch for build 6720's auth bridge, or advise a workaround other than rollback to 26.810.52044.
chunguscodes commentedon Aug 19, 2026
I am now also experiencing this issue.
gaozhitw commentedon Aug 19, 2026
I found a workaround that resolved the issue for me:
After completing these steps, I can open any existing conversation without being signed out again.
This may help anyone encountering the same problem. It appears that fully clearing the existing device and web sessions before signing in with the updated app is the important part, although I have not confirmed the underlying root cause.
JiaruiUNSW commentedon Aug 19, 2026
Additional root-cause isolation: personal paid plan is enabling a workspace-only settings query
I reproduced this independently on macOS arm64 with a personal ChatGPT Pro account and compared the shipped renderer bundles from a failing and a working signed build.
Affected / control builds
26.814.41407(build 6720) and26.814.41957(build 6744).26.727.51351(build 6119).0.148.0did not change the failure, which points to the desktop renderer/auth bridge rather than thread data or Codex core.Endpoint and token comparison
Immediately before the logout, the same fresh bearer token produced:
The selected historical thread had already completed
thread/resumesuccessfully. The settings 401 was then handled by the generic authenticated-fetch retry path, followed by a forced auth refresh; the observed state sequence ended inrefresh_token_invalidated/auth_token_missing,hasToken=false, and the sign-in UI.This means the historical session files are not the source of the failure. A resource-authorization 401 from a workspace-only endpoint is being escalated into global authentication loss.
Shipped renderer A/B
In the failing renderer, the usage banner mounts a hook that requests
/accounts/{account_id}/settingsand selectsusage_limit_increase_request. For a non-owner/non-admin account, the hook is enabled when any of the following are true:pricePlanis non-null for personal paid plans such as Pro, so a normal personal Pro account now enters the workspace settings path.In the working build 6119, the equivalent hook was enabled only for workspace/threshold-related conditions:
The personal paid-plan
pricePlancondition was absent, and the workspace settings request was not made.Rollback validation
After rollback and a fresh login, I opened four different historical sessions:
thread/resumecalls succeeded./accounts/<account>/settingswere emitted.desktop_fetch_auth_401, token invalidation, orhasToken=falseevents occurred.The app remained signed in. This was with the same machine, account type, local sessions, network, and stable Codex core.
Suggested fix
account.structure === "workspace"or equivalent), not onpricePlanbeing present.usage_limit_increase_requestto unavailable.This appears to be the same cross-platform endpoint behavior reported in #39189, but the renderer bundle comparison above identifies why personal paid accounts started calling the workspace-only endpoint.
totkd commentedon Aug 19, 2026
Additional independent reproduction, with one UI observation that may be relevant to the workspace-account analysis above.
26.810.52044/ build 6662: works26.814.41407/ build 6720: sign-out loop26.814.41957/ build 6744: same sign-out loopDuring the failing login flow, I was also shown a “Choose a workspace” screen that I do not normally see during ChatGPT/Codex sign-in. This may be consistent with the workspace-only path described above, although I did not independently verify the endpoint behavior.
No local session data needed to be cleared for recovery.
breakaway4here-arch commentedon Aug 19, 2026
I’m seeing the same issue on macOS with ChatGPT/Codex 26.814.41407.
After signing in again, new conversations seem to work normally. However, opening an existing/older conversation appears to trigger the authentication failure and the app gets signed out.
Relevant log entries:
A few additional details:
26.814.41407The
refreshToken=truetogether withhasToken=false/auth_token_missingseems especially relevant.borystam commentedon Aug 19, 2026
Confirming this is still present on 26.814.41957 (newer than the 26.814.41407 in the title) — macOS, Apple Silicon, ChatGPT-account auth (
auth_mode = chatgpt). So the regression carries into 41957, not just 41407.Two data points to add:
Trigger correlation. Every
refresh_token_invalidated/ auth drop here fires while resuming an existing (older) conversation — the invalidation timestamps line up exactly with bursts ofthread/resumefor that thread. Freshly created conversations resume fine. (In my case the affected threads all predate enabling account "advanced security," though that may just be because those are the old ones.)Second failure mode during resume — thread-store conflict retry storm. Alongside the auth 401, the resume path spams retries:
Dozens of
thread/resumeattempts within a few seconds for the same thread, each re-attempting auth — which likely amplifies the token churn.Same non-fixes as others: cleared the models cache, reset
~/.codex/auth.json, and logged out of all devices. A fresh login completes and refreshesauth.jsonnormally, but resuming an old conversation reproduces the drop.totkd commentedon Aug 19, 2026
One additional data point on Advanced Account Security: I also enabled AAS only recently, shortly before encountering this regression.
I have not established that AAS is causal, and I have not compared pre-AAS vs. post-AAS threads systematically. But given your observation above, I thought the timing might be worth recording in case affected users share an account-state or migration-related characteristic.
43 remaining items
richcn commentedon Aug 25, 2026
I'm experiencing the same issue on Windows after enabling Advanced Account Security.
Environment:
26.818.8289.0(x64)0.149.0-alpha.4.3I enabled Advanced Account Security because my account has access to the Daybreak Blue model, so disabling Advanced Account Security is not really a viable workaround for me.
The browser authentication itself completes successfully, and Codex initially recognizes the account:
However, shortly afterwards Codex receives a 401 while the access token is still present:
About one second later, the authentication state changes to:
This is then followed by:
and:
The Codex Desktop app then signs me out and returns to the login flow.
So in my case the sequence appears to be:
I can reproduce this consistently. The Passkey/browser authentication itself does not appear to be failing; the session is lost only after Codex has already successfully authenticated.
This started after enabling Advanced Account Security.
I can provide the complete Codex Desktop logs if they would help diagnose the token refresh/session handling issue.
totkd commentedon Aug 26, 2026
26.820.60940 / build 7119 still reproduces; brand-new thread creation is affected too
I tested the current macOS Stable release
26.820.60940(build7119) on the same Mac/account that remains stable on26.810.52044(build6662).On build
7119:The logs show that the thread operations succeed before authentication collapses.
For an existing thread:
For the brand-new thread:
In the relevant reproduction window, I did not observe
refresh_token_invalidatedortoken_revoked; the/accounts/{account_id}/settings401 was followed directly byauth_token_missing.I then rolled back only the application bundle to
26.810.52044(build6662), without clearing~/.codex, local task data, Keychain, or browser cookies, and without changing AAS or account/workspace state.Importantly, I then reopened the same Codex Spark thread that had just triggered the sign-out on build 7119. On build 6662, that exact thread resumed normally and accepted multiple additional turns while the account remained signed in.
So on the same machine/account/thread data:
This further weakens both:
In this A/B test, the thread data remained in place and changing only the Desktop application bundle back to build
6662made the same affected thread usable again.maojianzhong999 commentedon Aug 26, 2026
Reproduced on the newer production build 26.820.60940 (Build 7119) with bundled
codex-cli 0.150.0-alpha.8, on macOS 26.5.2 (25F84), arm64, using a personal ChatGPT Plus account.The original reproduction remains exact: browser OAuth completes successfully, the account is initially present, and clicking any existing conversation immediately returns the app to the browser sign-in screen.
Additional endpoint isolation with the same freshly issued, unexpired token:
The fresh login sequence records:
Opening an existing thread then records:
The bundled CLI remains authenticated and real Codex CLI model calls succeed on the same machine/account/network. Rebuilding the Electron profile, upgrading to 26.820.60940, and completing a new OAuth login with the updated bundled runtime do not change the result.
This further supports the regression being caused by the desktop client calling a workspace-only settings endpoint for a personal subscription and treating that endpoint-specific 401 as a global auth failure. Tokens, email, account ID, device IDs, conversation IDs, and project names are intentionally omitted.
s1n9t9b9r commentedon Aug 26, 2026
After changing the email address associated with my ChatGPT account, the ChatGPT macOS app entered a persistent authentication loop.
When I open Codex, the app asks me to log in. I complete the authentication flow successfully in the browser using my new email address, but after being redirected to the macOS app, the session is not established or persisted. Codex immediately displays the login screen again. Repeating the process produces the same result, so Codex is currently inaccessible.
ChatGPT works correctly in the web browser with the new email address. The problem appears to be isolated to the macOS desktop app and started immediately after the account email change.
Possible technical cause: the desktop client may still have an authentication token, cached account identifier, or refresh-token binding associated with the previous email address. The browser login succeeds, but the returned OAuth session may not replace or reconcile the stale local authentication state.
Expected behavior:
After successful browser authentication, the callback should return to the ChatGPT macOS app, update the locally stored credentials, and open Codex under the existing account.
Actual behavior:
The authentication appears to complete, but the app returns to the login screen and starts the login flow again.
I have already confirmed that I can access the same account through ChatGPT on the web using the new email address. Please investigate whether email-address changes can leave the macOS app with stale account or session data, and advise how I can fully reset the desktop authentication state without losing my existing Codex chats or projects.
mufeiyu-ayu commentedon Aug 26, 2026
me too,
geegewu commentedon Aug 26, 2026
Current production build 7119 still breaks active work — this needs urgent prioritization
I am independently reproducing this on:
26.820.60940(build7119)26A5416b), Apple SiliconThis is not a cosmetic login inconvenience. The desktop app can switch to the sign-in screen while Codex is actively working. The only reliable immediate recovery is to fully quit and reopen the application, which interrupts the workflow and makes the desktop client unreliable for ongoing work.
The underlying credential is not actually gone:
My sanitized Desktop logs show the same failure chain reported here:
After quitting and reopening the app, the account is available again without repairing the CLI login. That strongly indicates the Desktop runtime is discarding or hiding a valid authenticated state after a route-scoped authorization failure.
It is unacceptable for a production desktop client to convert a workspace-only endpoint error into a global logout, especially during an active agent task. Users should not have to repeatedly restart a paid product to keep working, and repeatedly signing in is not a reasonable workaround because it can create duplicate device sessions without addressing the underlying failure.
This regression has now survived multiple production builds and has many independent reports. Please treat it as a high-priority release blocker rather than a generic authentication issue.
At minimum, the fix should:
401into global authentication loss.I have intentionally omitted account IDs, thread IDs, tokens, and project information.
lynnswap commentedon Aug 26, 2026
I have some additional findings and a recovery case to share.
Environment
thread/resumecompleted successfullyA complete local reset did not resolve the issue
I removed the following state, then reinstalled the app and signed in again, but the same issue remained:
~/.codexEach new sign-in reached
account_login_completed success=true. However, opening an existing thread caused the authentication state to disappear within a few seconds.The observed sequence was:
Subsequent requests were sent without a token and returned:
Replacing auth.json with credentials issued under a separate CODEX_HOME resolved the issue
Another local tool on this Mac runs the Codex app-server with an isolated
CODEX_HOME:These credentials were issued for the same ChatGPT account through an independent OAuth session using the Codex 0.147.0 app-server.
Copying this file, containing credentials for my own account, to the following location immediately resolved the issue:
Warning
auth.jsoncontains a refresh token. It must never be obtained from another person, attached to an issue, or otherwise shared. In this case, both files belonged to the same local user and the same ChatGPT account; they were generated under two separate localCODEX_HOMEdirectories.After comparing the two files without exposing any secrets, I confirmed that they had the same:
account_idauth_mode=chatgptHowever, the ID token, access token, and refresh token were all different. In other words, they represented separate token families for the same account.
After the copy, ChatGPT Desktop successfully refreshed
~/.codex/auth.jsonitself and persisted newly rotated access and refresh tokens. This makes a file-permission problem, write failure, or malformed JSON unlikely to be the sole cause.What changed after replacing the credentials
The
/backend-api/accounts/{account_id}/settingsrequest still returns 401, but its response is now:This appears to be an authorization error caused by calling a workspace-only endpoint for a personal account.
The important difference is that authentication now remains intact after this 401. The later
auth_token_missingandaccount_info_token_unavailableevents no longer occur.At least in this environment, the failure therefore appears to involve these two interacting behaviors:
I could not determine why the refresh token issued through the normal Desktop sign-in path became unusable so soon after a successful login. The original
auth.jsonwas overwritten during recovery, and the refresh endpoint's response body was not retained in the Desktop logs available to me.However, a separate token family issued for the same account through another OAuth session could be refreshed and persisted successfully by the same Desktop build, on the same machine and network, while opening the same thread.
This result suggests that the problem is more likely related to the Desktop OAuth sign-in/refresh path, or to its handling of a workspace-only 401 as an authentication failure, than to stale application data or the local thread itself.
turgur commentedon Aug 27, 2026
TL;DR
If you get a
401log out when opening existing chats, normal app logouts or deleting local files won't help.The Fix: Go to your ChatGPT web account, use “Log out of all sessions/devices”, and sign back in.
Workaround that fixed this for me
I was seeing a reproducible logout in the ChatGPT/Codex desktop app when opening an existing conversation.
The failure sequence in the desktop logs was:
I tried the following without success:
~/.codex/auth.jsonWhat finally fixed it was using “Log out of all sessions/devices” from the ChatGPT web account, then signing in again.
After the global server-side logout and fresh login, existing conversations open normally and the desktop app no longer immediately logs me out.
So if you're seeing the same
401 → auth_token_missingsequence, try a global logout of all sessions, not just a normal desktop logout or terminating individual active sessions.This suggests the issue may involve stale/inconsistent server-side auth/session state rather than only local
auth.jsonor Electron storage.Update: I also have Advanced Account Security (AAS) enabled, and it was enabled before I installed Codex.
This makes my case consistent with the AAS-related reports in #40611. Notably, the global “Log out of all sessions/devices” workaround still fixed the issue.
stoimenov95 commentedon Aug 27, 2026
This resolved it on my side as well, thanks OP!
tokezooo commentedon Aug 27, 2026
that worked thanks!
Roarrk commentedon Aug 28, 2026
New version deployed today have solved the issue for me.
chunguscodes commentedon Aug 28, 2026
New version is also working for me.
efraim9 commentedon Aug 28, 2026
New version solved the issue for me as well.
aravhawk commentedon Aug 29, 2026
Version 26.825.41651 has resolved the issue for me
mikeg0 commentedon Sep 25, 2026
hit this bug today on codex-cli 0.157.0. turns out codex had spawned some processes that went zombie on a long batch job I was running. killing these zombies and re-authing fixed it for me.