[Windows 26.814] Opening an existing thread signs out a personal Pro account after workspace-only settings 401

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

• #39162
• #39170

Powered by Codex Action

Additional A/B account comparison (sanitized)

I tested two different ChatGPT accounts on the same Windows device and the exact same installed desktop build.

• Both accounts receive HTTP 401 from /backend-api/accounts/{account_id}/settings with Must use workspace account for this operation.
• The control account remains signed in despite that response. Thread list/read/resume and subsequent requests continue to succeed.
• Only the affected account loses authentication when the client performs the forced refresh. Its auth state transitions to hasToken=false with auth_token_missing; an earlier refresh attempt returned refresh_token_invalidated.
• Switching back to the control account makes the desktop app work normally without reinstalling or changing the machine configuration.

This comparison narrows the issue: the workspace-only settings 401 is not sufficient by itself to cause sign-out. The failure appears to be account-specific and related to the refresh-token/session lifecycle triggered by the updated desktop client.

No email addresses, account IDs, access or refresh tokens, thread IDs, or raw logs are included.

Confirmed workaround: clear the ChatGPT Web multi-account session

This is now resolved on the same affected Windows installation and desktop build.

After reviewing #39199, I confirmed that the browser used for OAuth had two ChatGPT accounts active through ChatGPT Web account switching. I then:

1. Fully exited the desktop app.
2. Signed out of both ChatGPT Web accounts and cleared the multi-account browser session.
3. Signed back in to only the affected ChatGPT Pro account.
4. Signed in to the desktop app again.

Result:

• New and existing conversations now work normally.
• The forced sign-out has stopped.
• The local auth cache completed a successful automatic refresh while the access, refresh, and ID tokens remained present.
• No additional reinstall or Windows App package reset was needed after clearing the browser session.

This narrows the diagnosis: the workspace-only settings 401 may still occur, but it was not the root cause of the sign-out. In this case, the upstream trigger was the ChatGPT Web multi-account session interfering with the desktop OAuth refresh-token lifecycle.

Current workaround: sign out of all ChatGPT Web accounts in the OAuth browser, then sign in to only the account intended for Codex Desktop before starting the desktop login flow.

No email addresses, account IDs, tokens, thread IDs, or raw logs are included.

I had the same issue and your tip fixed it. I wasn’t signed in with multiple accounts, though — I only had one Pro account. Logging out of that account and then signing back into the ChatGPT app solved it for me.

Same issue on Windows — and a workaround that has held: clear the browser session you sign in with, not app state.

Setup: Windows 11, Microsoft Store package OpenAI.Codex 26.814.5167.0 (desktop client 26.814.41407), personal account.

The Store auto-updated the app from 26.810.7004 to 26.814.5167 at 7:06 PM local yesterday. The previous build had run all day with zero auth errors; the first failure hit minutes after the new build registered. From the app's own log DB (~/.codex/logs_2.sqlite, target codex_login::auth::manager):

19:06:31  26.814.5167 registered (Store auto-update); app relaunched
19:12:57  getAuthStatus -> 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"}}
19:14:43  re-signed in via browser -> oauth token exchange succeeded status=200 OK
19:15:28  same 401 refresh_token_invalidated -- the fresh token died after 44 seconds
19:20:46  signed in again -> exchange 200 OK
19:20:58  app issued account/logout 11 seconds later

Also new in this build: codex_login::auth::manager logs Reloading auth roughly once per second while the loop is active (300+ entries within ~30 minutes of the update; zero occurrences anywhere in the prior 30 days of logs).

Consistent with what OP reported, local resets (auth file, credential store, app package) don't help — and I think that's the tell. The sign-in flow round-trips through the default browser, so the new grant inherits whatever session context auth.openai.com already had there. If that browser-side session is stale, every sign-in comes back poisoned the same way, no matter how much app state you wipe.

Workaround that worked here: clear the signing browser's data for the OpenAI domains (I cleared Chrome data wholesale; a targeted clear of cookies for auth.openai.com / chatgpt.com / openai.com is likely enough), then sign in again when the app opens the browser. Result: sign-ins went from dying within a minute (44s, then 11s) to fully stable — 30+ minutes including long agent runs, with zero auth errors or logouts in the log since. The 1 Hz Reloading auth churn also stopped.

The browser-session dependency might explain why this only hits some accounts: it seems to need a stale browser-side OpenAI session (mine dated back months) for the sign-in to inherit.

Same issue on Windows — and a workaround that has held: clear the browser session you sign in with, not app state. Setup: Windows 11, Microsoft Store package 26.814.5167.0 (desktop client 26.814.41407), personal account.OpenAI.Codex The Store auto-updated the app from 26.810.7004 to 26.814.5167 at 7:06 PM local yesterday. The previous build had run all day with zero auth errors; the first failure hit minutes after the new build registered. From the app's own log DB (, target ):~/.codex/logs_2.sqlitecodex_login::auth::manager `` 19:06:31 26.814.5167 registered (Store auto-update); app relaunched 19:12:57 getAuthStatus -> 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"}} 19:14:43 re-signed in via browser -> oauth token exchange succeeded status=200 OK 19:15:28 same 401 refresh_token_invalidated -- the fresh token died after 44 seconds 19:20:46 signed in again -> exchange 200 OK 19:20:58 app issued account/logout 11 seconds later ` Also new in this build: logs roughly once per second while the loop is active (300+ entries within ~30 minutes of the update; zero occurrences anywhere in the prior 30 days of logs).codex_login::auth::manager`Reloading auth Consistent with what OP reported, local resets (auth file, credential store, app package) don't help — and I think that's the tell. The sign-in flow round-trips through the default browser, so the new grant inherits whatever session context already had there. If that browser-side session is stale, every sign-in comes back poisoned the same way, no matter how much app state you wipe.auth.openai.com Workaround that worked here: clear the signing browser's data for the OpenAI domains (I cleared Chrome data wholesale; a targeted clear of cookies for / / is likely enough), then sign in again when the app opens the browser. Result: sign-ins went from dying within a minute (44s, then 11s) to fully stable — 30+ minutes including long agent runs, with zero auth errors or logouts in the log since. The 1 Hz churn also stopped.auth.openai.comchatgpt.comopenai.comReloading auth The browser-session dependency might explain why this only hits some accounts: it seems to need a stale browser-side OpenAI session (mine dated back months) for the sign-in to inherit.

This works. 👍

I can reproduce this on Windows with the unified ChatGPT desktop app.

Environment

• ChatGPT version: 26.814.41957
• Released: Aug 17, 2026
• Windows
• Personal account/workspace

Reproduction

1. Clean reboot.
2. ChatGPT Classic is installed but not running and has been disabled from startup.
3. Launch the new ChatGPT desktop app and sign in successfully.
4. Account/profile, usage, settings, projects, and conversation list all load normally.
5. Open any existing conversation thread, including an ordinary Chat thread.
6. The app immediately signs me out and returns to the “Sign in to ChatGPT” screen.

The same conversations work normally on chatgpt.com in the browser and in the iPhone app.

I also uninstalled and reinstalled the new desktop app, but the problem persisted.

I captured the failure using Help → Start Performance Trace.

Performance trace Feedback ID:

no-active-thread-01a01ae6-8bd2-7c60-ac75-de810f65a3bc

This appears consistent with the issue reported here: authentication succeeds initially, but opening an existing thread triggers an immediate logout.

I can reproduce this on Windows with the unified ChatGPT desktop app. Environment ChatGPT version: 26.814.41957 Released: Aug 17, 2026 Windows Personal account/workspace Reproduction 1. Clean reboot. 2. ChatGPT Classic is installed but not running and has been disabled from startup. 3. Launch the new ChatGPT desktop app and sign in successfully. 4. Account/profile, usage, settings, projects, and conversation list all load normally. 5. Open any existing conversation thread, including an ordinary Chat thread. 6. The app immediately signs me out and returns to the “Sign in to ChatGPT” screen. The same conversations work normally on chatgpt.com in the browser and in the iPhone app. I also uninstalled and reinstalled the new desktop app, but the problem persisted. I captured the failure using Help → Start Performance Trace. Performance trace Feedback ID: no-active-thread-01a01ae6-8bd2-7c60-ac75-de810f65a3bc This appears consistent with the issue reported here: authentication succeeds initially, but opening an existing thread triggers an immediate logout.

A few additional data points after further testing:

Timeline / affected machine

• I used the Windows desktop app throughout Aug 18 without any noticeable problem.
• When I returned on Aug 19, the logout problem was already present.
• Unfortunately, I do not know which exact build was installed at the moment the problem first appeared, because I uninstalled/reinstalled the app before I started recording version information.
• After reinstalling, the problem still reproduces consistently.

Current affected installation:

• About ChatGPT: 26.814.41957 (Released Aug 17, 2026)
• Windows AppX: OpenAI.Codex 26.814.5517.0
• OpenAI.ChatGPT-Desktop 1.2026.190.0

I also reproduced the issue after a clean Windows reboot with ChatGPT Classic disabled from startup and not running.

The issue is not limited to existing threads

I tested a completely new standalone conversation in Chat mode, outside any Project:

1. Sign in successfully.
2. Create a brand-new Chat.
3. Typing in the composer works normally.
4. Send the first message.
5. The assistant begins responding, and the desktop app immediately signs me out.

Importantly, I then opened chatgpt.com in the browser and found that this newly created conversation was present there, including both my message and the complete assistant response.

So the server-side conversation creation and model response appear to succeed; the desktop client logs out during or immediately after response handling.

Existing conversations still reproduce the original behavior as well: opening them causes an immediate logout.

Performance trace previously submitted:

no-active-thread-01a01ae6-8bd2-7c60-ac75-de810f65a3bc

Useful negative control: another Windows installation is working normally

My wife's Windows desktop installation is currently working normally in Chat mode.

Her versions are:

• About ChatGPT: 26.814.41407 (Released Aug 17, 2026)
• Windows AppX: OpenAI.Codex 26.814.5167.0
• OpenAI.ChatGPT-Desktop 1.2026.190.0

She is actively using Chat without this logout problem.

This seems important because 26.814.41407 / 26.814.5167.0 can apparently work normally on another Windows installation/account, while my newer 26.814.41957 / 26.814.5517.0 installation consistently fails.

So the 26.814 build alone may not be a sufficient condition; there may also be an account/session/auth-state-dependent trigger.

Confirming that this remains reproducible on a newer Windows package.

Environment

• Windows: Microsoft Windows NT 10.0.26200.0 x64
• Package: OpenAI.Codex 26.814.5517.0
• Authentication: Sign in with ChatGPT
• Default browser: Opera (HTTP/HTTPS handlers are registered and normal manual login opens it successfully)

User-visible behavior

The app was already authenticated and working, then unexpectedly switched to the Sign in to ChatGPT screen.

There is an important difference between the two login paths:

• After a normal manual logout, selecting sign-in opens the browser and authentication completes successfully.
• After the spontaneous auth loss, selecting sign-in says to continue in the browser, but no browser page opens.
• Fully quitting and reopening the desktop app can temporarily restore the previously cached authenticated session.

This suggests that the browser association itself is healthy; the sign-in action is failing only after the desktop client enters the forced signed-out/stale auth state.

Sanitized log markers from the latest occurrence

During 2026-08-19T20:59:40Z–21:03:57Z, the current desktop process recorded:

• 10 × desktop_fetch_auth_401
• 4 × account_login_completed
• 4 × Must use workspace account for this operation
• 1 × auth_token_missing

Earlier occurrences on the same installation also recorded:

• Failed to refresh authentication token
• Failed to retrieve authentication token

The latest event therefore follows the same general sequence reported here: authentication/login completes, account-dependent desktop requests return 401, the token becomes unavailable, and the UI falls back to sign-in.

The browser-session cleanup workaround discussed in this issue has not yet been tested for this latest occurrence.

No tokens, email addresses, account IDs, thread IDs, local paths, or raw logs are included.

<html>
<body>
<!--StartFragment--><html><head></head><body><p>Confirming this on a personal (non-workspace) ChatGPT account. Same failure chain, and in my case it also happens on <strong>brand-new chats</strong>, not only when resuming an existing thread.</p>
<h3>Environment</h3>

  |  
-- | --
OS | Windows 11 x64
Package | OpenAI.Codex 26.814.5517.0_x64__2p2nqsd0c76g0
Desktop client release | 26.814.41957
Account type | personal ChatGPT (authMethod=chatgpt), not a workspace member

<h3>Timeline strongly points at the update</h3>
<ul>
<li>App package updated: <strong>2026-08-19 17:07</strong> (local, UTC+3)</li>
<li>First <code>desktop_fetch_auth_401</code> in the app logs: <strong>2026-08-19T14:09:12.075Z</strong> = 17:09 local</li>
</ul>
<p>Two minutes after the update. There is not a single <code>desktop_fetch_auth_401</code> entry before that point. Counts since: <strong>593</strong> occurrences on 08-19, <strong>378</strong> on 08-20.</p>
<h3>Failure chain (from <code>%LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs</code>)</h3>
<pre><code>[devicecheck-attestation] DeviceCheck attestation unavailable deviceCheckLatencyMs=null durationMs=0 errorCode=1

[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

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

[electron-message-handler] sa_server_request_failed status=401
errorMessage="{\"detail\":\"Missing valid access token or actor biscuit\"}"
routePattern=/accounts/{account_id}/settings

[electron-fetch-wrapper] desktop_fetch_auth_401 hadToken=false skipRetryReason=no_token_attached
target="GET https://chatgpt.com/backend-api/wham/:param/:param" willRetry=false
</code></pre>
<p>After that every subsequent request goes out with no token at all (<code>hadToken=false</code>, <code>no_token_attached</code>) and the app drops to the sign-in screen.</p>
<h3>The token itself is valid — this is not an expiry problem</h3>
<p>Checked <code>~/.codex/auth.json</code> directly:</p>
<ul>
<li><code>auth_mode = chatgpt</code>, no <code>OPENAI_API_KEY</code> set</li>
<li><code>last_refresh = 2026-08-20T05:41:06Z</code> (file written successfully, so storage is writable)</li>
<li><code>access_token</code> JWT <code>exp</code> decodes to <strong>2026-08-30</strong>, i.e. still valid for 10 more days at the moment of the 401</li>
<li>File ACL is normal, <code>EnableControlledFolderAccess = 0</code>, no security software touching the file</li>
</ul>
<p>So the app discards a perfectly valid token because one workspace-only endpoint answered 401.</p>
<h3>Network is not the cause</h3>
<p>I initially suspected my connection. Verified it is fine at the moment the 401s occur:</p>
<pre><code>$ curl https://chatgpt.com/cdn-cgi/trace
h=chatgpt.com
ip=&lt;redacted&gt;
colo=AMS
loc=NL
tls=TLSv1.3
</code></pre>
<p>Requests to <code>chatgpt.com</code>, <code>auth.openai.com</code> and <code>ab.chatgpt.com</code> all complete normally in the network layer log at the same timestamps.</p>
<h3>What does NOT work as a workaround</h3>
<ul>
<li>Signing in again — the app signs out again within seconds</li>
<li>Starting a new chat instead of resuming an old thread</li>
<li>Reinstalling the app</li>
</ul>
<h3>Suggested fix</h3>
<p>A 401 from <code>/backend-api/accounts/{account_id}/settings</code> for a personal account should be treated as "this endpoint is not applicable to this account type" and ignored, not as proof that the session is invalid. Right now it triggers a forced refresh that destroys a working session, and the resulting state is unrecoverable without re-login — which then immediately repeats.</p></body></html><!--EndFragment-->
</body>
</html>

Confirming this on a personal (non-workspace) ChatGPT account. Same failure chain, and in my case it also happens on brand-new chats, not only when resuming an existing thread.

Environment

| | |
|---|---|
| OS | Windows 11 x64 |
| Package | OpenAI.Codex 26.814.5517.0_x64__2p2nqsd0c76g0 |
| Desktop client release | 26.814.41957 |
| Account type | personal ChatGPT (authMethod=chatgpt), not a workspace member |

Timeline strongly points at the update

• App package updated: 2026-08-19 17:07 (local, UTC+3)
• First desktop_fetch_auth_401 in the app logs: 2026-08-19T14:09:12.075Z = 17:09 local

Two minutes after the update. There is not a single desktop_fetch_auth_401 entry before that point. Counts since: 593 occurrences on 08-19, 378 on 08-20.

Failure chain (from %LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs)

[devicecheck-attestation] DeviceCheck attestation unavailable deviceCheckLatencyMs=null durationMs=0 errorCode=1

[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

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

[electron-message-handler] sa_server_request_failed status=401
    errorMessage="{\"detail\":\"Missing valid access token or actor biscuit\"}"
    routePattern=/accounts/{account_id}/settings

[electron-fetch-wrapper] desktop_fetch_auth_401 hadToken=false skipRetryReason=no_token_attached
    target="GET https://chatgpt.com/backend-api/wham/:param/:param" willRetry=false

After that every subsequent request goes out with no token at all (hadToken=false, no_token_attached) and the app drops to the sign-in screen.

The token itself is valid — this is not an expiry problem

Checked ~/.codex/auth.json directly:

• auth_mode = chatgpt, no OPENAI_API_KEY set
• last_refresh = 2026-08-20T05:41:06Z (file written successfully, so credential storage is writable)
• access_token JWT exp decodes to 2026-08-30, i.e. still valid for 10 more days at the moment of the 401
• File ACL is normal, EnableControlledFolderAccess = 0, no security software touching the file

So the app discards a perfectly valid token because one workspace-only endpoint answered 401.

Network is not the cause

I initially suspected my connection and ruled it out. At the same timestamps as the 401s:

$ curl https://chatgpt.com/cdn-cgi/trace
h=chatgpt.com
colo=AMS
tls=TLSv1.3

Requests to chatgpt.com, auth.openai.com and ab.chatgpt.com all complete normally at the network layer.

What does NOT work as a workaround

• Signing in again — the app signs out again within seconds
• Starting a new chat instead of resuming an existing thread
• Reinstalling the app

Suggested fix

A 401 from /backend-api/accounts/{account_id}/settings for a personal account should be treated as "this endpoint does not apply to this account type" and ignored, not as proof that the session is invalid. Right now it triggers a forced refresh that destroys a working session, and the resulting state is unrecoverable without re-login — which then immediately repeats.

Confirming the same failure chain on macOS, personal (non-workspace) account, and confirming the browser-session workaround fixes it there too.

Environment

• macOS 26.2 (Apple Silicon)
• Unified ChatGPT/Codex desktop app 26.818.21641, bundle com.openai.codex
• Account: personal ChatGPT (authMethod=chatgpt), not a workspace member
• Standalone Codex CLI 0.148.0 worked fine with the same account throughout

Timeline points at the update, same as the Windows reports

• App auto-updated 2026-08-20 17:07 local
• First broken session 17:12 local, five minutes later; no desktop_fetch_auth_401 entries before the update

Same chain as OP, from ~/Library/Logs/com.openai.codex:

• account_login_completed, fresh auth.json written, access_token JWT exp decodes to +10 days
• GET /backend-api/accounts/{account_id}/settings -> 401 "Missing valid access token or actor biscuit"
• app_server_connection.auth_status_result hasToken=false nullReason=auth_token_missing refreshToken=true
• codex_login::auth::manager refresh -> 401 refresh_token_invalidated
• UI drops to "Sign in to ChatGPT"

Data point supporting the poisoned-grant theory rather than a local race: a refresh token minted 26 seconds earlier was already refresh_token_invalidated, with every other local process that shares ~/.codex/auth.json stopped during the test. The access token from the same grant was still accepted by /backend-api/wham/tasks/list (200) at that moment. Fresh app browser profile, keychain check, and clock check (9 ms offset) changed nothing.

Workaround confirmed on macOS: quit the app, sign out of chatgpt.com in the default browser (Brave here), clear cookies for chatgpt.com / auth.openai.com / openai.com, sign back in to the single intended account, then sign in to the desktop app. Sign-in now sticks; opening existing threads works; no further desktop_fetch_auth_401 or refresh_token_invalidated entries in the logs.

Adding a code-level repro from 26.818.2441.0 because this failure mode is even worse than it looks.

The bundled client literally names the call getWorkspaceSettings() and maps it to /accounts/{account_id}/settings. The sidebar/project gate (Orl() in this build) first looks at current account data. If structure === "workspace" it uses the workspace ID, which is fine. But if current account data is null and loading has stopped, it falls back to the auth account ID anyway and calls the workspace endpoint.

That is exactly the wrong fallback during an account/login outage. With a personal Pro Lite account the route answers:

401 Must use workspace account for this operation

Then performDesktopFetch() sees any authenticated 401, forces a token refresh, and the live app state becomes:

hasToken=false nullReason=auth_token_missing refreshToken=true

The UI kicks the user out while an already-running Codex CLI task keeps working. I also reproduced the kick without opening an old thread: a live task/sidebar update was enough. So the thread is not corrupt. The sidebar permission check is detonating auth.

This is ridiculous. A check for chatgpt.workspace.project.crud should not be able to destroy the whole session. Please do both obvious fixes: do not call workspace settings until account structure is known to be workspace, and do not treat a route-specific authorization 401 as proof that the OAuth session is dead. Re-login loops, cache wipes, and reinstalling are not acceptable answers for a client bug like this.

No raw logs, IDs, tokens, email addresses, thread IDs, or local paths are included here.

Disclosure: I used Codex to inspect the local app logs and bundled JavaScript and to help write this comment. I reviewed the result before posting.

Confirming the workaround on Windows with a personal ChatGPT Pro account and OpenAI.Codex 26.818.2441.0. After fully quitting the desktop app, signing out of ChatGPT in the OAuth browser, clearing browser site data for the OpenAI/ChatGPT domains, signing back in to only the intended account, and then authenticating the desktop app again, the app remained signed in and existing conversations loaded normally. No reinstall or Windows App package reset was needed. This confirms the browser-session reset workaround on the current Windows package.

Impact: diagnosing and recovering from this cost me roughly 4–5 hours.

On my Macbook Air M4 Base model, I have the same issue. Also, the workaround suggested here did not provide a solution for the issue. I still cannot do any work on my paid account.

@orkasi For clarity, to fix the issue, in Chrome I went to Settings → Privacy and security → Third-party cookies → See all site data and permissions. I searched for and deleted all site data matching chatgpt.com, auth.openai.com, and openai.com. I did this after fully quitting the desktop app and signing out of ChatGPT Web. I then signed back into only the intended account before reopening the desktop app. PS I didn't clear all Chrome browsing data if they are earlier instructions.

Reproducing this on a newer build than the one originally reported, with a full network-level trace from the app's own Sentry breadcrumbs. My account is a personal account with no workspace and no team membership, plan type prolite.

I can confirm the diagnosis in the original report and add two things: the failure is fully reproducible, and there is a second, independent defect that turns the sign-out into what users perceive as a crash.

Environment
OpenAI.Codex 26.818.5229.0 (desktop client 26.818.41509, buildFlavor prod)
Electron / Chrome 151.0.7922.170, Node 24.14.0
Windows 10.0.19045 x64, Intel Core i7-3770K, 16 GB RAM
Account: personal, plan type prolite, subscription active until 2026-09-20, auth method chatgpt (email OTP)
For log correlation on your side:

installation id: 7e983c90-44e8-49a3-9901-7010e3875a0e
sentry session id: c8c1a1f0-d9b5-4097-8107-ec53f47485b7
sentry sid: 2138bd2254d942fc8e4971c97b21cafd
app session started 2026-08-22 19:53:59 UTC
failures at 2026-08-22 19:48:38 UTC and 20:02:27 UTC
Timestamps in the traces below are Europe/Berlin (UTC+2). Happy to share account-level identifiers privately.

Steps to reproduce
Sign in through the browser. Sign-in completes normally.
Use the app for a few minutes. Everything works: sidebar loads, task polling succeeds, pinned items appear.
Click a pinned project.
Within about three to five seconds the app drops to the signed-out state.
Reproduced twice in one session, with an identical request sequence both times.

Observed behaviour
The session is provably healthy right up to one specific request. wham/tasks/list polls once a minute and returned 200 on eight consecutive polls. Then, on opening the project:

22:02:23 200 /backend-api/settings/user
22:02:24 200 /backend-api/pins?item_type=conversation
22:02:24 200 /backend-api/pins?item_type=project
22:02:24 200 /backend-api/wham/usage
22:02:24 200 /backend-api/wham/accounts/check
22:02:24 200 /backend-api/gizmos/snorlax/sidebar
22:02:27 401 /backend-api/accounts/{account_id}/settings
22:02:28 401 /backend-api/accounts/{account_id}/settings (retry)
22:02:29 401 /backend-api/wham/onboarding/context
22:03:12 401 /backend-api/wham/tasks/list <-- returned 200 eight times before this
22:04:12 401 /backend-api/wham/tasks/list
Console output across the transition, showing the token being lost rather than expiring:

22:02:27 [electron-fetch-wrapper] desktop_fetch_auth_401
hadToken=true skipRetryReason=null tokenSource=cached willRetry=true
target="GET https://chatgpt.com/backend-api/accounts/:param/settings"
22:02:28 [AppServerConnection] app_server_connection.auth_status_result
authMethod=chatgpt cacheWrite=null hasToken=false
nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
22:02:29 [electron-message-handler] sa_server_request_failed
errorMessage="{\"detail\":\"Missing valid access token or actor biscuit\"}"
routePattern=/accounts/{account_id}/settings status=401
requestHeaderNames=["OAI-Language","X-OpenAI-Attach-Auth",
"X-OpenAI-Attach-Integrity-State","originator"]
rendererWindowVisible=true rendererWindowFocused=true
22:02:29 [electron-fetch-wrapper] desktop_fetch_auth_401
hadToken=false skipRetryReason=no_token_attached willRetry=false
target="GET https://chatgpt.com/backend-api/wham/:param/:param"
The state change is unambiguous: hadToken=true before the workspace-only call, hadToken=false on every call afterwards. A 401 from an endpoint that does not apply to this account type discards an otherwise valid session.

The first occurrence 14 minutes earlier followed the same path and additionally captured the app switching itself to the login flow:

21:48:34 ui.click (the project)
21:48:35 200 /backend-api/wham/accounts/check
21:48:38 401 /backend-api/accounts/{account_id}/settings
21:48:39 GET .../assets/login-route-*.js
21:48:39 GET .../assets/chatgpt-desktop-auth-url-*.js
21:48:39 GET .../assets/onboarding-entrypoint-*.js
21:48:39 GET .../assets/onboarding-login-content-*.js
21:48:39 electron renderer.destroyed url=https://chatgpt.com/?source=codex#pricing
21:48:39 401 /backend-api/wham/onboarding/context
Two distinct defects
Defect 1 - a workspace-only 401 invalidates a personal session. /backend-api/accounts/{account_id}/settings is not applicable to a personal account, so its 401 is expected. Treating it as an authentication failure, forcing a token refresh and tearing down the session is not.

Defect 2 - the resulting screen renders empty. Even granting the sign-out, the app should show a usable sign-in prompt. Instead the route renders nothing, with this console warning:

Matched leaf route at location "/" does not have an element or Component.
This means it will render an <Outlet /> with a null value by default resulting in an
"empty" page.
This is why the failure is widely reported as a crash. It is not one. During the whole episode all nine processes stay alive, the main window keeps responding (Responding = True), CPU usage stays near zero, and no crash dump is written to Crashpad\reports. Anyone triaging these reports as crashes will be looking in the wrong place.

Token state is not the problem
~/.codex/auth.json was intact before, during and after both failures, and was never rewritten (file mtime unchanged throughout):

auth_mode = chatgpt, OPENAI_API_KEY = null
access token valid for another 10 days (exp 2026-09-01), aud https://api.openai.com/v1
refresh token present
last_refresh predates both failures
So the client is discarding a valid session rather than reacting to an expired one.

Possibly related: plan type prolite
Three observations that may share a root cause in how prolite is handled:

/backend-api/payments/payment_methods returns 400: "Payment methods for mobile subscriptions must be managed in the mobile platform."
The last URL of the destroyed renderer is chatgpt.com/?source=codex#pricing, i.e. the app was routing toward a pricing or upsell page.
There are separate reports that the app-server provider probe rejects account.planType = "prolite" because the value is missing from its schema enum (accepted: free, go, plus, pro, team, business, enterprise, edu, unknown), leaving the model list empty.
It would be worth checking whether prolite is handled consistently across the account-settings, entitlement and provider-probe paths.

Side observation: same misleading "expired" framing in a second client
Possibly useful for triage, not part of this bug: a completely separate third-party client on the same machine talks to the same chatgpt.com/backend-api/codex endpoint with its own OAuth session (same account, same client_id, separate access and refresh tokens). It also surfaces 401s as "Provided authentication token is expired" while its token is likewise valid for another ten days.

Two independent clients therefore report token expiry for 401s that are not expiry. If the backend returns 401 for authorisation or plan-eligibility reasons rather than expiry, a more specific status or error body would let clients stop tearing down valid sessions.

Ruled out locally
Each of these was measured, not assumed:

App repair, app reset, and full uninstall plus reinstall
Complete reset of the Chromium profile at %APPDATA%\Codex\web\Codex (note: this lives outside the MSIX container, so the three Windows repair paths never touch it)
DPAPI decryption of os_crypt.encrypted_key - succeeds, yields a valid 32-byte AES key
codex:// protocol handler - resolves correctly to the app
Chrome's protocol_handler.excluded_schemes - empty, no silent block on the callback
Proxy and enterprise policies - none in effect
Hardware acceleration - disabling it changes nothing, and an HTTP 401 is not a rendering problem
Memory pressure - 7.4 GB free, all app processes together about 1.1 GB
Pending app updates - the update installed successfully; this build is current
Expected behaviour
Either skip the workspace-only account-settings request for personal accounts, or treat a 401 from it as non-fatal and keep the existing session. Additionally, the signed-out route should render an actual sign-in prompt rather than an empty page.

Confirmed workaround on Windows Stable, still reproducible on OpenAI.Codex 26.818.5229.0.

Observed failure pattern in the desktop logs matched this issue closely:

• /backend-api/accounts/{account_id}/settings -> 401
• desktop_fetch_auth_401 hadToken=true
• then hasToken=false, nullReason=auth_token_missing, while refreshToken=true
• followed by Missing valid access token or actor biscuit / account_info_token_unavailable
• opening any project/thread immediately returned the app to the sign-in screen
• codex login status in CLI still showed Logged in using ChatGPT

What fixed Stable for me:

1. Fully quit Codex and Microsoft Edge.
2. Clear Edge cookies for OpenAI/ChatGPT (openai.com, auth.openai.com, chatgpt.com).
3. Start Codex Stable again and complete browser login with only the intended ChatGPT account/session.
4. Open the same projects/threads.

Result: the sign-in loop stopped and Stable is working normally again. No reinstall, Reset-AppxPackage, .codex deletion, or downgrade was needed.

This strongly supports the browser-side OpenAI/ChatGPT OAuth session/cookies workaround already reported in this thread, and confirms it also works on the 26.818 Stable branch.

Confirmed workaround that is currently working for me on Windows Desktop:

1. Create a brand-new browser profile, or use a completely different browser that has no existing OpenAI/ChatGPT session.
2. Sign in to the intended ChatGPT account in that fresh browser profile/browser.
3. Fully quit the ChatGPT/Codex Desktop app, including all background processes.
4. Reopen the Desktop app and complete its sign-in flow only through that fresh browser profile/browser.
5. Do not let the OAuth flow use the old browser profile/session.

This is slightly different from only clearing cookies in the existing browser profile. In my case, isolating the login into a completely fresh browser profile/session is what made the Desktop authentication stable. It is working normally for me now.

Sharing in case anyone is blocked by the repeated sign-in / auto-logout loop.

Confirming on OpenAI.Codex 26.818.8289.0 (desktop client 26.818.61809, bundled core 0.149.0-alpha.4.3), Windows 11 Pro 10.0.26200, personal ChatGPT Pro account with no workspace and no team membership. Adding three things not yet in this thread: a strict per-launch correlation, a negative control that isolates the trigger, and a counter-forensics note about several log fields that are misleading people in this thread and elsewhere.

1. Per-launch correlation across five consecutive launches: 5/5, no exceptions

Same machine, same build, five app launches within 100 minutes. settings401 counts GET /backend-api/accounts/{account_id}/settings returning 401; logout is the UI returning to the signed-out state.

| launch (local) | settings 401 | resumeStarted | resumeSuccess | logout |
|---|---|---|---|---|
| 18:17 | 0 | 2588 | 1 | no |
| 18:37 | 0 | 706 | 0 | no |
| 18:44 | 2 | 187 | 4 | yes |
| 18:58 | 2 | 11 | 11 | yes |
| 19:13 | 1 | 5 | 5 | yes |

The settings 401 is necessary and sufficient for the logout in every launch. The logout follows the 401 by 1–2 seconds each time:

18:45:01.530  desktop_fetch_auth_401 hadToken=true skipRetryReason=null
              target="GET https://chatgpt.com/backend-api/accounts/:param/settings"
18:45:02.815  auth_status_result hasToken=false nullReason=auth_token_missing
19:14:09.066  desktop_fetch_auth_401 hadToken=true  (same target)
19:14:10.331  auth_status_result hasToken=false nullReason=auth_token_missing

hadToken=true on the settings call, then every subsequent request logs hadToken=false skipRetryReason=no_token_attached. The client discards a locally valid token — exp was 10 days out (2026-09-03), verified unexpired at the time of the logout.

2. Negative control: the two clean launches were not healthy, they just never reached the call

This is worth stating because it rules out "opening an old thread" as the trigger. At 18:17 and 18:37 I had (for unrelated reasons) moved some session .jsonl files off disk, so resume failed: 2588 resume attempts with 1 success, and 706 with 0. Those launches never issued the settings request at all and never logged out. Restoring the files made resume succeed, and the settings 401 plus logout returned immediately.

So the ordering is: resume must complete before the client issues getWorkspaceSettings(). A partially-broken thread store accidentally suppresses the bug. That matches @johnny-salz's code-level finding — the fallback fires once account data has settled to null with loading stopped.

3. Counter-forensics: cacheWrite, hasToken and nullReason are hardcoded literals, not measurements

Several reports here (and Codex's own self-diagnosis when I asked it) treat these fields as evidence about token state. In app.asar for this build they are constants in that single log branch:

this.logger.warning(`app_server_connection.auth_status_result`, {
  safe: { authMethod: r?.authMethod ?? null,
          cacheWrite: `null`,   // literal string
          hasToken: !1,         // literal false
          nullReason: t, refreshToken: n, tokenExpiryState: LG(i,e) }})

nullReason comes from a classifier that returns auth_token_missing for any chatgpt-mode account whose status response lacked a token — it is a label, not a diagnosis:

function RG(e){ return e==null ? `response_null`
                : e.authMethod===`chatgpt` ? `auth_token_missing`
                : `auth_method_not_chatgpt` }

Consequences for triage:

• cacheWrite=null never indicates a failed cache write; it is emitted identically on every occurrence.
• hasToken=false in this line does not mean the local token is gone. In my case auth.json held a valid unexpired token throughout.
• refresh_token_invalidated appears 0 times in the 273 MB app.asar, so where it shows up it originates from a server response body, not client logic. In my five launches there were 0 refresh events, yet the same logout occurred — so refresh-token invalidation is not required to reproduce this.
• actor biscuit is likewise absent from the bundle (0 occurrences); Missing valid access token or actor biscuit and {"detail":"Unauthorized"} are downstream consequences logged after the token is dropped, not the cause.
• last_refresh (present in auth.json) has 0 occurrences in the bundle — the desktop client never reads it; that field belongs to the Rust CLI.

I also chased and refuted three plausible-looking local causes, in case they save someone else the time: a poid=org-… claim on a personal plan_type=pro token is normal (personal accounts get a personal org id, and chatgpt_account_id matched tokens.account_id exactly); this account has no workspace switcher in its settings UI at all; and the "Payment methods for mobile subscriptions must be managed in the mobile platform." response also appears in the launches that did not log out, so it is unrelated background noise.

Impact

codex login status in the CLI continued to report Logged in using ChatGPT throughout, so the CLI and the desktop app disagree about auth state. The practical severity is that a failed subscription-info lookup — a non-critical read — invalidates an otherwise working authenticated session. Independent of the server-side 401, the client-side escalation from one 401 on a non-essential endpoint to discarding the token and signing out globally looks like the more tractable fix, and would make the endpoint problem invisible to users.

Happy to provide the sanitized per-launch log extracts if that would help.

Following up on my report from 08/22 — the "sign out of all sessions server-side, then wait, then relaunch" workaround worked for me too.

Steps: chatgpt.com → Settings → Security → Active sessions → "Log out of all devices". Then waited about 30 minutes (the delay some others mentioned turned out to be real for me). Then relaunched the Desktop app (Windows, personal prolite account, was on 26.818.8289.0) and signed in fresh.

Since then the app has been working without any sign-out on opening pinned projects/threads. Adding this as another data point for anyone hitting the same 401-on-accounts/settings invalidation.

I can confirm that this issue is still reproducible on the latest Microsoft Store version available to me, using a personal ChatGPT Plus account. Advanced Account Security is disabled.

Environment:

• Windows NT 10.0.26200.0 x64
• MSIX package: OpenAI.Codex_26.820.7780.0
• Desktop release: 26.820.60940
• Bundled Codex CLI: 0.150.0-alpha.8

Observed after a full logout and fresh sign-in:

• OAuth token exchange succeeds with HTTP 200.
• A fresh auth.json is written.
• 26 seconds later, Desktop requests GET /backend-api/accounts/{account_id}/settings and receives HTTP 401.
• The app-server auth state changes to hasToken=false / auth_token_missing.
• Account lookup reports account_info_token_unavailable.
• Token refresh then returns refresh_token_invalidated, and Desktop returns to the sign-in screen.

Read-only comparison using the same freshly issued access token:

• GET /backend-api/codex/models?client_version=0.150.0-alpha.8 -> HTTP 200
• GET /backend-api/accounts/{account_id}/settings -> HTTP 401: “Must use workspace account for this operation”

This indicates that the access token remains valid for Codex, but Desktop treats the workspace-only account-settings 401 as a global authentication failure. ChatGPT Web remains signed in and works normally. Resetting the app, clearing credentials/cache, and signing in again do not resolve it.

Confirming this on OpenAI.Codex 26.818.8289.0 for Windows. The same ChatGPT account is signed in on both a Mac and a Windows PC. Creating a new conversation on Windows works, but opening an existing conversation signs the Windows app out and requires authentication again. This started immediately after completing the new enhanced security verification. Please confirm whether simultaneous use on two computers is supported; if it is, please investigate the unexpected sign-out.

Additional Windows reproduction on 26.820.71523 (sanitized)

I am seeing the same repeated sign-in loop on Windows with Codex Desktop client 26.820.71523.

Context:

• ChatGPT sign-in succeeds initially.
• Shortly before the issue started, the ChatGPT account password was changed.
• VPN/no-VPN makes no difference.
• Existing Codex sessions were signed out from ChatGPT Active Sessions.
• ~/.codex/auth.json was renamed/regenerated.
• No CODEX_* or OPENAI_* environment variables are present.
• Windows App Repair and then Reset were both tried; the issue persists.

Sanitized log sequence:

desktop_fetch_auth_401 hadToken=true tokenSource=cached willRetry=true
app_server_connection.auth_status_result authMethod=chatgpt hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
sa_server_request_failed ... status=401 ... Unauthorized
desktop_fetch_auth_401 hadToken=false skipRetryReason=no_token_attached ... willRetry=false

The remote-control refresh path also reports:

Encountered invalidated oauth token for user, failing request
code=token_revoked

and the auth recovery path reports that the access token cannot be refreshed because the refresh token was revoked.

The bundled Codex app-server/CLI still initializes successfully, so the failure appears isolated to the Desktop ChatGPT OAuth/session lifecycle rather than the repository, Git, or CLI runtime.

I have not included account IDs, tokens, thread IDs, email addresses, or raw logs. I will next test the browser-session workaround described in this issue (clear OpenAI/ChatGPT browser session and sign in with only the intended account) before attempting a Desktop rollback.

Additional Windows reproduction on newer builds:

• Codex Desktop was confirmed on 26.820.60940 (released 2026-08-26), and the problem is still reproducible after installing the next available update on 2026-08-27.
• Sign-in succeeds and the home/conversation list is visible.
• Opening any existing Codex conversation immediately signs the Desktop app out and returns it to the ChatGPT sign-in screen.
• Signing in again succeeds, but opening an existing conversation reproduces the same logout loop every time.
• Codex CLI on the same Windows machine and same ChatGPT account remains usable. CLI can discover/resume the same local sessions when Desktop is fully closed, which suggests the session files themselves are not corrupted.
• If Desktop is still running, CLI may report thread ... already has an active writer; once Desktop is fully exited, that writer conflict can be removed. This appears separate from the authentication/logout failure.
• Updating the Desktop client did not resolve the issue.

Expected behavior: opening/resuming an existing conversation should preserve the authenticated ChatGPT session instead of transitioning the Desktop runtime to signed-out state.

This looks consistent with the auth-state/refresh-token regression already described in this issue and related reports. Please prioritize a Desktop-side fix; the failure makes existing Codex conversations effectively unusable on affected Windows installations.

Confirmed workaround from another affected Windows user on 26.820.60940:

The root trigger in this case was multiple ChatGPT/OpenAI browser sessions/accounts being present during the Codex Desktop OAuth sign-in flow.

Observed behavior:

• ChatGPT Web was actively using one account.
• When Codex Desktop opened the browser for OAuth, the browser showed a different ChatGPT account that was still present in cookies/session state.
• Codex sign-in appeared to succeed, but opening any existing conversation immediately signed Desktop out again.

What fixed it:

1. Fully quit Codex/ChatGPT Desktop (not just close the window).
2. Sign out of all ChatGPT/OpenAI accounts in the browser used for OAuth.
3. Clear site data/cookies specifically for:

• chatgpt.com
• auth.openai.com
• openai.com

1. Close and reopen the browser.
2. Sign in to only the ChatGPT account intended for Codex Desktop.
3. Launch Codex Desktop and complete Sign in with ChatGPT again.
4. Open an existing Codex conversation.

Result: existing conversations now open normally and the automatic sign-out loop has stopped.

This strongly suggests that stale or multi-account browser OAuth state can cause Codex Desktop to obtain/use an inconsistent account/session context, which later collapses during thread resume/account refresh.

Recommendation for affected users: before reinstalling the app or deleting ~/.codex, first clear the browser-side OpenAI/ChatGPT OAuth session and retry with a single account. The local Codex sessions themselves do not need to be deleted.

Confirmed on Windows with Codex Desktop 26.820.71523.

I hit the same auth loop after changing my ChatGPT password: sign-in succeeded, then the desktop app quickly returned to sign-in. Local troubleshooting did not resolve it (signed out active Codex sessions, regenerated ~/.codex/auth.json, tested without VPN, checked for CODEX/OPENAI env vars, used Windows Repair, then full App Reset). Logs showed the same sequence reported here:

• desktop_fetch_auth_401 hadToken=true
• auth_token_missing
• token_revoked / invalidated OAuth token
• later hadToken=false skipRetryReason=no_token_attached

What finally fixed it was clearing the browser-side ChatGPT/OpenAI OAuth session, not more Codex app state:

1. Fully exit Codex Desktop.
2. Sign out of ChatGPT in the browser used for OAuth (sign out of all ChatGPT accounts if multiple are present).
3. Clear site data/cookies for chatgpt.com, openai.com, and auth.openai.com (or clear the browser session completely).
4. Restart the browser.
5. Sign in to only the intended ChatGPT account.
6. Launch Codex Desktop and complete Sign in with ChatGPT again.

After doing this, Codex remained signed in and completed new tasks normally. A stale pre-fix conversation later returned thread not found, but opening a new thread worked correctly; this appeared to be leftover thread state from the earlier broken auth session, not an ongoing auth failure.

This workaround may be worth surfacing in troubleshooting docs because local App Reset / auth.json reset alone can leave the browser OAuth session unchanged and therefore reproduce the same revoked-token loop.

Additional Windows reproduction on package 26.820.9563.0: the same workspace-settings 401 triggers forced authentication refresh, but the locally observed failure is a 30-second getAuthStatus timeout, not a confirmed refresh_token_invalidated response.

Environment

• Windows 10 Pro x64, build 19045.
• Microsoft Store package: OpenAI.Codex 26.820.9563.0.
• Desktop client version recorded in logs: 26.820.71523.
• App-managed backend, verified with --version: codex-cli 0.150.0-alpha.8.
• ChatGPT browser sign-in; the user reports no newer app update is available.
• A third-party TUN/VPN network path is in use. Its involvement in the refresh stall has not been ruled out.

Two captured incidents

Times below are local UTC+08:00 on 2026-08-28 (equivalently 2026-08-27 UTC).

| Local time | Observation |
| --- | --- |
| 05:17:04 | Forced refresh starts after accounts/settings 401; no refresh-completion log before the later restart. |
| 05:17:34 | Failed to refresh authentication token. |
| 05:18:11 | Timed out waiting for MCP response to getAuthStatus; authenticatedAccountPresent=false, failureType=account_info_token_unavailable. |
| 05:35:21.841 | A second incident: accounts/settings 401 with hadToken=true, tokenSource=cached, willRetry=true. Backend records Refreshing token. |
| 05:35:51.874 | Failed to refresh authentication token, approximately 30 seconds later. |
| 05:36:25.310 | Timed out waiting for MCP response to getAuthStatus. |
| 05:36:25.337 | authenticatedAccountPresent=false; failureType=account_info_token_unavailable. |
| 05:36:46 | An active task is still writing an assistant progress message to its durable rollout. |
| 05:36:50.358 | Desktop logs stop_process; backend is restarted at approximately 05:36:53. |

Other settings requests immediately before the second incident repeatedly returned:
Must use workspace account for this operation.

The user saw an apparent stall followed by the sign-in screen. This is not demonstrated to be an OS crash: during the authentication stall, thread/list and model/list requests still completed in approximately 0–3 ms. No matching Windows Application Error / WER / Application Hang or resource-exhaustion event was found in the inspected window. Approximately 21 GB of 31.84 GB RAM was free after restart; this is not a measurement of memory at the exact failure time.

Relevant client behavior

Read-only inspection of the installed desktop JavaScript found that the forced-refresh path calls getAuthStatus with a 30,000 ms local timeout. The fetchAuthToken catch path calls setAuthTokenCache(null) when the token generation is unchanged. The account-info lookup then reports no authenticated account after that request times out.

This identifies a client path from a transient refresh failure to an apparent logout. It does not establish why the OAuth refresh stalls, whether it is a network/server/internal synchronization issue, or that disk credentials were deleted.

Clearing the external Chrome login-site cookies, explicitly signing out, completing browser authorization again, and restarting did not prevent these later recurrences. We have not established which update introduced the behavior, and have not run a controlled alternate-network or standalone-CLI comparison on this machine.

Impact and requested investigation

Please distinguish a workspace-only settings rejection and a temporary authentication-refresh timeout from a confirmed invalid/revoked login, and investigate the backend refresh operation that stops completing while other RPCs remain responsive.

There is also an independently confirmed stale-history projection defect matching #41079. Returning to the sign-in screen / restarting exposes that stale projection, making later conversation turns appear lost. This is an interaction between two observed failures, not proof that they share one underlying cause.

Privacy: no tokens, account IDs, emails, thread IDs, project names, conversation content, raw logs, or databases are attached. This report was prepared from local read-only diagnostics with the affected user's authorization.