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

What version of the Codex App are you using?

• About Codex / UI release: 26.818.31338
• Windows MSIX package: 26.818.3698.0
• Bundled Codex CLI/app-server: 0.149.0-alpha.4
• Electron/Chromium executable: 151.0.7922.170
• Release observed: 2026-08-21

Platform

Windows x64.

Summary

Codex Desktop can lose its Desktop UI authentication near the end of an otherwise successful task. A cached UI token receives HTTP 401 from the account-settings endpoint; Desktop invalidates the access token, but does not attempt a refresh-token exchange even though refresh-token metadata remains present. Desktop then transitions to authenticatedAccountPresent=false and /wham/* requests continue failing with 401.

The Codex execution plane remains healthy: the bundled CLI works normally, the Desktop app-server stays alive, and an already-established mobile Remote Control session can continue executing tools through the same Desktop app-server while the Desktop UI visibly shows the signed-out screen.

This appears adjacent to #39677, but the distinguishing evidence here is a deterministic cached account-settings 401 -> access token missing -> refresh token still present -> no refresh exchange transition on 26.818, plus Remote Control continuing to work through the same app-server.

Initial symptom

The original symptom was Codex Desktop exiting during task execution and repeatedly requiring authentication. It reproduced with:

• an empty project;
• a new thread;
• a fresh .codex profile.

The bundled codex.exe, invoked directly, authenticates, calls the model, executes PowerShell tools, completes tasks, and remains running.

After isolating regenerable Desktop Chromium/OWL caches and reauthenticating through the official Desktop login flow, the process-exit symptom stopped reproducing during testing, but the authentication collapse below remained reproducible.

Reproducible authentication failure

After a successful interactive ChatGPT login:

1. Desktop reports authenticatedAccountPresent=true.
2. Start a normal local task.
3. Task execution proceeds normally.
4. Near task completion, Desktop sends:
   GET /backend-api/accounts/{account_id}/settings
5. Request uses a cached Desktop UI token:
   • hadToken=true
   • tokenSource=cached
6. Endpoint returns HTTP 401.
7. Fetch wrapper marks the request retryable.
8. ~363 ms later, app-server auth status reports:
   • access token: missing
   • refresh token: present
   • tokenExpiryState=missing
   • nullReason=auth_token_missing
   • cacheWrite=null
9. No OAuth refresh-token exchange is observed.
10. authenticatedAccountPresent=false / account_info_token_unavailable follows.
11. Subsequent Desktop requests have hadToken=false, skipRetryReason=no_token_attached, and return 401/Unauthorized.
12. The task itself can still complete successfully.

Sanitized timeline from one reproduction

11:15:45.922  manual login completed, success=true
11:15:47.033  authenticatedAccountPresent=true
11:16:07.038  thread/start
11:16:12.958  main turn/start
11:16:25.226  GET /backend-api/accounts/{account_id}/settings -> HTTP 401
                hadToken=true, tokenSource=cached, willRetry=true
11:16:25.589  hasToken=false, refreshToken=true,
                tokenExpiryState=missing,
                nullReason=auth_token_missing,
                cacheWrite=null
11:16:25.730  authenticatedAccountPresent=false,
                account_info_token_unavailable
11:16:25.778  Missing valid access token
11:16:25.826  next request hadToken=false, no_token_attached
11:16:25.839  task completes successfully
11:16:25.847  onboarding request -> Unauthorized
11:16:48.860  tasks/list continues returning 401 without token

Refresh is never attempted

No refresh-token exchange, OAuth token request, refresh RPC, or refresh HTTP request was observed after the first 401.

The observable transition is:

valid Desktop session
-> cached account-settings token rejected with 401
-> cached access token invalidated
-> access token missing
-> refresh token still present
-> expiry metadata missing
-> auth_token_missing
-> no refresh attempted
-> authenticatedAccountPresent=false

This looks like a missing state transition between 401 token invalidation and refresh-token recovery, potentially at the Desktop electron-fetch-wrapper / auth-manager / app-server auth-cache boundary.

Persistent auth state remains intact

~/.codex/auth.json remains present after this task-time authentication collapse. Its size and modification timestamp do not change when the in-memory/Desktop auth state fails.

A manual official Desktop login recreates/refreshes both Desktop web-session state and ~/.codex/auth.json successfully, but the same task-time auth collapse can recur afterward.

No credential/token values are included here.

Remote Control continues working while Desktop UI is signed out

After the authentication collapse:

• Desktop UI authenticated: NO
• Desktop access token: MISSING
• Refresh token metadata: PRESENT
• /wham/tasks/list and /wham/usage: repeated 401 Unauthorized
• Desktop UI shows the ChatGPT sign-in screen

However, an already-established mobile Remote Control session remains functional.

A remote user message:

1. reaches the existing Desktop app-server/root agent session;
2. triggers agent reasoning;
3. produces an agent message;
4. executes an exec tool successfully;
5. returns the tool result.

The same existing Desktop app-server handles the remote task. The Desktop renderer receives event broadcasts but is not required to receive or execute the remote task. No new Desktop UI token refresh occurs for the remote task.

This strongly suggests the live Remote Control authorization/session path is operationally separate from the broken Desktop UI account-token path.

Logout transition also exposes an RPC lifecycle race

A manual Desktop logout itself completes successfully. Immediately afterward:

account/logout success
-> persistent auth cleared
-> account API / pinned-thread sync continues
-> main AppServer RPC stub is disposed
-> renderer attempts to use disposed RPC session
-> `AppServerManager RPC is not connected`
-> React error boundary
-> `Oops, an error has occurred`

Desktop and app-server processes remain alive in this case. No EPIPE/native crash is required.

Earlier process-exit sequence

Before isolating regenerable Desktop renderer/browser caches, failures sometimes showed:

IAB/Browser route window not live
-> route/window removal
-> IPC reset / EPIPE
-> AppServerManager disconnect / RPC disposal
-> app-server stop_process
-> Desktop exit

After cache isolation, that process-exit sequence did not reproduce in subsequent controlled tests, but the authentication failure described above remained reproducible.

Control tests / exclusions

Investigated and not supported as the primary cause:

• project contents;
• fresh vs existing .codex profile;
• SQLite lock/corruption;
• WSL (Desktop launches native Windows app-server over stdio);
• stale app-server process;
• native access violation / current Crashpad crash;
• codex-code-mode-host.exe crash;
• MCP startup warnings;
• agent configuration warnings.

The bundled CLI/runtime is a useful control: direct execution of the same bundled codex.exe successfully runs model and tool tasks without the Desktop failure.

Expected behavior

On a 401 from a cached Desktop account API token, Codex Desktop should either:

1. refresh/re-resolve the access token using the still-valid refresh-token state and retry safely; or
2. fail authentication explicitly without leaving the renderer, app-server RPC, and Remote Control/task state in inconsistent states.

A transient account-settings 401 should not cause the Desktop UI to become signed out while the execution backend and existing Remote Control session remain usable.

Suspected defect boundary

Highest-confidence candidate: Desktop auth manager, specifically coordination between the Desktop electron-fetch-wrapper 401 invalidation/retry path and app-server authentication cache.

Secondary issue: renderer/AppServerManager lifecycle race during authentication transitions.

Related issue

#39677 appears closely related (OAuth/account transition can disconnect AppServerManager while tasks continue), but this report adds a reproducible 26.818 auth state-machine trace where auth_token_missing occurs while refresh-token metadata remains present and no refresh exchange is attempted.

I can provide additional sanitized timestamps/log excerpts if maintainers need them. Raw tokens, cookies, account IDs, device IDs, thread IDs, and credentials have intentionally been omitted.

Start with the Desktop electron-fetch-wrapper, auth manager, and app-server authentication cache boundaries named in the report. Reproduce the cached account-settings 401 sequence and inspect the transition from token invalidation to auth_token_missing while refresh metadata remains present. Done means the documented recovery or explicit failure path no longer leaves the Desktop UI and app-server state inconsistent.