Windows desktop intermittently prompts for login after getAuthStatus takes ~10 seconds

Summary

The Codex/ChatGPT Windows desktop app intermittently treats a cached authenticated session as signed out during startup and prompts for browser login again.

The failures correlate with the initial getAuthStatus request taking almost exactly 10 seconds. A successful cold relaunch completed the same request in about 5.2 seconds.

Environment

• Windows desktop app package: OpenAI.Codex_26.915.4065.0
• Desktop release reported in logs: 26.915.31945
• Platform: Windows x64
• Sign-in method: ChatGPT

Observations

Additional checks:

• The successful test was a new app process, not merely reopening the existing window.
• %USERPROFILE%\.codex\auth.json existed throughout the controlled exit/relaunch and was unchanged during the successful startup.
• The cached access token was not expired and a refresh token was present.
• No actual logout or credential-clear event was found in the preceding seven days of desktop logs.
• The user exits through the app's normal Exit action; this did not delete or modify the auth cache during a controlled test.
• Completing browser login succeeds and restores access to the existing tasks, but requiring repeated login is unexpected.

Expected behavior

A cached ChatGPT session should be reused or refreshed automatically. An authentication-status timeout should not be converted into a signed-out state.

Suspected behavior

The desktop startup path may have a ~10-second boundary around getAuthStatus. When the check reaches that boundary, the UI appears to treat the result as unauthenticated and begins a fresh login instead of retrying or surfacing a transient authentication-check error.

Reproduction

The issue is intermittent:

1. Sign in normally.
2. Exit the Windows desktop app using Exit.
3. Launch it again after the app has been closed for some time.
4. On affected launches, the app presents the signed-out screen and starts a new browser login.

No raw logs, account identifiers, tokens, or conversation contents are included in this report.

Begin at the Windows desktop startup path that issues the initial getAuthStatus request, and inspect how its ~10-second boundary handles timeout versus unauthenticated results. Compare the 10,030 ms and 5,237 ms cases using desktop logs and the unchanged %USERPROFILE%\.codex\auth.json; account/login/start should not begin when a cached token is valid. Done means transient status delays do not trigger a fresh login and existing sessions are reused or refreshed.