Repository navigation
[Windows][Desktop 26.818] Cached account-settings 401 drops access token without refresh while Remote Control remains functional #39850
Description
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
.codexprofile.
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:
- Desktop reports
authenticatedAccountPresent=true. - Start a normal local task.
- Task execution proceeds normally.
- Near task completion, Desktop sends:
GET /backend-api/accounts/{account_id}/settings - Request uses a cached Desktop UI token:
hadToken=truetokenSource=cached
- Endpoint returns HTTP 401.
- Fetch wrapper marks the request retryable.
- ~363 ms later, app-server auth status reports:
- access token: missing
- refresh token: present
tokenExpiryState=missingnullReason=auth_token_missingcacheWrite=null
- No OAuth refresh-token exchange is observed.
authenticatedAccountPresent=false/account_info_token_unavailablefollows.- Subsequent Desktop requests have
hadToken=false,skipRetryReason=no_token_attached, and return 401/Unauthorized. - 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/listand/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:
- reaches the existing Desktop app-server/root agent session;
- triggers agent reasoning;
- produces an agent message;
- executes an
exectool successfully; - 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
.codexprofile; - 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.execrash;- 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:
- refresh/re-resolve the access token using the still-valid refresh-token state and retry safely; or
- 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.
Activity
github-actions commentedon Aug 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
chrishzc commentedon Aug 21, 2026
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_resultlogging,refreshToken=trueis the request parameter passed togetAuthStatusasking 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.jsandapp.asar/.vite/build/src-Bqg9CB1K.js). No files were modified.Observed logic/sequence:
getAuthToken(refreshToken=false)serves the currentAppServerConnection.authTokenCache.GET /backend-api/accounts/{account_id}/settings.getAuthStatus(includeToken=true, refreshToken=true).setAuthTokenCache({ value: null })and broadcasts auth-token-unavailable.account_info_token_unavailable/authenticatedAccountPresent=false.getCachedAuthToken()calls returnnull.nullis treated as a resolved cached result, rather than a cache miss requiring the app-server to be queried again.no_token_attached/willRetry=false.This forms a sticky negative-cache condition in the Electron main process: once
authTokenCachebecomesnull, 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:
authTokenCachehad previously entered the null/auth-token-missing state~/.codex/auth.jsonexistedProcedure:
~/.codex/auth.jsonuntouched.Result after restart:
~/.codex/auth.jsonwas 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:
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.asaror any MSIX-signed resource. The package uses signed MSIX resources and modifying the bundle would not be an acceptable workaround.chrishzc commentedon Aug 21, 2026
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.jsonand could still successfully call/backend-api/wham/usage(HTTP 200). They also captured an account-settings 401 response indicatingMust use workspace account for this operationwhile 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}/settingsmay 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:
The independent reproduction in #39925 strengthens the case that the initial account-settings 401 itself, rather than token expiry, may be the trigger.
Ccat-Q commentedon Aug 21, 2026
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).hasToken=false nullReason=auth_token_missingwipe there is no refresh attempt — and~/.codex/auth.jsonstill holds a valid refresh_token.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=1appears on every turn start (also on healthy turns with no logout), so it is not the trigger for the wipe.hanao-ai commentedon Aug 21, 2026
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_completedreportssuccess=true./backend-api/accounts/{account_id}/settingsis sent withhadToken=true/tokenSource=cached, but returns HTTP 401.hasToken=falsewithnullReason=auth_token_missing.hadToken=falsewithskipRetryReason=no_token_attachedand continue returning 401.~/.codex/auth.jsonremains present and still contains access, refresh, and ID token data.As a control test, I installed Codex CLI
0.149.0separately 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 operationresponse reported above, so I can only confirm the samehadToken=true → 401 → auth_token_missing → hadToken=falsetransition independently.berkyuo2-cpu commentedon Aug 21, 2026
Independent Windows 10 reproduction: auth-response orphaning plus post-login RPC error boundary
I reproduced the same general failure on 2026-08-21 with:
26.818.3698.026.818.313380.149.0-alpha.4151.0.7922.170This sample adds two details to the sticky-negative-cache diagnosis in this issue:
AppServerManager RPC is not connectedand 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:29account/login/start: 3Failed to refresh authentication token: 7Must use workspace account for this operationresponses: 294AppServerManager RPC is not connectederror boundaries: 2, at 17:29:06 and 23:41:47The counts are event counts, not raw occurrences of the generic UI text.
Sanitized collapse clusters
In the three-minute window preceding each
authenticatedAccountPresent=falsetransition, the logs contain:desktop-authdesktop-authaccount/readaccount/readRepresentative sanitized sequence:
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:
The error boundary occurred 149 ms after login completion. A normal app restart restored
authenticatedAccountPresent=truewithout 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:
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.
kanewong1028 commentedon Aug 22, 2026
I can confirm the same failure on a newer Windows build.
Environment
26.818.4152.0OkChatGPT.exeprocess and one childcodex.exeapp-server were runningSanitized reproduction timeline (UTC)
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
401 application/json) rather than a Cloudflare challenge page.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, oraccount_info_token_unavailableevents, 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.
hanao-ai commentedon Aug 22, 2026
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
~/.codexstate, and rolled Codex Desktop back from26.818.3698.0to an older build.Rollback target
26.810.7004.026.810.520442026-08-15The MSIX was obtained from OpenAI's
persistent.oaistatic.comdistribution URL. Windows Authenticode verification reported:Status: ValidStatusMessage: Signature verifiedResults after rollback
~/.codexstate from the affected 26.818 installation remains in useI also searched the Desktop logs after using both a new project and an existing project for the following failure markers:
desktop_fetch_auth_401auth_token_missingaccount_info_token_unavailableno_token_attachedThere 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 loopSo, at least in my environment, the issue does not reproduce on
26.810.7004.0but does reproduce on26.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.0until a confirmed fixed build is available, then update and retest.Marcus-Tailius commentedon Aug 23, 2026
Additional independent reproduction on a newer 26.818 Windows build, specifically while using an SSH-discovered headless Remote host.
Environment:
26.818.4170526.818.5345.0Sanitized timeline from the Desktop log:
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=trueinauth_status_resultas 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.0build, not only the earlier26.818.31338 / 26.818.3698.0build.qiankun229 commentedon Aug 24, 2026
I have the same issue on Windows Codex Desktop 26.818.5229.0 with a personal ChatGPT Plus account.
Environment:
Symptoms:
Investigation results:
Reproduction timeline:
GET /backend-api/accounts/{account_id}/settings
hadToken=true).hasToken=false
nullReason=auth_token_missing
refreshToken=true
Historical logs also contain:
Must use workspace account for this operation
The problem appears to be:
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.
qiankun229 commentedon Aug 24, 2026
Additional reproduction on Windows with a personal ChatGPT Plus account.
Environment
OpenAI.Codex_26.818.5229.0I was able to reproduce the failure deterministically when opening an existing conversation.
Observed sequence
Historical Desktop logs contain 95 occurrences of:
Additional exclusions
~/.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:
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.