[macOS][26.814.41407] Opening an existing conversation invalidates ChatGPT auth and redirects to sign-in

Confirming this reproduction on another machine (macOS arm64).

• App: ChatGPT desktop (bundle id com.openai.codex), version 26.814.41407 (build 6720), Apple Silicon
• Auth: ChatGPT account (auth_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=true
• sa_server_request_failed … "Missing valid access token or actor biscuit" … /accounts/{account_id}/settings … status=401
• getAuthStatus … hasToken=false nullReason=auth_token_missing

After that the app drops the cached token (hadToken=false skipRetryReason=no_token_attached) and /wham/tasks/list returns 401 every ~60s, driving the sign-in redirect loop.

Already attempted (no fix): deleted/regenerated ~/.codex/auth.json and did a fresh device login — OAuth refresh now succeeds (refresh_token_invalidated no 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.

Same problem here. Same platform.

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.

• App 26.814.41407 (build 6720), auto-updated 2026-08-18 13:03Z. First desktop_fetch_auth_401 appears 16 minutes later (13:19:56Z) — hadToken=true on /accounts/:param/settings, then hadToken=false skipRetryReason=no_token_attached tokenSource=cached for everything after, same sequence @kent8192 posted above.
• Marker counts in ~/Library/Logs/com.openai.codex/: 0 occurrences across Aug 5–17 logs, 196 since the update.
• account_login_completed logged 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/list call 401s and the sign-in sheet reappears.
• No effect from: full reset, repeated re-login, app/OS restarts. Keychain (Codex Safe Storage) and cookie stores verified intact. codex CLI on the same machine is unaffected — ~/.codex/auth.json refreshes normally (it was last refreshed by the desktop app mid-loop, so OAuth itself is healthy).

Happy to provide fuller logs if useful.

same issue. Macbook air m5

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):

04:01:45 account_login_completed success=true
04:01:50 existing conversation restored
04:01:52 desktop_fetch_auth_401 hadToken=true GET chatgpt.com/backend-api/accounts/:param/settings
04:01:53 sa_server_request_failed {"detail":"Missing valid access token or actor biscuit"}
04:01:53 auth_status_result hasToken=false nullReason=auth_token_missing
04:01:55 desktop_fetch_auth_401 hadToken=false no_token_attached GET .../wham/:param/:param
04:02:48 same on /wham/tasks/list; recurs ~every 60 s → sign-in screen

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 openai/codex#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.

I am now also experiencing this issue.

I found a workaround that resolved the issue for me:

1. Sign out of the older Codex desktop app.
2. In ChatGPT Web, sign out all currently registered Codex devices.
3. Sign out of ChatGPT Web as well.
4. Update the Codex desktop app to the latest available version.
5. Sign in again.

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.

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

• Reproduced on desktop 26.814.41407 (build 6720) and 26.814.41957 (build 6744).
• Not reproduced after rollback to signed desktop 26.727.51351 (build 6119).
• Switching only the app-server/CLI to stable 0.148.0 did 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:

GET /backend-api/wham/usage
-> 200 OK (personal plan_type: pro)

GET /backend-api/accounts/<personal-account>/settings
-> 401 {"detail":"Must use workspace account for this operation"}

The selected historical thread had already completed thread/resume successfully. The settings 401 was then handled by the generic authenticated-fetch retry path, followed by a forced auth refresh; the observed state sequence ended in refresh_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}/settings and selects usage_limit_increase_request. For a non-owner/non-admin account, the hook is enabled when any of the following are true:

showWorkspaceUsageLimit || workspaceSpendControl || pricePlan != null

pricePlan is 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:

showWorkspaceUsageLimit || workspaceSpendControl || rateLimitWarningThreshold != null

The personal paid-plan pricePlan condition was absent, and the workspace settings request was not made.

Rollback validation

After rollback and a fresh login, I opened four different historical sessions:

• 4/4 thread/resume calls succeeded.
• 0 requests to /accounts/<account>/settings were emitted.
• 0 desktop_fetch_auth_401, token invalidation, or hasToken=false events occurred.

The app remained signed in. This was with the same machine, account type, local sessions, network, and stable Codex core.

Suggested fix

1. Gate the settings query on an actual workspace account (account.structure === "workspace" or equivalent), not on pricePlan being present.
2. Do not globally clear/refresh authentication for a 401 from an account-scoped resource when the bearer token remains valid for Codex/usage endpoints.
3. Treat the expected personal-account rejection locally and default usage_limit_increase_request to unavailable.
4. Add a regression test for resuming history with a personal paid ChatGPT account.

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.

Additional independent reproduction, with one UI observation that may be relevant to the workspace-account analysis above.

• MacBook Pro (Mac14,7), M2, 16 GB
• macOS 27.0 (26A5416b)
• 26.810.52044 / build 6662: works
• 26.814.41407 / build 6720: sign-out loop
• 26.814.41957 / build 6744: same sign-out loop
• rollback to 6662: works again immediately

During 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.

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:

warning [AppServerConnection] app_server_connection.auth_status_result authMethod=chatgpt cacheWrite=null hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

warning [AppServerConnection] app_server_connection.auth_status_result authMethod=chatgpt cacheWrite=null hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

A few additional details:

• Version: 26.814.41407
• Re-signing in temporarily restores access
• New conversations seem fine so far
• Opening an existing conversation appears to reproduce the logout/auth failure
• The first logout happened before I manually removed any active session from my OpenAI account, so session removal was not the cause

The refreshToken=true together with hasToken=false / auth_token_missing seems especially relevant.

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 of thread/resume for 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:

resume_thread_with_history:thread_spawn: Failed to create session:
  thread-store conflict: thread <id> already has an active session
session_init: failed to initialize thread persistence: thread-store conflict: thread <id> ...

Dozens of thread/resume attempts 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 refreshes auth.json normally, but resuming an old conversation reproduces the drop.

the affected threads all predate enabling account "advanced security," though that may just be because those are the old ones.

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.

Same issue on MacOS... making Codex completely unusable on my £200/mth subscription...
Recently enabled Advanced Account Security few days ago BUT only started happening since the latest update yesterday.

This issue also occurs when the advanced account security features are not enabled.

Confirming on the same build, and I can extend the repro: it isn't only existing conversations — sending the first message in a brand-new thread does it too.

Environment: ChatGPT/Codex Desktop 26.814.41407 (Released Aug 17, 2026), macOS 26.4.1 (Tahoe), MacBook Pro, Apple M5 Max, arm64.

I updated onto this build from your known-good and broke immediately

2026-08-10T18:34:04.477Z [sparkle] action=check_completed  currentBuildNumber=6119 result=update_available
2026-08-13T02:41:20.285Z [sparkle] action=install_started  currentBuildNumber=6119
2026-08-17T02:48:26.324Z [sparkle] action=install_started  currentBuildNumber=6415
2026-08-20T03:58:05.533Z [sparkle] action=install_started  currentBuildNumber=6662   <-- onto 26.814.41407

6662 is 26.810.52044 — the build you rolled back to. I ran 6119/6415/6662 through heavy daily use with zero auth failures in the logs, then auto-updated at 03:58Z and the loop started the same hour.

New-thread repro, captured live

I reproduced this deliberately a few minutes ago. Full sequence, ~/Library/Logs/com.openai.codex/:

05:17:38.417Z info    [AppServerConnection] response_routed ... method=thread/start
05:17:39.194Z error   [electron-message-handler] Received turn/started for unknown conversation
05:17:41.544Z info    [ephemeral-generation] ephemeral_generation_token_usage feature=thread_title
05:17:42.477Z warning [electron-fetch-wrapper] desktop_fetch_auth_401 hadToken=true skipRetryReason=null
              target="GET https://chatgpt.com/backend-api/accounts/:param/settings"
              tokenSource=cached willRetry=true
05:17:42.660Z warning [AppServerConnection] app_server_connection.auth_status_result
              authMethod=chatgpt cacheWrite=null hasToken=false nullReason=auth_token_missing
              refreshToken=true tokenExpiryState=missing
05:17:42.673Z info    [electron-message-handler] chatgpt_conversation_updates_subscription_unmounted
05:17:42.741Z warning [electron-fetch-wrapper] desktop_fetch_auth_401 hadToken=false
              skipRetryReason=no_token_attached target="GET .../backend-api/wham/:param/:param"

New thread → send message → 1.6 seconds later the settings 401 lands, the forced refresh empties the token, and the subscription unmounts. No existing conversation involved. Suggest widening the title, since "opening an existing conversation" undersells it — any authenticated turn seems to do it.

Earlier cycles were the same but even faster on re-login: signed in at 04:58:20, dead at 04:58:59 (39s); signed in again at 04:59:11, dead at 04:59:19 (8s). 16 account_login_completed events in one evening, 4 of them success=false.

The refresh is rejected server-side, which is why local resets don't help

From codex_login::auth::manager:

Failed to refresh token: 401 Unauthorized: {
  "error": {
    "message": "Your refresh token has been invalidated. Please try signing in again.",
    "type": "invalid_request_error",
    "code": "refresh_token_invalidated"
  }
}

and concurrently on background app/read:

"message": "Encountered invalidated oauth token for user, failing request",
"code": "token_revoked",
"status": 401

token_revoked, not expired — the server kills the token family, so every fresh login gets torn down on its first refresh. That should explain why clearing Electron storage and recreating ~/.codex/auth.json do nothing.

Daily counts across my logs:

| | Aug 10–19 (builds 6119/6415/6662) | Aug 20 (26.814.41407) |
|---|---|---|
| refresh_token_invalidated | 0 | 2 |
| token_revoked | 0 | 12 |
| account_login_completed | 0 | 16 |

On the Advanced Account Security theory

I enabled AAS ~40 minutes before this update landed, so on my machine the two are confounded — but lim1s notes above that this reproduces with AAS disabled, which I think settles it. For what it's worth, my one pre-update token loss (03:57:21Z, still on 6662) was a 401 on /wham/tasks/list, not the settings endpoint, and it recovered on re-login; the settings-401 loop starts only after 03:58. #39581 reports these same symptoms and attributes them to AAS — we're both on 26.814.41407, so that's likely this bug. Cross-linking so the two don't get diagnosed separately.

Rolling back to 6662 next. Happy to supply fuller logs or test a candidate build.

I enabled AAS yesterday and the errors just started for me this morning. Completely unable to use the app.

Confirmed: this regression is still present on a newer desktop build, and an A/B rollback fixes it on the same machine/account.

Environment

• ChatGPT/Codex Desktop 26.818.21641 (build 6849)
• macOS 27.0 (26A5378n), Apple Silicon (arm64)
• Personal paid ChatGPT account
• ChatGPT account authentication

Reproduction and exact state transition

1. Start authenticated; conversation/task lists are available.
2. Switch to an existing Codex task.
3. thread/resume succeeds.
4. About 2.6 seconds later the renderer requests the account-scoped settings endpoint and gets a 401.
5. The running app clears its live access token and presents the signed-out UI even though the persisted refresh credential remains.

Sanitized sequence from one reproduction (UTC):

08:00:54.992  thread/resume succeeded
08:00:55.011  maybe_resume_success
08:00:57.636  desktop_fetch_auth_401 hadToken=true
                 GET /backend-api/accounts/:account/settings
                 tokenSource=cached willRetry=true
08:01:00.492  auth_status_result hasToken=false
                 nullReason=auth_token_missing refreshToken=true
08:01:00.811  authenticatedAccountPresent=false
                 failureType=account_info_token_unavailable
08:01:01.722  subsequent authenticated requests haveToken=false
08:01:06.018  /wham/tasks/list -> 401

The strongest behavioral clue is that Cmd+Q followed by reopening the app restores the same account immediately without another OAuth login. That is consistent with the persisted refresh credential remaining valid while the renderer/auth bridge has cleared or stranded only the running process's access-token state.

Local causes ruled out by recurrence

The failure recurred after fresh logins and after changing or disabling each of the following: file-backed vs Keychain/encrypted credential storage, Remote Control, Computer History/Chronicle, Advanced Account Security, and the ChatGPT Chrome extension/native host. Those were correlations or mitigations, not durable causes.

Same-machine A/B rollback

I rolled back to the official OpenAI-signed and notarized desktop 26.810.52044 (build 6662) while preserving the same account, local tasks, configuration, and machine state. I then switched through:

• the exact historical Codex task that triggered the failure;
• another historical Codex task;
• a regular ChatGPT chat;
• and back to the active Codex task.

Results on build 6662:

• all tested task resumes succeeded;
• the same Desktop/app-server process remained alive;
• codex login status remained Logged in using ChatGPT;
• no actual /accounts/:account/settings request was emitted;
• zero desktop_fetch_auth_401 events;
• zero auth_token_missing results;
• zero authenticated-account drops or refresh-token invalidations.

This confirms the regression also affects 26.818.21641, while rollback to 26.810.52044 removes the failing request and the logout on the same setup.

Expected fix

1. Gate /accounts/{account_id}/settings on an actual workspace account, not merely the presence of a personal paid plan.
2. Do not treat a resource-level/account-scope 401 as global bearer-token failure when Codex/usage endpoints still accept the token.
3. Keep the persisted and in-memory auth state coherent across task activation.
4. Add a regression test for switching/resuming tasks with a personal paid ChatGPT account.

No tokens, account IDs, emails, private task contents, or unredacted logs are included.

@Roarrk try to revert to an olde build, thats the only thing that worked for me, go through my comment above to get more details.

Also I too had enabled AAS a few days ago, but then disabled it and started having these issues. Enabling it again did not solve the problem.

I can reproduce what appears to be the same logout loop on ChatGPT/Codex desktop 26.814.41407 on macOS 26.6. I had just enabled Advanced Account Security, which correctly signed out my existing sessions; after signing in again, Codex continues to authenticate successfully on my remote machines, but the local desktop app logs me out immediately when I send a message to a remote task. The trigger is therefore not only reopening an older conversation: sending a task message can also cause the active desktop session to disappear.

Day-two update from my account. I know this issue has attention and that these fixes take time. I’m adding the current-build result and one useful client-path distinction so the exact failure remains visible.

Today’s update to ChatGPT/Codex Desktop 26.818.21641 (build 6849) did not change the local Mac behavior. I reproduced the same sequence on two different prior threads:

thread/resume → account-settings 401 while hadToken=true → refresh_token_invalidated / auth_token_missing → sign-in

Passkey and USB hardware-key authentication both complete successfully. The app returns signed in, but opening another prior thread repeats the loop.

For this account, prior-thread work in the Mac desktop app therefore remains fully blocked. New threads remain usable.

A useful boundary:

• The current ChatGPT iOS app on iOS 27 Developer Beta 4 can use Remote against this same affected MacBook Pro.
• Every thread I have tested through iOS Remote remains accessible, including prior threads that trigger the Mac desktop loop.
• Remote does not produce a sign-in loop on the phone or visibly force the Mac desktop app back to sign-in.
• After the final successful desktop login, the active Mac log continued through 15:13:32 UTC with no new desktop_fetch_auth_401, auth_token_missing, or refresh_token_invalidated markers.

This appears different from the report above where the Mac desktop app signs out when that desktop UI sends a message to a remote task. In my test, the initiating client is iOS Remote. Both results may be valid and may help isolate which client path invokes the failing account-settings request.

I know this is already receiving attention. I mainly want to make sure this exact current-build path remains visible as a full blocker for affected accounts. I’m happy to test a supported candidate build when one is available.

I can confirm a closely matching regression on another Apple Silicon Mac, with one additional account-state observation that may help narrow the trigger.

Subscription-state observation

The desktop app appeared to work normally while the account was on the Free tier. After Plus access became active, the forced sign-out began reproducing consistently.

This is only a correlation from one affected environment—not proof that Plus is the sole cause—but it may indicate that a paid personal-account settings path triggers the regression.

Reproduction

1. Sign in successfully to the macOS desktop app.
2. Open a new or existing Chat conversation.
3. Send a message.
4. The response is generated successfully.
5. As the response completes, the app returns to the login screen.

The app can remain open while idle without signing out. Interaction with a conversation triggers the problem.

Web and Android continue to work normally with the same account, indicating that the issue is limited to the unified desktop client.

Sanitized diagnostic pattern

account lookup: authenticated
account settings request: HTTP 401
authentication status: token missing
account lookup: token unavailable
Unauthorized
Missing valid access token

No account identifiers, tokens, conversation identifiers, IP addresses, local paths, or original log files are included.

Reinstalling the current desktop version, resetting local state, and performing a fresh sign-in did not resolve the problem.

Workaround confirmed

Rolling back the desktop app to the official signed version 26.810.52044 resolved the issue immediately. Plus remained active, conversations worked normally, and the app stayed authenticated after responses completed.

This appears consistent with the account-settings/authentication behavior described in #39189. The Free-to-Plus state change may be an additional condition worth testing.

@Roarrk try to revert to an olde build, thats the only thing that worked for me, go through my comment above to get more details.

Thanks @AryanRG. I am temporarily using the codex-cli tool, that one works too.

And just for a heads up, the newest chatgpt app update just pushed now still has the same bug for me - also after re-authing.

Same-machine rollback confirmed: exact Apple Silicon package and procedure

I completed a controlled same-machine rollback on August 20, 2026. ChatGPT Desktop 26.810.52044 (build 6662) is working normally on the same Mac, account, browser session, local tasks, configuration, security settings, and network environment where builds 6720, 6849, and 6872 failed.

This comment records the exact procedure I followed. It is not an official OpenAI rollback instruction or a general recommendation for other platforms.

Personal and Team account clarification

During troubleshooting I encountered the Personal/Team account chooser. That makes account structure or multi-account state a possible contributing condition, but I do not think the evidence establishes that having two accounts is required.

Reports in #39189 include the same failure on personal, non-workspace accounts, including reports from users with only one account. Some users recovered after clearing a browser multi-account session, while that procedure did not work universally.

In my case, rollback succeeded without:

• removing or changing either the Personal or Team option;
• changing account or workspace membership;
• signing out of ChatGPT in the browser;
• clearing browser cookies or site data;
• changing the subscription;
• changing Advanced Account Security or registered security keys;
• or performing another authentication-state reset.

Static bundle comparison also found the account-settings endpoint and fallback logic in working build 6662. I am therefore not claiming that the endpoint itself was newly added in build 6720.

What is confirmed is the runtime difference. The newer builds actually entered the failing account-settings/authentication path on this machine. During the bounded rollback acceptance test, build 6662 did not.

The two-account state is a possible trigger or modifier. It is not a confirmed root cause.

Environment

• Date tested: August 20, 2026
• MacBook Pro: Mac16,5
• Processor: Apple M4 Max
• Architecture: Apple Silicon arm64
• macOS: 27.0
• macOS build: 26A5416b
• First observed failing desktop release: 26.814.41407, build 6720
• Later failing release: 26.818.21641, build 6849
• Latest failing release tested: 26.818.22352, build 6872
• Working rollback release: 26.810.52044, build 6662
• Working bundled Codex CLI: 0.148.0-alpha.9

Exact package downloaded

Official OpenAI Apple Silicon ZIP:

https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-arm64-26.810.52044.zip

Package verification:

• Target release: 26.810.52044
• Build: 6662
• Bundle identifier: com.openai.codex
• Architecture: Apple Silicon arm64
• ZIP size: 589,942,003 bytes
• ZIP SHA-256: 7a5923dab8fcce2ac451de6e9e47fdb314fba01e02e83ab3e7a228382f4b27bf
• Signing authority: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
• Team identifier: 2DC432GLL2
• ZIP integrity test: passed
• Deep code-signature verification: passed
• Gatekeeper assessment: accepted
• Notarization validation: passed

The installed application’s app.asar SHA-256 matches the same file inside the verified ZIP:

6e7e8791b8bf69a586ff994721fff518af391d9efdc66cd2e620dd2a4aedc90f

Exact macOS procedure followed

1. Downloaded the official Apple Silicon ZIP into a separate staging folder.
2. Verified the ZIP size, SHA-256, integrity, application version, build number, bundle identifier, architecture, OpenAI signing authority, Team ID, Gatekeeper acceptance, and notarization before changing the installed application.
3. Extracted the verified ChatGPT.app into the staging folder.
4. Fully quit ChatGPT using Command-Q. Closing the application window was not treated as sufficient.
5. Right-clicked ChatGPT and selected Stop Running in Background.
6. Only after completing both quit actions, opened /Applications in Finder.
7. Dragged the installed ChatGPT.app, version 26.818.22352 build 6872, from /Applications to Trash.
8. I did not overwrite the newer application and did not select a Replace operation.
9. I did not empty Trash. The newer build remains recoverable there.
10. Dragged the verified 26.810.52044 ChatGPT.app from the staging folder into /Applications.
11. Launched ChatGPT from /Applications, not from the ZIP or staging folder.
12. Confirmed that the installed application reports release 26.810.52044, build 6662.
13. Opened previously affected existing tasks and allowed responses to complete.
14. Switched between existing Codex tasks and normal ChatGPT conversations to confirm that authentication remained stable.

I did not run an uninstaller. This was a clean application-bundle swap.

I did not delete, replace, or clean:

• ~/Library/Application Support/Codex
• ~/.codex
• ~/Library/Logs/com.openai.codex
• macOS Keychain entries
• browser cookies or OpenAI browser sessions
• local task or conversation data
• account or workspace membership
• Advanced Account Security settings
• registered passkeys or hardware security keys

Result

• The existing authenticated account was recognized after launch.
• Previously affected existing tasks resumed successfully.
• Normal ChatGPT conversations worked.
• Responses completed normally.
• The same desktop process remained usable.
• The account remained authenticated after responses completed.
• codex login status reports Logged in using ChatGPT.
• The installed desktop application remains 26.810.52044, build 6662.
• The newer 26.818.22352, build 6872, application remains preserved in Trash.
• In the bounded rollback acceptance window, there were zero actual /accounts/:account/settings requests.
• There were zero actual desktop_fetch_auth_401 events.
• There were zero auth_token_missing results.
• There were zero authenticated-account drops or refresh_token_invalidated events.

This is a strong same-machine A/B result because the application bundle was the controlled variable. The account, Personal/Team options, browser session, Keychain, local tasks, security settings, and network remained in place.

It confirms that official signed build 26.810.52044 is a working rollback on this Apple Silicon Mac. It does not prove that Personal/Team multi-account state causes the regression.

The remaining engineering questions are:

1. What activates the account-settings path in builds 6720 and later when it remains inactive in the tested 6662 path?
2. Is the trigger a client feature gate, remote flag, account-state timing condition, bundled Codex-core change, browser-grant condition, or another account-specific state?
3. Why can a resource-level or account-scope 401 trigger global token refresh and invalidate an otherwise working authenticated session?
4. Does the failure reproduce independently with personal paid accounts both with and without Team membership or browser multi-account state?

The client should gate workspace settings on a confirmed workspace account and should not treat a route-specific authorization failure as proof that the entire authenticated session is invalid.

Same problem here. Extremely annoying.

same here

Additional evidence: exact workspace rejection and misleading “Admin config” provenance

Confirming the same regression on current macOS desktop 26.818.22352 (build 6872) with a personal ChatGPT Pro account. To avoid repeating the detailed build-6872 timeline and rollback procedure already posted above, these are the new machine-specific findings:

Proven

• On the failing account-settings request, the backend response was exactly:

``text
401 {"detail":"Must use workspace account for this operation"}
``

The client then changed to hasToken=false, nullReason=auth_token_missing, and authenticatedAccountPresent=false. This is an account/route authorization rejection being escalated into global authentication loss.

• Sanitized access-token claims identify a personal Pro account and contain no workspace ID.
• This Mac has no DEP/MDM enrollment, no OpenAI managed preference or managed requirements.toml, and no forced login method or forced ChatGPT workspace ID.
• A direct app-server configuration read returned only the user configuration and an empty system layer; it returned no enterpriseManaged layer.
• A one-release rollback to 26.814.41407 (build 6720) still failed. A deeper rollback to signed 26.730.61639, preserving the account and conversation data, loaded multiple existing conversations with zero account-settings 401s, zero auth_token_missing events, and no logout.

UI implementation finding

The affected app also displays a locked Admin config scope in Agent defaults. Static inspection of the current renderer shows that this scope is used not only for actual Enterprise/MDM/legacy-managed layers, but also for internal sessionFlags; all are presented with the same “Admin config” label and read-only message.

Given the live configuration result above, that label is not evidence that this personal account belongs to an Enterprise workspace.

Inference

These facts support the paid-personal-account/workspace-settings trigger described earlier in the thread. The robust fix should gate the settings route on a confirmed workspace account and must not invalidate global authentication for a route-scoped 401. The UI should also distinguish internal session flags from genuine administrator policy.

No account IDs, conversation IDs, tokens, emails, local paths, or private conversation content are included.

same

Production build 6892 still reproduces the auth loop

I tested the newest public production Apple Silicon release, 26.818.31338 (build 6892), published on 2026-08-20 at 22:29:38 UTC. This was the same clean application-bundle swap used for the controlled rollback, with the same Mac, account, browser session, local tasks, configuration, security settings, registered keys, and network.

Build 6892 did not fix the regression. The current local log contains three unique cycles of:

GET /backend-api/accounts/:param/settings
desktop_fetch_auth_401 hadToken=true
auth_token_missing
authenticatedAccountPresent=false
refresh_token_invalidated
later requests: no_token_attached

Two fresh recurrences followed successful login-completion events:

• login success at 13:42:50.739Z → settings 401 at 13:43:04.705Z
• login success at 13:45:23.052Z → settings 401 at 13:45:32.002Z

I deliberately made two manual reauthentication attempts, passkey first and physical hardware security key second, with an intentional wait between them to avoid the rapid-attempt / spinning-Continue behavior seen previously. Both returned to the visible local authentication loop.

The desktop log records login completion but not factor type, and the full launch interval contains three account_login_completed success=true records. I therefore cannot responsibly map a specific factor to each timestamp. This still shows that the factor itself is not the demonstrated failure point: authentication completes before the account-settings and token-loss sequence.

A final login completed at 13:49:19.456Z, followed by authenticatedAccountPresent=true at 13:49:20.988Z. No later matching local failure marker appeared through the reviewed cutoff at 13:56:52.906Z. I nevertheless remained on the local authentication-loop surface and used Remote to continue the diagnostic session. The visible loop is my observation; the bounded marker absence is independently confirmed.

Same-machine tested-build matrix:

• 26.810.52044 / 6662: working
• 26.814.41407 / 6720: failing
• 26.818.21641 / 6849: failing
• 26.818.22352 / 6872: failing
• 26.818.31338 / 6892: failing

Every newer production build tested on this Mac after 6662 has reproduced the regression. This does not mean every intermediate published build was tested.

This result still does not establish that having both Personal and Team accounts is required. The most actionable engineering question remains why a route-specific account-settings 401 is escalated into global authentication loss after login succeeds.

Confirming this exact issue persists in ChatGPT/Codex Desktop 26.818.32112 (build 6933).

Environment:

• macOS 26.5.1 (25F80), arm64
• Bundled codex-cli 0.149.0-alpha.4.1

The browser authentication flow completes successfully and the app initially reports the authenticated account present. Opening an existing conversation or beginning a new chat then immediately produces:

desktop_fetch_auth_401 hadToken=true ... /accounts/:param/settings
app_server_connection.auth_status_result ... hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
sa_server_request_failed ... status=401 ... "Missing valid access token or actor biscuit"

The app then returns to the sign-in screen.

Still reproduces after:

• Reinstalling and rebooting
• Clearing bundle-specific Application Support, caches, HTTP storage, cookies, and preferences
• Moving ~/.codex/auth.json aside and completing a completely fresh login
• Confirming the newly issued access and ID tokens are internally consistent and unexpired
• Confirming no managed Codex authentication policy is installed

A /feedback bug report with logs was successfully uploaded on 2026-08-21 at 20:00:04 UTC (HTTP 200, include_logs=true, six attachments).

This extends the report to a newer build and confirms that both existing and new chats trigger the failure.

same issue here

Issue is still happening on latest version, can't use the desktop app on Mac for 3 days now

Additional impact: rollback is overwritten by install-on-quit auto-update

A new user-impact detail from my affected personal Plus environment:

• The last locally verified failing build was 26.818.21641 (build 6849).
• Rolling back to official signed build 26.810.52044 (build 6662) immediately restored normal Chat behavior on the same account and network.
• After the rollback, the desktop updater downloaded a newer build in the background and replaced the working app when it quit.
• Reopening the app reproduced the authentication failure, so I had to roll back a second time and temporarily apply a macOS filesystem immutable flag to the old application bundle to prevent another forced replacement.

This makes rollback an unstable workaround for personal users: leaving the updater enabled restores the broken client, while pinning the old build means remaining on an outdated release without normal security updates.

The controlled result still points to the desktop build rather than general connectivity: Web and Android remain usable with the same account, and build 6662 works under the same local network conditions where newer desktop builds fail.

For accuracy, I did not capture the exact version of the most recent auto-installed build before reverting it, so I am not claiming a personal reproduction on build 6933. That build has been reported separately by another affected user above.

Could an OpenAI maintainer please acknowledge whether this auth regression has been triaged and identify a safe fixed build or a supported update-pause mechanism for affected personal accounts?

No account identifiers, tokens, IP addresses, device identifiers, local paths, or raw logs are included.

same

Cross-account reproduction on build 6962

Environment:

• ChatGPT/Codex Desktop 26.818.41509 (build 6962)
• Bundled Codex CLI 0.149.0-alpha.4.1
• macOS 26.5.2 (25F84), Apple Silicon
• ChatGPT authentication was used for both accounts

Additional reproduction:

1. Existing local Codex sessions were created while Account A was active.
2. After signing into Account B in the same macOS user profile, Account B could see those existing sessions in the Codex sidebar and resume them successfully.
3. After signing back into Account A, selecting the same sessions produced the same sequence reported in this issue: thread/resume, an account-settings 401, auth_token_missing, “Missing valid access token or actor biscuit,” followed by the sign-in screen or “Oops, an error has occurred.”
4. Account B can still resume those sessions, while Account A cannot.

Client-side session files do not prove that server-side ownership was changed. However, this does demonstrate cross-account visibility of local session history and an account-dependent resume/authentication result.

Expected behavior:

• Account B should not be able to resume Account A’s sessions without explicit sharing or importing.
• Switching accounts should not affect Account A’s ability to resume its existing sessions.
• A resource-scoped 401 should not invalidate the application’s global authentication state.
• Please provide a private channel for sharing affected thread IDs and account identifiers for server-side investigation.

No account IDs, email addresses, authentication tokens, actor biscuits, local filesystem paths, conversation content, or complete thread IDs are included in this report.

Production build 6971 still reproduces the auth loop

I tested the current public Apple Silicon release at test time, 26.818.41705 (build 6971), published on 2026-08-22 at 06:11:06 UTC. The installed application confirms that exact release and build, arm64, with bundled codex-cli 0.149.0-alpha.4.1.

Build 6971 does not fix the regression.

I made two manual reauthentication attempts, passkey first and physical hardware security key second, with a pause between them. The desktop log records login completion but does not record factor type, so that factor order is my direct observation.

The first completed login was followed by the same confirmed sequence:

15:39:14.848Z  account_login_completed
15:39:28.154Z  /backend-api/accounts/:param/settings -> 401, hadToken=true
15:39:28.392Z  auth_token_missing
15:39:28.510Z  refresh_token_invalidated
15:39:28.546Z  retry -> 401, no_token_attached

A second account_login_completed event occurred at 15:41:24.012Z, followed 86 ms later by another no_token_attached 401. The local Mac app remained in the authentication loop, while Remote continued to work against the same Mac.

Updated personally tested build matrix:

• 26.810.52044 / 6662: working
• 26.814.41407 / 6720: failing
• 26.818.21641 / 6849: failing
• 26.818.22352 / 6872: failing
• 26.818.31338 / 6892: failing
• 26.818.41705 / 6971: failing

I did not personally test intermediate public builds 6933 or 6962. This result again places the failure after authentication completes, in the local desktop account-settings and token-handling path.

Confirming this still reproduces on 26.818.32112.

Repro

1. Sign in successfully; the app initially appears authenticated and the conversation list loads.
2. Leave the app open without opening a ChatGPT conversation: Remote continues to work normally.
3. Open any existing ChatGPT conversation.
4. The app immediately redirects back to the sign-in screen.
5. Sign in again and open any conversation → same loop.

Additional observations

• I first noticed this shortly after enabling Advanced Account Security. Disabling AAS again did not resolve the issue.
• ChatGPT on the web works normally with the same account.
• Reinstalling the macOS app did not help.
• I fully quit the app and renamed ~/Library/Application Support/Codex so the app created a completely fresh profile, then signed in again; behavior was unchanged.

The fact that Remote remains usable while the app is left idle, and the forced sign-out only occurs when an existing ChatGPT conversation is opened, makes this look more like a failure in the conversation/account-settings auth path than a general loss of authentication.

Happy to provide sanitized logs if useful.

I can reproduce this issue on the latest macOS build 26.818.41705 (build 6971), so the regression is still present several releases after the originally reported build.

One potentially relevant detail: my ChatGPT account has Advanced Security enabled and uses FIDO hardware security keys.

Environment

• macOS / Apple Silicon
• ChatGPT desktop bundle: com.openai.codex
• Affected version: 26.818.41705 (build 6971)
• Known-good version: 26.810.52044 (build 6662)
• Same account works normally in:

• ChatGPT Web
• ChatGPT on Windows
• Codex CLI
• OAuth clients
• A fresh ChatGPT installation inside a macOS VM also works correctly.

Behavior

After launching the macOS app, it initially appears authenticated:

• profile is visible
• settings are accessible
• conversation list is visible

As soon as I open an existing conversation, or a newly created conversation completes, the app immediately switches to the logged-out state.

Quitting and reopening the app makes it appear authenticated again, but opening a conversation reproduces the logout every time.

The model does not matter; this also happens with normal models such as Sol and is not specific to a cyber/Advanced Security model.

Relevant log sequence

Immediately before logout:

[chatgpt-account-lookup]
authenticatedAccountPresent=true
authMethod=chatgpt
result=succeeded

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

Immediately afterward:

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

[chatgpt-account-lookup]
authenticatedAccountPresent=false
failureType=account_info_token_unavailable
result=failed

Subsequent backend requests are then sent without a token:

desktop_fetch_auth_401
hadToken=false
skipRetryReason=no_token_attached

and fail with:

401 Unauthorized
Unauthorized - Access token is missing

Local state troubleshooting

I tested this quite extensively and preserved/renamed data rather than simply deleting it.

The issue remained after independently resetting:

• ~/Library/Application Support/Codex
• ~/Library/Application Support/com.openai.codex
• ~/Library/HTTPStorages/com.openai.codex
• ~/Library/HTTPStorages/com.openai.codex.binarycookies
• ~/Library/Preferences/com.openai.codex.plist
• ~/Library/Caches/Codex
• ~/Library/Caches/com.openai.codex
• Keychain item Codex Safe Storage

I then removed ~/.codex/auth.json.

This caused the desktop app to request a completely fresh login, confirming that ~/.codex/auth.json participates in the desktop authentication path. However, after successful fresh authentication, opening a conversation caused the exact same failure.

Finally, I moved the entire ~/.codex directory out of the way and authenticated from scratch.

The problem still reproduced.

Rollback test

I downloaded the official OpenAI-signed build:

26.810.52044 / build 6662

The application signature is:

Identifier=com.openai.codex
Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
TeamIdentifier=2DC432GLL2

I replaced only the desktop application with this older build.

The problem disappeared immediately.

Existing chats open normally and the application remains authenticated.

Therefore, on this machine/account:

26.818.41705 / 6971  -> broken
26.810.52044 / 6662  -> works

No account, network, FIDO configuration, or machine configuration was changed between those tests.

This makes it look strongly like a regression in the desktop authentication/account-settings flow introduced after build 6662, rather than corrupted local state.

Given the Advanced Security/FIDO enrollment, it may also be worth checking whether /backend-api/accounts/{account_id}/settings behaves differently for Advanced Security accounts and whether the desktop client incorrectly treats that endpoint's 401 as invalidation of the entire ChatGPT authentication state.

Maybe this is mentioned above. Physically logging out of the application and going back in fixed it for me.

Additional context: https://github.com/openai/codex/pull/39214 (e13c1d569d9) makes custom providers without explicit auth send requests unauthenticated, breaking existing API-key configurations with 401 Missing bearer authentication.

Adding requires_openai_auth = true fixed requests to eu.api.openai.com immediately.

The security protection should remain, but Codex needs a migration warning and actionable error instead of silently dropping authentication.

One more workaround / diagnostic data point: switching the macOS default browser before re-authenticating resolved the loop for me.

In my case:

• Default browser was Chrome → ChatGPT desktop login succeeded, but opening any existing conversation immediately sent the app back to sign-in.
• I changed the macOS default browser to Safari.
• Re-authenticated the desktop app through Safari.
• The app then started working normally; existing conversations open without triggering the sign-out loop.

I had already ruled out the desktop profile itself by reinstalling and recreating ~/Library/Application Support/Codex, so this points to the external browser/OAuth handoff or browser-side OpenAI session state as another relevant variable.

Interestingly, another reporter in the thread described the inverse workaround (Safari → Chrome). That suggests this may not be browser-specific; using a different browser with a fresh auth/session state may be what clears it.

No other account or machine configuration was changed between the failing and working login attempts.

One more workaround / diagnostic data point: switching the macOS default browser before re-authenticating resolved the loop for me. In my case: Default browser was Chrome → ChatGPT desktop login succeeded, but opening any existing conversation immediately sent the app back to sign-in. I changed the macOS default browser to Safari. Re-authenticated the desktop app through Safari. The app then started working normally; existing conversations open without triggering the sign-out loop. I had already ruled out the desktop profile itself by reinstalling and recreating ~/Library/Application Support/Codex, so this points to the external browser/OAuth handoff or browser-side OpenAI session state as another relevant variable. Interestingly, another reporter in the thread described the inverse workaround (Safari → Chrome). That suggests this may not be browser-specific; using a different browser with a fresh auth/session state may be what clears it. No other account or machine configuration was changed between the failing and working login attempts.

Thanks for the tip - switching macOS' default browser before auth worked for me, too.

Switching conversations immediately invalidates desktop authentication and signs the account out

I can reproduce this issue consistently on the current macOS build. The core problem is that switching from one conversation to another immediately causes the desktop app to lose its authenticated state and return to the sign-in screen.

Environment

• ChatGPT/Codex Desktop: 26.818.41705 (build 6971)
• Bundle ID: com.openai.codex
• Bundled app-server/CLI: 0.149.0-alpha.4.1
• macOS: 26.5.2, Apple Silicon (arm64)
• Authentication: ChatGPT account

Impact and reproduction

The issue is 100% reproducible for me:

1. Sign in successfully with a fresh ChatGPT device-code authorization.
2. The initial account lookup succeeds and the desktop UI shows the account as authenticated.
3. Switch from the current conversation to another conversation in the sidebar.
4. The desktop app requests GET https://chatgpt.com/backend-api/accounts/:param/settings.
5. That request returns 401; the desktop auth state immediately changes from authenticated to auth_token_missing, and the UI returns to the sign-in screen.

The account is effectively signed out every time I switch conversations. The Codex CLI remains logged in and operational while the desktop UI is signed out.

Sanitized log timeline

17:01:36.336Z [chatgpt-account-lookup] authenticatedAccountPresent=true result=succeeded
17:01:42.488Z [electron-fetch-wrapper] desktop_fetch_auth_401 hadToken=true method=GET url=https://chatgpt.com/backend-api/accounts/:param/settings willRetry=true
17:01:44.130Z [AppServerConnection] hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
17:01:44.149Z [chatgpt-account-lookup] authenticatedAccountPresent=false failureType=account_info_token_unavailable
17:01:44.623Z [electron-message-handler] status=401 error="Missing valid access token or actor biscuit"

The account lookup succeeded with newly issued credentials. Switching conversations then triggered the failure roughly six seconds later.

Additional checks

• Reauthenticated from scratch using device-code OAuth. The fresh login succeeded, but switching conversations still signed the account out within seconds.
• Verified the access token was unexpired, and the token/account claims matched the account used in the failing request. No token or identifier is included here.
• Reproduced the same sequence repeatedly: successful login/account lookup, conversation switch, account-settings 401, auth_token_missing, then the sign-in screen.
• codex login status still reported Logged in using ChatGPT after the desktop UI had signed out.
• codex doctor reported authentication configured, healthy local state/database, successful desktop app-server initialization, and an HTTP 101 WebSocket connection.
• Confirmed there is only one installed ChatGPT/Codex app bundle and its code signature is valid.

Analysis

The triggering action is switching conversations. The credentials are accepted during sign-in and the initial account lookup, but the account-settings request made during the conversation switch returns 401 with Missing valid access token or actor biscuit.

There appears to be a desktop authentication regression in which a single 401 from /backend-api/accounts/:account/settings globally downgrades the desktop auth state to auth_token_missing and signs the account out, even though the CLI and model-provider WebSocket remain authenticated and healthy.

This matches the current-build behavior reported in #40143 and appears to be the same regression tracked by this issue.

Expected behavior

• Switching conversations must not invalidate a valid authenticated session or sign the account out.
• A failure to fetch account settings should not clear the entire desktop authentication state.
• A newly issued, valid ChatGPT authorization should remain usable across conversations.

Please let me know if there is a fixed build to test. I can provide additional account/session identifiers through a private support channel if needed, but I will not post credentials or personal identifiers publicly.

Build 6971: changing the default browser before reauthentication stopped the logout loop

Follow-up to my earlier report that 26.818.41705 (build 6971) still failed through Chrome Dev.

I repeated the clean application-bundle swap to the same official build 6971 on the same Mac. Before reauthenticating, I changed the macOS default browser from Chrome Dev to Safari. I then opened a previously affected existing task, which triggered the expected authentication flow through Safari.

One browser-side detail may be material: Safari initially presented my Business workspace as selected. I explicitly changed the selection to Personal before completing the single authorization. In the earlier Chrome Dev attempts, Personal had already been selected by default. The workspace-selection behavior is my direct observation; the desktop log does not record the browser or selected workspace.

The pre-authentication failure reproduced normally:

17:41:58.850Z  thread/resume
17:41:59.096Z  /backend-api/accounts/:param/settings -> 401, hadToken=true
17:41:59.339Z  auth_token_missing
17:41:59.641Z  authenticatedAccountPresent=false
17:41:59.736Z  retry -> 401, no_token_attached

The Safari authorization then completed:

17:42:22.405Z  account_login_completed
17:42:24.148Z  authenticatedAccountPresent=true

Through the reviewed cutoff at 17:51:14.128Z in the same desktop process:

• 12 thread/resume markers
• 4 maybe_resume_success markers
• 0 non-null thread-resume errors
• 0 auth_token_missing
• 0 refresh_token_invalidated
• 0 no_token_attached
• 0 authenticated-account drops

The account-settings endpoint still returned three additional 401 responses with hadToken=true after the successful Safari login. The important behavioral difference is that those route-level failures no longer cleared the token or signed the desktop app out.

This is a strong within-build result: the same build 6971 that repeatedly failed after Chrome Dev authorization is currently usable after the Safari handoff and explicit Personal selection.

It does not establish that Safari itself is the fix. The changed variables include the external browser session and cookie context, the workspace initially selected by the browser flow, and the explicit Business-to-Personal switch. The inverse Safari-to-Chrome report elsewhere in the thread also suggests that obtaining a fresh browser authorization context may matter more than the browser brand.

This is a confirmed session-level workaround on this Mac, not a product fix. Durability across quit/relaunch or a later token refresh remains unverified.

This is becoming unacceptable.

This regression has been reported for nearly a week, with multiple independent reproductions on macOS and Windows, detailed logs, same-machine A/B rollback tests, and confirmations that it still reproduces on newer Desktop builds.

The failure pattern is extremely clear:

/accounts/{account_id}/settings → HTTP 401
→ Must use workspace account for this operation
→ auth_token_missing
→ account_info_token_unavailable
→ Desktop signs the user out

A valid personal paid ChatGPT account works normally in the browser and CLI, while the Desktop client destroys its own authenticated state after this 401.

Users have already tried reinstalling, clean state, fresh OAuth login, Keychain resets, app restarts, macOS restarts, and other troubleshooting. The only consistently confirmed workaround is rolling back to an older Desktop build.

Yet there is still no visible engineering acknowledgement, no assigned owner, no linked fix PR, no ETA, and no explanation from OpenAI.

At this point, the complete lack of acknowledgement makes it look like OpenAI has no intention of fixing a regression that makes the current paid Desktop product unusable for affected users.

I have also contacted OpenAI Support repeatedly and have not received a substantive answer addressing the actual 401/authentication regression.

Please stop ignoring this issue.

We need an OpenAI engineer to confirm:

• whether this regression is acknowledged;
• whether engineering is actively working on it;
• whether a fix is already in progress;
• and which Desktop build is expected to contain the fix.

Paid users should not have to downgrade indefinitely just to keep authentication working.

In our company we use Codex CLI on OS X with a private Azure cloud. Up the former version I used (I think 0.148.0) this was no problem. After upgrading to v0.149.1) I get:

Unexpected status 401 Unauthorized: Authentication Error, No api key passed in., url: https://**custom-ai-gateway-url**/responses

Searching through the issues I found this issue, as well as the following comment that makes me think the issue is the same:

Additional context: #39214 (e13c1d5) makes custom providers without explicit auth send requests unauthenticated, breaking existing API-key configurations with 401 Missing bearer authentication. Adding requires_openai_auth = true fixed requests to eu.api.openai.com immediately. The security protection should remain, but Codex needs a migration warning and actionable error instead of silently dropping authentication.

codox doctor reports no relevant issues, also not with auth; only one related to MS defender scanning that might interfere.

Downgrading to v0.148.0 (which is quite a hassle with homebrew as only the latest version is served...) solves the problem.

Users have already tried reinstalling, clean state, fresh OAuth login, Keychain resets, app restarts, macOS restarts, and other troubleshooting. The only consistently confirmed workaround is rolling back to an older Desktop build.

More seriously, this forced downgrade now prevents affected users from safely receiving all subsequent Desktop updates, including unrelated bug fixes and improvements. If any of those releases contain security fixes, affected users are effectively being forced to choose between a known authentication regression and remaining on an older build without those patches. OpenAI should explain how users are expected to handle that risk.

In addition: it's even worse; Codex CLI >v0.184.0 is also affected in the same way @totkd describes.

Same issue here, MacBook Air M1, and honestly this bug is unbearable...

same here. fresh macos. mb we should raid Tibo on X with this bug?

i'll start https://x.com/tokezooo/status/2091946644916891929

Reproduced on macOS build 7019 with a clean profile and personal Pro account

Confirming this remains reproducible on a newer macOS build.

Environment

• Codex Desktop: 26.818.61809 (build 7019)
• Bundled Codex core: 0.149.0-alpha.4.3
• macOS on Apple Silicon (M3 Pro)
• Authentication: ChatGPT personal Pro account
• Account metadata returned by ChatGPT: structure=personal, plan_type=prolite, account_user_role=account-owner, is_deactivated=false

Clean reproduction timeline (UTC)

21:51:14  OAuth token exchange succeeded: HTTP 200
21:51:15  account_login_completed; fresh auth.json written
21:51:19  authenticated account lookup succeeded
21:51:29  GET /backend-api/accounts/{account_id}/settings -> HTTP 401
21:51:29  auth state changed to auth_token_missing; desktop returned to sign-in

A read-only request using the freshly issued access token produced these controls:

GET /backend-api/me                                      -> HTTP 200
GET /backend-api/accounts                               -> HTTP 200
GET /backend-api/accounts/check/v4-2023-04-27           -> HTTP 200
GET /backend-api/accounts/{account_id}/settings         -> HTTP 401
detail: "Must use workspace account for this operation"

The selected account was present in both account-list responses, and the stored account ID matched the token's embedded chatgpt_account_id. Supplying ChatGPT-Account-Id, X-OpenAI-Account-ID, or both did not change the settings response.

The desktop log surfaces the same request as Missing valid access token or actor biscuit, retries authentication, then drops the desktop session. The CLI remains operational.

Controls and remediation already attempted

• Reinstalled the signed app and tested across multiple updates.
• Removed and regenerated auth.json.
• Fully removed the 141 MB Electron/Chromium profile, cookies, local/session storage, caches, logs, Crashpad state, and temporary sockets.
• Confirmed sessions and config.toml were preserved but no auth/credential override exists.
• Confirmed no proxy environment or macOS system proxy.
• Confirmed no other Codex/CLI process existed during the clean failure window. The CLI process started eight seconds after the desktop logout.
• Previously signed out of all OpenAI sessions and reauthenticated; no change.

This evidence suggests the settings endpoint rejects a valid personal account because it expects a workspace account, and the desktop client then incorrectly escalates that route-specific 401 into global authentication loss. The issue is not fixed by resetting local state or issuing a fresh OAuth credential.

No email address, account ID, thread ID, access token, refresh token, or raw log archive is included.

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.

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.

Makes sense, I also enabled Advanced Account Security with the OpenAI YubiKeys just a few days back, and this is the first time I've opened up Codex since.

Adding one clarification to my earlier AAS comment, now that several more account-state data points have appeared in this thread.

I enabled Advanced Account Security specifically to retain Daybreak Blue access under the Sep 1 requirement. I have two registered YubiKeys, and the AAS authentication flow completes successfully with either key. I have not tested disabling AAS, so I do not have the same AAS on/off comparison that @gwu929 reported.

For timeline context, I had already successfully used Daybreak Blue on Aug 12, several days before this Desktop regression appeared. My only consistently stable Desktop version remains 26.810.52044 (build 6662).

Taken together, the reports here seem to point to a more nuanced account-state interaction rather than AAS alone:

@gwu929 reports AAS enabled → loop, AAS disabled → loop disappears.
@aravhawk also recently enabled AAS with YubiKeys and reproduces the issue.
Other users have reproduced the same regression with AAS disabled.
In my case, Daybreak Blue was already active before the regression, while build 6662 remains stable.

So I would not treat either AAS or Daybreak Blue alone as the confirmed root cause. But AAS enrollment, Daybreak Blue eligibility, or some account state associated with one or both now seem like potentially relevant exposure factors.

A working hypothesis that seems consistent with the combined reports is:

certain account states may cause newer Desktop builds to enter an account/workspace/settings path that older working builds do not, and a route-specific 401 is then incorrectly escalated into global authentication loss.

That would also fit the otherwise odd “Choose a workspace” screen I reported earlier, as well as the /accounts/{account_id}/settings 401 behavior discussed above.

In other words, this may be less “AAS itself breaks authentication” and more “the affected Desktop builds take a broken account/workspace path for some account states.”

Workaround that fixed the older-task logout loop for me

I had the same issue: new tasks worked, but opening an older codex://threads/... task immediately logged me out.

What I verified

I reproduced and investigated this across four different older tasks:

• The older tasks and their local transcripts were still intact.
• The local task database passed its integrity checks.
• The codex:// handler was registered correctly.
• The app successfully resumed the task first: thread/resume returned errorCode=null.
• Immediately afterward, authentication failed with 401 Unauthorized and refresh_token_invalidated.

This suggests the logout was caused by stale or invalid desktop authentication—not corrupted older tasks.

What fixed it for me

1. Open chatgpt.com in your browser.
2. Open the profile menu and fully Log out, then confirm.

Be aware that this can also sign you out of other ChatGPT sessions.

1. Return to the Codex/ChatGPT Mac app.
2. Click Sign in another way.
3. Choose Email and sign in directly using the email address connected to your ChatGPT account. Do not use Google, Apple, or another social-login option.
4. Enter the email verification code if requested.
5. On the Sign in to Codex with ChatGPT page, explicitly select the workspace containing the affected older tasks. In my case, this was Personal account. My personal and company workspace both use the same email address.
6. Click Continue/Open ChatGPT, return to the desktop app, and try opening the older tasks again.

After the full browser logout and direct email sign-in, I successfully opened all four older tasks without being logged out. The task resumes continued to return errorCode=null, with no further refresh_token_invalidated errors while opening them.

The successful test happened on the same ChatGPT/Codex build that had previously failed. I had staged a reinstall, but the logs confirmed the app was still running from the older copy, so I do not consider reinstalling or renaming the app to be the fix.

I did not delete ~/.codex, its session files, or its SQLite databases. Those contained healthy local task history, and deleting them could cause data loss.

Environment:

• macOS 27 beta (26A5421a)
• ChatGPT/Codex 26.818.61809, build 7019

Btw I also have advanced security on so that shouldn't be the issue

I still observed a separate account-settings 401 saying Must use workspace account for this operation, but it no longer logged me out or prevented older tasks from opening. Therefore, this should be considered a workaround rather than a confirmed root-cause fix.

I'm experiencing the same issue on Windows after enabling Advanced Account Security.

Environment:

• OS: Windows 11
• Codex Desktop: 26.818.8289.0 (x64)
• Codex app-server: 0.149.0-alpha.4.3
• Authentication: ChatGPT account via browser + Passkey
• Advanced Account Security: Enabled

I 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:

authenticatedAccountPresent=true
authMethod=chatgpt
result=succeeded

However, shortly afterwards Codex receives a 401 while the access token is still present:

desktop_fetch_auth_401
hadToken=true
tokenSource=cached
willRetry=true

About one second later, the authentication state changes to:

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

This is then followed by:

authenticatedAccountPresent=false
failureType=account_info_token_unavailable
result=failed

and:

401
Missing valid access token or actor biscuit

The Codex Desktop app then signs me out and returns to the login flow.

So in my case the sequence appears to be:

Passkey/browser login succeeds
→ Codex recognizes the authenticated ChatGPT account
→ API request returns 401
→ access token becomes unavailable
→ auth_token_missing
→ account_info_token_unavailable
→ Codex signs out

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.

26.820.60940 / build 7119 still reproduces; brand-new thread creation is affected too

I tested the current macOS Stable release 26.820.60940 (build 7119) on the same Mac/account that remains stable on 26.810.52044 (build 6662).

On build 7119:

• Opening an existing thread immediately signed the app out.
• After signing in again and explicitly selecting Personal account, I created a completely new thread.
• I happened to use Codex Spark for this test; I have no evidence that the selected model is relevant to the authentication failure.
• The new thread itself was created successfully and its first turn started successfully, but the app then entered the same sign-out path.
• After signing in again, opening that newly created thread also triggered the sign-out.

The logs show that the thread operations succeed before authentication collapses.

For an existing thread:

thread/resume -> errorCode=null
desktop_fetch_auth_401 hadToken=true -> /backend-api/accounts/:param/settings
auth_status_result hasToken=false nullReason=auth_token_missing
account_info_token_unavailable

For the brand-new thread:

thread/start -> errorCode=null
turn/start -> errorCode=null
desktop_fetch_auth_401 hadToken=true -> /backend-api/accounts/:param/settings
auth_status_result hasToken=false nullReason=auth_token_missing
account_info_token_unavailable

In the relevant reproduction window, I did not observe refresh_token_invalidated or token_revoked; the /accounts/{account_id}/settings 401 was followed directly by auth_token_missing.

I then rolled back only the application bundle to 26.810.52044 (build 6662), 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:

26.820.60940 / 7119 -> existing thread: sign-out
26.820.60940 / 7119 -> brand-new thread: sign-out
26.820.60940 / 7119 -> reopening that newly created thread: sign-out
26.810.52044 / 6662 -> the same newly created thread resumes and continues normally

This further weakens both:

1. the idea that only historical/older thread state is required to trigger the regression; and
2. the idea that the newly created thread itself becomes corrupted.

In this A/B test, the thread data remained in place and changing only the Desktop application bundle back to build 6662 made the same affected thread usable again.

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:

GET /backend-api/wham/usage                         -> HTTP 200
GET /backend-api/accounts/{redacted}/settings       -> HTTP 401
response detail: Must use workspace account for this operation

The fresh login sequence records:

account_login_completed ... success=true
chatgpt-account-lookup ... authenticatedAccountPresent=true ... result=succeeded

Opening an existing thread then records:

desktop_fetch_auth_401 hadToken=true target="GET https://chatgpt.com/backend-api/accounts/:param/settings"
app_server_connection.auth_status_result hasToken=false nullReason=auth_token_missing refreshToken=true
chatgpt-account-lookup ... authenticatedAccountPresent=false failureType=account_info_token_unavailable result=failed

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.

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.

me too,

Current production build 7119 still breaks active work — this needs urgent prioritization

I am independently reproducing this on:

• ChatGPT/Codex Desktop 26.820.60940 (build 7119)
• macOS 27.0 (26A5416b), Apple Silicon
• ChatGPT authentication

This 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:

$ codex login status
Logged in using ChatGPT

My sanitized Desktop logs show the same failure chain reported here:

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

status=401
detail="Must use workspace account for this operation"

chatgpt-account-lookup
authenticatedAccountPresent=false
failureType=account_info_token_unavailable

Failed to retrieve authentication token
status=432

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:

1. Avoid calling the workspace-only settings route for personal accounts.
2. Never convert a route-specific 401 into global authentication loss.
3. Preserve active task UI and recover credentials in place instead of forcing a restart.
4. Publish a confirmed fixed build and update this issue with its version.

I have intentionally omitted account IDs, thread IDs, tokens, and project information.

I have some additional findings and a recovery case to share.

Environment

• macOS 26.6.2
• ChatGPT.app 26.820.60940
• Bundled Codex: 0.150.0-alpha.8
• Personal ChatGPT account
• The affected thread could be read correctly from local storage, and thread/resume completed successfully

A 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:

• ~/.codex
• Codex-related Application Support directories
• Cache / HTTPStorage / Cookie / Local Storage data
• Preferences
• Logs
• Authentication state, including Keychain entries

Each 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:

thread/resume succeeds
→ GET /backend-api/accounts/{account_id}/settings returns 401
→ Desktop requests auth status with refreshToken=true
→ hasToken=false, nullReason=auth_token_missing
→ account_info_token_unavailable
→ UI returns to the sign-in screen

Subsequent requests were sent without a token and returned:

Missing valid access token or actor biscuit

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:

~/.codex_review/auth.json

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:

~/.codex/auth.json

[!WARNING] auth.json contains 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 local CODEX_HOME directories.

After comparing the two files without exposing any secrets, I confirmed that they had the same:

• account_id
• issuer
• audience
• plan
• scope
• auth_mode=chatgpt

However, 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.json itself 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}/settings request still returns 401, but its response is now:

Must use workspace account for this operation

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_missing and account_info_token_unavailable events no longer occur.

At least in this environment, the failure therefore appears to involve these two interacting behaviors:

1. A workspace-only settings request returns 401 for a personal account.
2. Desktop treats that 401 as an authentication failure and forces a token refresh. The refresh token issued through the normal Desktop sign-in path then becomes unusable, after which the existing access token is no longer returned to the Desktop shell.

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.json was 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.

TL;DR

If you get a 401 log 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:

GET /backend-api/accounts/.../settings → 401 → auth_token_missing → authenticatedAccountPresent=false

I tried the following without success:

• Completely quitting Cursor (Codex extension was installed, but Cursor was not running)
• Signing out/in of the desktop app
• Removing local Codex state, including ~/.codex / auth.json
• Reinstalling the desktop app
• Manually terminating the individual active sessions shown for this device

What 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_missing sequence, try a global logout of all sessions, not just a normal desktop logout or terminating individual active sessions.

• Desktop version where I reproduced the issue: 26.820.60940 (macOS)

This suggests the issue may involve stale/inconsistent server-side auth/session state rather than only local auth.json or 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.

I found a workaround that resolved the issue for me: 1. Sign out of the older Codex desktop app. 2. In ChatGPT Web, sign out all currently registered Codex devices. 3. Sign out of ChatGPT Web as well. 4. Update the Codex desktop app to the latest available version. 5. Sign in again. 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.

This resolved it on my side as well, thanks OP!

I found a workaround that resolved the issue for me: 1. Sign out of the older Codex desktop app. 2. In ChatGPT Web, sign out all currently registered Codex devices. 3. Sign out of ChatGPT Web as well. 4. Update the Codex desktop app to the latest available version. 5. Sign in again. 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.

that worked thanks!

New version deployed today have solved the issue for me.

New version is also working for me.

New version solved the issue for me as well.