What version of the Codex App are you using?
Windows Appx package: OpenAI.Codex_26.818.2441.0_x64__2p2nqsd0c76g0
Desktop log release identifier: 26.818.21641
Primary runtime bundle observed in logs: 26.819.11345 (already-current; this is the runtime bundle, not the Desktop Appx version).
What platform is your computer?
Windows x64.
What issue are you seeing?
Codex Desktop starts authenticated and can complete exactly one new conversation response. Immediately after the first response completes, the Desktop UI switches to the Log in to ChatGPT screen.
Closing the Desktop app and reopening it shows the account as signed in again. Repeating the test produces the same behavior.
ChatGPT Web remains signed in and works normally. Codex CLI, using the same account and network/proxy, also authenticates automatically and can complete multiple consecutive turns normally.
A full uninstall/reinstall and clearing/recreating Codex local state did not resolve the Desktop issue.
This does not look like an account-wide authorization failure; the failure appears specific to Desktop auth recovery after an app-server restart.
Reproduction
- Start Codex Desktop on Windows. Account is authenticated normally.
- Create a new conversation.
- Send a simple prompt such as
hello.
- The first response completes successfully.
- Immediately afterward, Desktop switches to the ChatGPT login screen.
- Quit Desktop and reopen it.
- The app is authenticated again without an account-wide login failure.
- Repeat and observe the same first-response-then-login behavior.
Local diagnostic evidence
A read-only investigation of the Desktop logs captured the following sequence on 2026-08-20 (local time):
22:46:20: authentication healthy; authenticatedAccountPresent=true.22:46:23: another renderer also reports authenticatedAccountPresent=true.22:47:07.525: method=config/batchWrite.- Immediately nearby:
method=windowsSandbox/readiness.
22:47:08.030: Desktop explicitly requests an app-server restart:
Restart requestedintent=restartkillCodexProcess=falsetransportKind=stdio
- Existing connection (
connectionId=1) is stopped.
22:47:08.144: a new codex.exe is spawned (old PID 17956; new PID 4048).22:47:08.212: app-server initialization/handshake succeeds.22:47:08.213: connection returns to connected.22:47:08.254: first post-restart getAuthStatus / account/read activity.22:47:30.465: first desktop_fetch_auth_401.22:47:31.502: logs explicitly show:
auth_token_missingtokenExpiryState=missingauthenticatedAccountPresent=false
/accounts/.../settings and /wham/onboarding/context return 401.- Subsequent
/wham/tasks/list and /wham/usage requests continue returning 401.
No 403, password failure, account suspension indication, or explicit server-side logout was observed.
Restart analysis
The app-server restart appears to be an intentional Desktop control path, not a crash/recovery path.
No evidence was found in the relevant window for:
- panic/crash/fatal error
- abnormal child-process exit
- timeout-triggered restart
- retry exhaustion
- Windows Error Reporting/Application Error
- Schannel/TCP/network-change event triggering the restart
The logs instead show a normal controlled sequence: Restart requested -> stop stdio transport -> spawn new app-server -> successful initialize handshake.
The closest preceding operation is config/batchWrite, but the available log does not expose the payload/caller/call stack, so it is not possible to claim that the config write caused the auth loss.
The strongest supported conclusion is that authentication is healthy before the Desktop-requested app-server restart, while the post-restart auth recovery path later reaches desktop_fetch_auth_401 and auth_token_missing.
Network/environment observations
The affected machine had a local proxy/TUN setup (127.0.0.1:7897; user Internet Settings proxy enabled). ChatGPT Web and Codex CLI use the same account/network path and remain functional, including multiple consecutive CLI turns. Therefore a Desktop-specific interaction with the network stack cannot be fully excluded, but there is no evidence that the account or general Codex authentication is unavailable.
WebView2 was running normally. Windows event logs did not show a relevant certificate/WebView2 fatal error.
Reinstall result
The Desktop app and Codex local state were completely removed/reinstalled/recreated before retesting. The issue still reproduced: a fresh Desktop session completes one response and then switches to the login screen.
Expected behavior
A controlled app-server restart should preserve or restore the authenticated Desktop account state. After restart, getAuthStatus / account/read should recover the existing authenticated session rather than transitioning to auth_token_missing and forcing the login UI.
Potentially related issues
This appears related to other Windows Desktop authentication/401 reports, but this reproduction includes a specific transition from healthy authentication through a Desktop-requested app-server restart to auth_token_missing.
Additional information / missing diagnostic evidence
The local logs do not expose enough information to determine the exact root cause. The most useful missing diagnostics are:
- The non-sensitive config keys/payload involved in the
config/batchWrite immediately before restart.
- The caller/reason/call stack that requested
AppServerConnection restart.
- The result of the token-store/auth-state read performed by the newly spawned app-server.
- Whether auth state is expected to be handed off from the Desktop shell/renderer or independently reloaded after an app-server restart.
No access tokens, refresh tokens, cookies, credentials, private project contents, or other secrets are included in this report.
What version of the Codex App are you using?
Windows Appx package:
OpenAI.Codex_26.818.2441.0_x64__2p2nqsd0c76g0Desktop log release identifier:
26.818.21641Primary runtime bundle observed in logs:
26.819.11345(already-current; this is the runtime bundle, not the Desktop Appx version).What platform is your computer?
Windows x64.
What issue are you seeing?
Codex Desktop starts authenticated and can complete exactly one new conversation response. Immediately after the first response completes, the Desktop UI switches to the Log in to ChatGPT screen.
Closing the Desktop app and reopening it shows the account as signed in again. Repeating the test produces the same behavior.
ChatGPT Web remains signed in and works normally. Codex CLI, using the same account and network/proxy, also authenticates automatically and can complete multiple consecutive turns normally.
A full uninstall/reinstall and clearing/recreating Codex local state did not resolve the Desktop issue.
This does not look like an account-wide authorization failure; the failure appears specific to Desktop auth recovery after an app-server restart.
Reproduction
hello.Local diagnostic evidence
A read-only investigation of the Desktop logs captured the following sequence on 2026-08-20 (local time):
22:46:20: authentication healthy;authenticatedAccountPresent=true.22:46:23: another renderer also reportsauthenticatedAccountPresent=true.22:47:07.525:method=config/batchWrite.method=windowsSandbox/readiness.22:47:08.030: Desktop explicitly requests an app-server restart:Restart requestedintent=restartkillCodexProcess=falsetransportKind=stdioconnectionId=1) is stopped.22:47:08.144: a newcodex.exeis spawned (old PID 17956; new PID 4048).22:47:08.212: app-server initialization/handshake succeeds.22:47:08.213: connection returns toconnected.22:47:08.254: first post-restartgetAuthStatus/account/readactivity.22:47:30.465: firstdesktop_fetch_auth_401.22:47:31.502: logs explicitly show:auth_token_missingtokenExpiryState=missingauthenticatedAccountPresent=false/accounts/.../settingsand/wham/onboarding/contextreturn 401./wham/tasks/listand/wham/usagerequests continue returning 401.No 403, password failure, account suspension indication, or explicit server-side logout was observed.
Restart analysis
The app-server restart appears to be an intentional Desktop control path, not a crash/recovery path.
No evidence was found in the relevant window for:
The logs instead show a normal controlled sequence:
Restart requested-> stop stdio transport -> spawn new app-server -> successful initialize handshake.The closest preceding operation is
config/batchWrite, but the available log does not expose the payload/caller/call stack, so it is not possible to claim that the config write caused the auth loss.The strongest supported conclusion is that authentication is healthy before the Desktop-requested app-server restart, while the post-restart auth recovery path later reaches
desktop_fetch_auth_401andauth_token_missing.Network/environment observations
The affected machine had a local proxy/TUN setup (
127.0.0.1:7897; user Internet Settings proxy enabled). ChatGPT Web and Codex CLI use the same account/network path and remain functional, including multiple consecutive CLI turns. Therefore a Desktop-specific interaction with the network stack cannot be fully excluded, but there is no evidence that the account or general Codex authentication is unavailable.WebView2 was running normally. Windows event logs did not show a relevant certificate/WebView2 fatal error.
Reinstall result
The Desktop app and Codex local state were completely removed/reinstalled/recreated before retesting. The issue still reproduced: a fresh Desktop session completes one response and then switches to the login screen.
Expected behavior
A controlled app-server restart should preserve or restore the authenticated Desktop account state. After restart,
getAuthStatus/account/readshould recover the existing authenticated session rather than transitioning toauth_token_missingand forcing the login UI.Potentially related issues
This appears related to other Windows Desktop authentication/401 reports, but this reproduction includes a specific transition from healthy authentication through a Desktop-requested app-server restart to
auth_token_missing.Additional information / missing diagnostic evidence
The local logs do not expose enough information to determine the exact root cause. The most useful missing diagnostics are:
config/batchWriteimmediately before restart.AppServerConnectionrestart.No access tokens, refresh tokens, cookies, credentials, private project contents, or other secrets are included in this report.