[Windows][26.820.7780.0] Opening an existing conversation triggers 401 → auth_token_missing → repeated sign-in

What version of the Codex App are you using?

OpenAI.Codex 26.820.7780.0 (Windows x64 MSIX)

What platform is your computer?

Windows x64

What issue are you seeing?

Codex Desktop remains usable for newly created conversations, but opening an existing conversation consistently causes the app to lose its authenticated state and return to the ChatGPT sign-in screen.

The existing thread itself resumes successfully first. Immediately afterwards, Desktop receives an HTTP 401 from the account settings request while a token is still present, then transitions to auth_token_missing and starts issuing later requests without a token.

Sanitized log sequence from repeated reproductions:

thread/resume
maybe_resume_success

desktop_fetch_auth_401
hadToken=true
target="GET https://chatgpt.com/backend-api/accounts/:param/settings"
willRetry=true

app_server_connection.auth_status_result
authMethod=chatgpt
hasToken=false
nullReason=auth_token_missing
refreshToken=true
tokenExpiryState=missing

chatgpt-account-lookup
authenticatedAccountPresent=false
failureType=account_info_token_unavailable

Missing valid access token or actor biscuit
status=401

# subsequent requests
desktop_fetch_auth_401
hadToken=false
skipRetryReason=no_token_attached

The important transition is:

thread/resume succeeds
→ /accounts/:param/settings returns 401 with hadToken=true
→ hasToken=false / auth_token_missing
→ subsequent requests have hadToken=false
→ Desktop redirects to sign-in

This reproduced repeatedly throughout the same day across multiple existing conversations. Newly created conversations continue to work until an existing conversation is opened.

Signing in again succeeds, but opening an existing conversation reproduces the same logout loop.

What steps can reproduce the bug?

1. Launch Codex Desktop on Windows and sign in with ChatGPT.
2. Create a new conversation and use it normally; it works.
3. Select an existing conversation from the sidebar.
4. The thread resumes successfully (thread/resume, maybe_resume_success).
5. Within roughly a second, Desktop logs desktop_fetch_auth_401 for /backend-api/accounts/:param/settings with hadToken=true.
6. Auth state changes to hasToken=false, nullReason=auth_token_missing.
7. The app returns to the ChatGPT sign-in screen.
8. Sign in again and open an existing conversation; the same sequence repeats.

Reproduction rate: consistent on the affected installation.

What is the expected behavior?

Opening an existing conversation should preserve the authenticated ChatGPT session and load the thread normally.

A 401 from an account-settings request should not cause Desktop to discard an otherwise present authentication state and subsequently send requests with no token.

Additional information

This appears related to the existing Desktop authentication regression reported in issues such as #39189, #39803, #39925, #40374, and #40541.

The reason for filing another report is that the same failure is still reproducible on the newer Windows package 26.820.7780.0, and in this case the trigger is especially narrow: new conversations work, while opening an existing conversation reliably causes the auth-state collapse.

The issue was reproduced many times in the same day's logs, with the same sequence each time. The thread resume completes before authentication is lost, which suggests the existing conversation data itself is not failing to load.

A separate Windows localhost/OAuth port issue (os error 10013) was also encountered during troubleshooting, but that was independently diagnosed and resolved; it is not required to reproduce this repeated-login bug and is intentionally excluded from this report.

Full logs are available locally; account IDs, thread IDs, tokens, cookies, and local usernames have been omitted here for privacy/security.