[Windows][Desktop 26.818] Cached account-settings 401 drops access token without refresh while Remote Control remains functional

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

• #39803
• #39718
• #39829
• #39695
• #39684

Powered by Codex Action

Additional findings from read-only local bundle inspection and a controlled A/B restart test:

Correction to my earlier interpretation

In the local auth_status_result logging, refreshToken=true is the request parameter passed to getAuthStatus asking it to refresh, not proof by itself that a refresh token exists. Please do not treat that field alone as refresh-token-presence evidence.

The stronger finding is in the Desktop main-process auth cache behavior below.

Failing state transition located in the Desktop bundle

Read-only inspection of the installed production resources located the relevant auth path in the packaged Electron JS bundles (for example app.asar/.vite/build/main-B6Z1yw33.js and app.asar/.vite/build/src-Bqg9CB1K.js). No files were modified.

Observed logic/sequence:

1. getAuthToken(refreshToken=false) serves the current AppServerConnection.authTokenCache.
2. The cached token is attached to GET /backend-api/accounts/{account_id}/settings.
3. The request receives HTTP 401 and the fetch wrapper allows one retry.
4. Desktop calls getAuthStatus(includeToken=true, refreshToken=true).
5. That call returns ChatGPT auth mode but no access token.
6. Desktop calls setAuthTokenCache({ value: null }) and broadcasts auth-token-unavailable.
7. Renderer transitions to account_info_token_unavailable / authenticatedAccountPresent=false.
8. Subsequent getCachedAuthToken() calls return null.
9. null is treated as a resolved cached result, rather than a cache miss requiring the app-server to be queried again.
10. New requests therefore have no Authorization token.
11. Because the retry path requires the original request to have had a token, subsequent 401s are classified as no_token_attached / willRetry=false.

This forms a sticky negative-cache condition in the Electron main process: once authTokenCache becomes null, Desktop remains signed out for that process lifetime.

Controlled cold-restart A/B test

I tested whether clearing only process-local state would recover the UI without login/logout or touching credentials.

Baseline while affected:

• Desktop visibly signed out
• authTokenCache had previously entered the null/auth-token-missing state
• ~/.codex/auth.json existed
• its size, mtime and SHA-256 were recorded

Procedure:

1. Waited until all active Desktop/child-agent work finished.
2. Gracefully exited the Desktop app and its Desktop-owned app-server.
3. Left ~/.codex/auth.json untouched.
4. Relaunched Codex Desktop manually.
5. Did not perform login or logout.

Result after restart:

• Desktop opened directly into the normal authenticated UI.
• Projects/history/composer were available.
• No login interaction was required.
• ~/.codex/auth.json was byte-for-byte unchanged (same size, timestamp, SHA-256).

This strongly supports the authentication failure being process-local/sticky cache state rather than loss of persistent credentials.

Re-trigger after one task

I then started one fresh minimal Desktop task (Reply only with: auth test).

Immediately after that task lifecycle, Desktop returned to the Sign in to ChatGPT screen again.

So the practical behavior is:

Desktop task
-> account/auth path hits 401
-> authTokenCache becomes sticky null
-> Desktop UI becomes signed out
-> full Desktop process restart (without login, logout, or auth.json changes)
-> authenticated UI is restored
-> run one new task
-> signed-out state reproduces again

This means a cold Desktop restart is only a temporary recovery, not a root fix.

Workaround impact

For affected 26.818 installations, a full Desktop restart can recover the signed-in UI without reauthentication as long as persistent credentials remain valid, but the next task can re-trigger the same failure. The bundled CLI and an already-established Remote Control session continue to work, so the execution plane remains healthy while the Desktop UI auth cache is poisoned.

I did not patch app.asar or any MSIX-signed resource. The package uses signed MSIX resources and modifying the bundle would not be an acceptable workaround.

Cross-reference: #39925 appears to be an independent reproduction of the same general 26.818 Windows Desktop auth failure, with two additional observations that may help narrow the trigger.

In #39925, the reporter observed that after Desktop fell back to the sign-in state, the access token persisted in auth.json and could still successfully call /backend-api/wham/usage (HTTP 200). They also captured an account-settings 401 response indicating Must use workspace account for this operation while the account was a Plus/personal account.

That is particularly interesting relative to the state-machine behavior documented here: a feature/account-scope 401 from /backend-api/accounts/{account_id}/settings may be getting treated by the generic Desktop auth retry path as evidence that the entire ChatGPT access token is invalid. The main-process cache is then driven into the sticky-null state described above even though the token may remain valid for other endpoints.

#39925 also reports an isolated refresh-token invalidation experiment; I am not treating that as proven to be the same root cause here, but it may be useful for maintainers investigating credential lifecycle separately.

So a candidate combined failure chain worth checking is:

personal/Plus account
-> Desktop requests an account/workspace-specific settings endpoint
-> endpoint returns a scope/workspace-related 401
-> generic auth wrapper interprets 401 as invalid access token
-> refresh/re-resolution returns no token
-> AppServerConnection.authTokenCache becomes null
-> null remains a sticky negative cache hit
-> Desktop UI becomes signed out

The independent reproduction in #39925 strengthens the case that the initial account-settings 401 itself, rather than token expiry, may be the trigger.

Independent confirmation of this exact failure chain on the same build (26.818.3698.0 + 0.149.0-alpha.4), personal Plus account:

• GET /backend-api/accounts/{id}/settings → 401 {"detail":"Must use workspace account for this operation"} even with a valid Bearer token (the same token returns 200 on /backend-api/me, /wham/onboarding/context, /wham/tasks/list).
• Between the 401 and the hasToken=false nullReason=auth_token_missing wipe there is no refresh attempt — and ~/.codex/auth.json still holds a valid refresh_token.
• Additional correlated signal: GET /payments/payment_methods → 400 {"detail":"Payment methods for mobile subscriptions must be managed in the mobile platform."} — the Plus subscription is mobile-IAP. Worth checking whether the settings 401 is tied to that account state.
• DeviceCheck attestation unavailable errorCode=1 appears on every turn start (also on healthy turns with no logout), so it is not the trigger for the wipe.

I’m seeing what appears to be the same failure pattern on Windows Codex Desktop 26.818.3698.0.

After a successful interactive ChatGPT login:

• account_login_completed reports success=true.
• The first authenticated request to /backend-api/accounts/{account_id}/settings is sent with hadToken=true / tokenSource=cached, but returns HTTP 401.
• Immediately afterward, auth status changes to hasToken=false with nullReason=auth_token_missing.
• Subsequent requests use hadToken=false with skipRetryReason=no_token_attached and continue returning 401.
• ~/.codex/auth.json remains present and still contains access, refresh, and ID token data.

As a control test, I installed Codex CLI 0.149.0 separately on the same Windows machine and used the same ChatGPT authentication. The CLI successfully completed an actual model request (codex exec), so the account credentials and network path appear to be working outside the Desktop app.

I also tried Windows app Repair, Reset, and a full uninstall → reboot → reinstall of Codex Desktop, with no change in the login loop.

I did not capture the specific Must use workspace account for this operation response reported above, so I can only confirm the same hadToken=true → 401 → auth_token_missing → hadToken=false transition independently.

Independent Windows 10 reproduction: auth-response orphaning plus post-login RPC error boundary

I reproduced the same general failure on 2026-08-21 with:

• Windows 10 Pro 22H2, build 19045, x64
• Codex Desktop MSIX: 26.818.3698.0
• UI/browser-use release: 26.818.31338
• bundled Codex CLI/app-server: 0.149.0-alpha.4
• Chromium: 151.0.7922.170

This sample adds two details to the sticky-negative-cache diagnosis in this issue:

1. Some refresh attempts are logged, but their Desktop request mappings become orphaned.
2. After interactive login reports completion, the renderer can immediately hit AppServerManager RPC is not connected and show the generic “Oops, an error has occurred” page.

Frequency in one local day

From the Desktop logs for 2026-08-21 (Europe/Istanbul local time):

• authenticatedAccountPresent=false / account_info_token_unavailable: 3 distinct collapses, at 16:46:45, 17:23:52, and 23:33:29
• account/login/start: 3
• login flow completion markers: 3
• Failed to refresh authentication token: 7
• cached account-settings 401 markers: 302
• corresponding Must use workspace account for this operation responses: 294
• AppServerManager RPC is not connected error boundaries: 2, at 17:29:06 and 23:41:47

The counts are event counts, not raw occurrences of the generic UI text.

Sanitized collapse clusters

In the three-minute window preceding each authenticatedAccountPresent=false transition, the logs contain:

| Collapse (local) | account-settings 401 | refresh failed | orphaned desktop-auth | “No promise” desktop-auth | orphaned account/read | “No promise” account/read |
|---|---:|---:|---:|---:|---:|---:|
| 16:46:45 | 5 | 2 | 3 | 6 | 4 | 8 |
| 17:23:52 | 3 | 1 | 2 | 4 | 2 | 4 |
| 23:33:29 | 3 | 2 | 3 | 6 | 5 | 10 |

Representative sanitized sequence:

desktop_fetch_auth_401 hadToken=true tokenSource=cached willRetry=true
sa_server_request_failed ... "Failed to refresh authentication token" ... status=401
response_orphaned ... requestId=desktop-auth:<redacted>
No promise for request ID ... desktop-auth:<redacted>
response_orphaned ... requestId=account/read:<redacted>
No promise for request ID ... account/read:<redacted>
chatgpt-account-lookup ... authenticatedAccountPresent=false
  failureType=account_info_token_unavailable result=failed
account/login/start

This suggests that, in this reproduction, the refresh/re-resolution path is not simply absent: responses are sometimes produced after the Desktop-side pending-request mapping has already been discarded. That can still drive the renderer into the same sticky unauthenticated state.

Exact final recurrence and “Oops” transition

The third recurrence was:

23:32:10  Failed to refresh authentication token
23:32:50  Failed to refresh authentication token
23:33:29  authenticatedAccountPresent=false / account_info_token_unavailable
23:34:34  account/login/start
23:41:47.215  login flow completion marker
23:41:47.364  error boundary:
                AppServerManager RPC is not connected
23:42:36  old app-server connection stopped
23:42:52  new Desktop generation started
23:42:56  authenticatedAccountPresent=true

The error boundary occurred 149 ms after login completion. A normal app restart restored authenticatedAccountPresent=true without another login, which is consistent with process-local stale auth/RPC state rather than lost persistent credentials.

The highest-confidence combined failure chain in this sample is:

personal-account settings endpoint returns workspace-only 401
-> Desktop auth refresh/re-resolution starts
-> desktop-auth/account-read responses become orphaned
-> renderer resolves account as unavailable and starts browser login
-> login completes
-> AppServerManager RPC is not connected
-> React error boundary shows “Oops, an error has occurred”
-> cold process restart restores authenticated state

This also overlaps the RPC/account-transition lifecycle problem in #39677, but the initial trigger and repeated auth collapse match this issue closely.

No access/refresh tokens, cookies, account IDs, device IDs, thread IDs, request IDs, process IDs, email addresses, local paths, or raw log archives are included.

I can confirm the same failure on a newer Windows build.

Environment

• Windows x64
• Microsoft Store / MSIX package: 26.818.4152.0
• Package status: Ok
• Store reported no newer upgrade available on 2026-08-22
• Login method: ChatGPT
• Exactly one root ChatGPT.exe process and one child codex.exe app-server were running

Sanitized reproduction timeline (UTC)

10:41:03  authenticatedAccountPresent=true
11:24:09  GET /backend-api/accounts/{account_id}/settings -> HTTP 401
           hadToken=true, tokenSource=cached, willRetry=true
11:24:11  hasToken=false, refreshToken=true,
           tokenExpiryState=missing,
           nullReason=auth_token_missing,
           cacheWrite=null
11:24:11  authenticatedAccountPresent=false,
           failureType=account_info_token_unavailable
11:24:12  subsequent request hadToken=false,
           skipRetryReason=no_token_attached
11:24:43–11:29:48  repeated /wham/* 401 responses without a token
11:29:39  account/login/start
11:29:48  account_login_completed success=true
11:29:50  authenticatedAccountPresent=true

This is the same transition described in the issue: a cached account-settings 401 invalidates the access token, the refresh token remains present, but Desktop does not recover through refresh and instead shows the sign-in screen.

Controls / exclusions

• The apparent C:/D: split is not a duplicate installation. The registered C: package directory is a Windows Junction to the D: package store; both paths resolve to the same file ID.
• There was only one root Desktop instance, with no related startup entry or scheduled task.
• The current network path returned normal unauthenticated API responses (401 application/json) rather than a Cloudflare challenge page.
• System time was accurate.
• Earlier local repair helpers were not running and had no scheduled trigger when this 11:24 UTC failure occurred.

After interactive login, a new encrypted auth record was written. From 11:30 through 11:46 UTC there were zero additional desktop_fetch_auth_401, auth_token_missing, or account_info_token_unavailable events, and three periodic feature/config refreshes succeeded. However, the same sign-in failure has occurred repeatedly across Desktop sessions, so the fresh login is only a temporary recovery.

No tokens, cookies, account IDs, device IDs, thread IDs, or raw logs are included here.

Follow-up to my earlier report with an additional A/B rollback test.

I kept the same Windows PC, the same ChatGPT account, and the same existing ~/.codex state, and rolled Codex Desktop back from 26.818.3698.0 to an older build.

Rollback target

• Microsoft Store / MSIX package: 26.810.7004.0
• In-app version: 26.810.52044
• Release date shown in the app: 2026-08-15

The MSIX was obtained from OpenAI's persistent.oaistatic.com distribution URL. Windows Authenticode verification reported:

• Status: Valid
• StatusMessage: Signature verified
• Microsoft Marketplace CA signing chain
• Valid Microsoft Time-Stamp Service timestamp

Results after rollback

• ChatGPT login remains stable
• New projects work normally
• Existing projects work normally
• Multiple interactions complete without returning to the sign-in screen
• Built-in browser operations work normally
• The same existing ~/.codex state from the affected 26.818 installation remains in use

I also searched the Desktop logs after using both a new project and an existing project for the following failure markers:

• desktop_fetch_auth_401
• auth_token_missing
• account_info_token_unavailable
• no_token_attached

There were no matches after the rollback.

By contrast, on 26.818.3698.0, the same PC, account, and local Codex state consistently reproduced the transition I reported earlier:

hadToken=true → /accounts/{account_id}/settings 401 → auth_token_missing → hadToken=false → sign-in loop

So, at least in my environment, the issue does not reproduce on 26.810.7004.0 but does reproduce on 26.818.3698.0.

This A/B result may help narrow the regression window to somewhere between the 26.810 and 26.818 Desktop releases.

Before performing the rollback, I made a complete backup of ~/.codex. This is an unofficial workaround that worked in my environment only; I cannot guarantee that it will work safely on other systems or preserve all local state. Anyone attempting a similar rollback should make a complete backup first and proceed at their own risk.

For now, I plan to remain on 26.810.7004.0 until a confirmed fixed build is available, then update and retest.

Additional independent reproduction on a newer 26.818 Windows build, specifically while using an SSH-discovered headless Remote host.

Environment:

• Windows Codex Desktop UI release: 26.818.41705
• Windows MSIX package observed in stack path: 26.818.5345.0
• Remote host: SSH-discovered Linux/headless Codex host
• ChatGPT login itself succeeds
• Re-authenticating the headless remote CLI again via device-code flow does not change the Desktop failure

Sanitized timeline from the Desktop log:

10:10:42.485  maybe_resume_started ... hostId=remote-ssh-discovered:<host>
10:10:43.678  thread/resume -> success
10:10:44.858  maybe_resume_success ... latestTurnStatus=completed
10:10:45.241  GET /backend-api/accounts/{account_id}/settings -> 401
                desktop_fetch_auth_401 hadToken=true tokenSource=cached willRetry=true
10:10:46.428  authMethod=chatgpt hasToken=false
                nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing
10:10:46.441  authenticatedAccountPresent=false
                failureType=account_info_token_unavailable
10:10:46.699  subsequent request: hadToken=false
                skipRetryReason=no_token_attached
10:10:47.021  /accounts/{account_id}/settings -> 401
                "Missing valid access token or actor biscuit"
10:10:47.076  /wham/onboarding/context -> 401 Unauthorized
10:11:09+     /wham/tasks/list continues returning 401 every ~60s with no token

The important control here is that the Remote thread successfully resumes before the Desktop UI auth collapses. This makes the SSH/Remote host connection and remote CLI authentication unlikely to be the root cause.

Also, a full Desktop process restart only restores the UI temporarily; after opening/running a Remote conversation, the same account-settings 401 -> auth_token_missing -> signed-out transition reproduces again.

One caveat matching the correction already noted above: I am not treating refreshToken=true in auth_status_result as proof that a refresh token exists; the useful evidence is the observed transition from a cached token on the first request to a sticky no-token state immediately after the 401.

There was also a separate no rollout found for thread id ... error for one older thread, but a different Remote thread resumed successfully and then hit the same auth collapse, so that rollout error appears unrelated.

This confirms the issue still reproduces on the newer 26.818.41705 / 26.818.5345.0 build, not only the earlier 26.818.31338 / 26.818.3698.0 build.

I have the same issue on Windows Codex Desktop 26.818.5229.0 with a personal ChatGPT Plus account.

Environment:

• OS: Windows 10 x64
• Codex Desktop: OpenAI.Codex_26.818.5229.0
• Standalone Codex CLI: works normally with the same account

Symptoms:

• Desktop login succeeds.
• Existing conversations load successfully.
• A few seconds later, Desktop signs out.

Investigation results:

• The shared auth token is valid and not expired.
• Codex CLI continues working with the same account.
• Network/proxy issues were ruled out.
• Clearing Desktop Chromium profile did not fix it.

Reproduction timeline:

1. Desktop login completes successfully.
2. Opening an existing conversation succeeds (history API returns HTTP 200).
3. Desktop then calls:

GET /backend-api/accounts/{account_id}/settings

1. The request returns HTTP 401 while the request still has a valid token (hadToken=true).
2. Desktop changes auth state to:

hasToken=false
nullReason=auth_token_missing
refreshToken=true

1. The UI returns to the login screen.

Historical logs also contain:

Must use workspace account for this operation

The problem appears to be:

• Personal account context is rejected by the account settings endpoint.
• Desktop incorrectly treats this optional settings failure as a global authentication failure.

Expected:
A failed account settings request should not invalidate an otherwise valid ChatGPT/Codex session.

CLI remains usable, which suggests the core credential is valid and the issue is limited to Desktop authentication state handling.

Additional reproduction on Windows with a personal ChatGPT Plus account.

Environment

• Windows 10 x64
• Codex Desktop package: OpenAI.Codex_26.818.5229.0
• ChatGPT Plus personal account
• Standalone Codex CLI remains fully functional with the same account

I was able to reproduce the failure deterministically when opening an existing conversation.

Observed sequence

1. Codex Desktop starts authenticated normally.
2. Opening an existing conversation succeeds. The conversation/history request returns HTTP 200.
3. Immediately afterward Desktop requests:

GET /backend-api/accounts/{account_id}/settings

1. That request returns HTTP 401 while the Desktop log still reports:

hadToken=true

1. About one second later the Desktop auth state changes to:

hasToken=false
nullReason=auth_token_missing

1. A subsequent request returns:

Missing valid access token or actor biscuit

1. Desktop redirects to the ChatGPT sign-in screen.

Historical Desktop logs contain 95 occurrences of:

Must use workspace account for this operation

Additional exclusions

• The access token was not expired.
• Standalone Codex CLI continued working with the same account/token.
• Other requests were returning HTTP 200 during the failure, so this was not a general network outage.
• The existing conversation itself loaded successfully before the auth failure.
• I completely isolated/rebuilt the Desktop Chromium profile while preserving ~/.codex/auth.json. The issue reproduced again in the fresh profile, so stale cookies/cache/local storage do not appear to be the root cause.

The reproducible chain on my machine is therefore:

open existing conversation
→ conversation loads successfully (200)
→ /accounts/{account_id}/settings returns 401
→ Desktop changes auth state to auth_token_missing
→ Desktop signs the user out

This appears consistent with this issue and also with #39189.

The important additional observation is that opening an existing conversation is a reliable trigger on my installation, while the conversation itself is accessible and successfully loads before the unrelated account-settings 401 invalidates the Desktop authentication state.

I can provide additional sanitized timestamps/log excerpts if useful. No tokens, account IDs, email addresses, or conversation IDs have been included.