Codex Desktop for Windows – authentication loop after opening local project

[spencertys]

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.61809

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

I am experiencing a persistent authentication loop in Codex Desktop on Windows.

Authentication succeeds in the browser and Codex returns to the application normally. However, as soon as I open a local project/folder, Codex loses authentication and asks me to sign in again. Re-authenticating repeats the same loop.

I have tested:

Passkey authentication and non-passkey authentication
Removing OPENAI_API_KEY temporarily from Windows environment variables
Updating Codex Desktop to the latest available version
Multiple local folders

The problem persists.

The important diagnostic point is that Codex CLI works correctly on the same Windows machine, with the same account and the exact same project folder:

E:\Projets\Test

Codex CLI v0.149.1 authenticates automatically and remains connected.

Desktop logs show:

desktop_fetch_auth_401 hadToken=true

followed immediately by:

hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

and then:

Missing valid access token or actor biscuit

with HTTP 401 responses on:

/backend-api/accounts/.../settings

and /backend-api/wham/...

Example sequence:

desktop_fetch_auth_401 hadToken=true ... status 401

then:

auth_status_result ... hasToken=false nullReason=auth_token_missing refreshToken=true

This strongly suggests that the Windows Desktop client is losing or failing to attach the ChatGPT authentication token after receiving the first 401, while the underlying Codex authentication remains valid because CLI continues working.

Environment:

Windows x64
Codex Desktop originally affected on 26.818.61809, still affected after update
Codex CLI v0.149.1 works normally
ChatGPT account authentication itself works normally

I can provide the full Codex Desktop log if needed.

What steps can reproduce the bug?

Steps to reproduce

Launch Codex Desktop on Windows.
Sign in with my ChatGPT/OpenAI account. Authentication succeeds in the browser and returns to Codex Desktop.
Open/select a local project folder, for example:
E:\Projets\Test
Codex Desktop immediately loses the authenticated state and asks me to sign in again.
Sign in again successfully.
Return to Codex Desktop and select/open the local folder again.
The same authentication prompt appears again, creating an infinite authentication loop.

Expected behavior

After successful authentication, Codex Desktop should remain signed in and open the local project normally.

Actual behavior

Codex Desktop repeatedly loses authentication after opening the local project and asks me to sign in again.

Important diagnostic information

The same account and the same project work correctly in Codex CLI on the same Windows machine:

OpenAI Codex v0.149.1
directory: E:\Projets\Test

The CLI authenticates automatically and stays connected, so the issue appears to be specific to Codex Desktop.

Desktop logs show the following sequence:

desktop_fetch_auth_401 hadToken=true

followed immediately by:

hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

and then:

Missing valid access token or actor biscuit

with HTTP 401 responses on account/settings endpoints.

Environment / recent account changes

I am not sure which of these changes is related to the issue, but shortly before the problem I made several account/authentication changes:

I purchased/created an OpenAI API key.
I added OPENAI_API_KEY as a Windows system environment variable.
I later removed it temporarily for testing, but the issue still occurred.
I changed my authentication method.
I added a passkey.
I changed my password.
I also tested signing in without the passkey, but the issue still occurred.

Because several authentication-related changes happened close together, I cannot determine which one, if any, triggered the issue.

Versions tested

Codex Desktop: originally reproduced on 26.818.61809
Still reproducible after updating Codex Desktop
Codex CLI: v0.149.1 works correctly

Session ID / usage / context

I do not currently have a session ID associated with the failed Desktop authentication loop.
The failure occurs immediately when opening the local project, before doing meaningful work in the session.
Token-limit usage and context-window usage do not appear applicable to the reproduction, because the authentication failure happens before a normal Codex interaction starts.

What is the expected behavior?

Expected behavior:

After successfully signing in to my OpenAI/ChatGPT account, Codex Desktop should remain authenticated and allow me to open and work in a local project folder without asking me to sign in again.

The authentication session should persist normally, as it currently does with Codex CLI on the same computer, using the same account and the same local project.

Additional information

Additional information:

The issue appears to be specific to Codex Desktop on Windows.

Codex CLI v0.149.1 works correctly on the same machine, with the same OpenAI/ChatGPT account and the exact same local project folder. The CLI authenticates automatically and remains signed in.

The Desktop logs show a consistent authentication failure sequence:

desktop_fetch_auth_401 hadToken=true

Immediately afterwards:

hasToken=false nullReason=auth_token_missing refreshToken=true tokenExpiryState=missing

Then subsequent requests fail with:

Missing valid access token or actor biscuit

This suggests that Codex Desktop initially has an authentication token, receives a 401 response, and then loses or stops attaching the token even though a refresh token is present.

I also tested the following without resolving the issue:

• Updated Codex Desktop to the latest available version.
• Signed in using a passkey.
• Signed in without using the passkey.
• Temporarily removed my OPENAI_API_KEY Windows environment variable.
• Restarted Codex and authenticated again.

Recent account changes that may or may not be related:

• I created/purchased an OpenAI API key.
• I added a passkey to my account.
• I changed my password.
• I changed authentication-related settings.

I cannot determine whether any of these changes triggered the problem.

The important distinction is that authentication still works correctly in Codex CLI, while Codex Desktop enters an infinite sign-in loop.

I can provide the full Codex Desktop logs if needed.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• [Windows][26.818.8289.0] Codex Desktop loses ChatGPT auth while CLI and server session remain active #40632
• Windows ChatGPT/Codex Desktop loses ChatGPT access token after successful login and redirects to login #39491
• Codex Desktop loses ChatGPT access token and returns to sign-in after enabling Advanced Account Security #39581
• Desktop app (macOS): logged out after every conversation — "Missing valid access token or actor biscuit", no token refresh attempted #40395
• Codex Desktop repeatedly logs me out after completing responses #40664

Powered by Codex Action

[chelebyy]

I’m seeing a related Windows Codex Desktop failure that began with an authentication/sign-in loop, but then progressed into intermittent conversation creation/continuation failures (Conversation creation failed – Timeout and no rollout found for thread id ...). I opened #40704 with the full environment, reproduction sequence, and troubleshooting details. This may share the same underlying auth/session-state problem, but in my case it also appears to corrupt or lose thread/rollout state after authentication recovers.

[spencertys]

Workaround found / additional diagnostic information

I was able to reproduce and partially work around this issue on Windows.

Observed behavior

Codex Desktop initially starts authenticated and is usable.
The authentication is lost when opening a Codex/ChatGPT conversation.

The Desktop logs show the following sequence:

desktop_fetch_auth_401 hadToken=true

followed immediately by:

hasToken=false
nullReason=auth_token_missing
refreshToken=true
tokenExpiryState=missing

Subsequent requests then fail with:

Missing valid access token or actor biscuit
Important finding

I monitored the local Codex files before and after reproducing the authentication failure.

The following file is modified when the failure occurs:

%USERPROFILE%.codex\auth.json

I made a backup of auth.json while Codex Desktop was successfully authenticated.

After reproducing the authentication loop:

Close Codex Desktop.
Restore the previously working auth.json.
Restart Codex Desktop.

Codex Desktop is immediately authenticated again without requiring a new login.

This was reproducible.

CLI comparison

Codex CLI continues to work correctly on the same machine, with the same account and project:

OpenAI Codex v0.149.1

The CLI remains authenticated while Desktop enters the authentication loop.

Temporary watchdog workaround

As an experiment, I created a PowerShell watchdog that monitors the Codex Desktop logs for:

nullReason=auth_token_missing

When detected, the workaround:

1. Restores a known-good auth.json
2. Terminates only the Codex Desktop process
3. Restarts Codex Desktop

This successfully restores the Desktop session automatically and has allowed Codex Desktop to remain usable despite the bug.

I initially tried restoring auth.json without restarting Desktop. This only worked temporarily. Restarting the Desktop process after restoring the file appears necessary, presumably because Desktop has already cached the unauthenticated state in memory.

Security warning

Do not share or publish auth.json or a backup of it. It contains authentication credentials.

The workaround should also be considered experimental. A permanently saved authentication file will eventually expire, and blindly restoring auth.json could interfere with legitimate token refreshes.

Possible area to investigate

Based on the observed sequence, Desktop appears to:

have a token
→ receive HTTP 401
→ transition to auth_token_missing
→ modify auth.json
→ remain unauthenticated in memory

while the CLI authentication remains functional.

This may help narrow the issue to the Desktop client's handling of the authentication state following the initial 401.

[spencertys]

[Windows Desktop] Successful login, then auth loop when switching conversations during an active task — clean reinstall fixes it

Summary

On Windows, Codex Desktop could authenticate successfully and work normally at first, but switching to another conversation while a task was still running reproducibly caused the app to return to the login screen.

The failure was specific to Codex Desktop. Codex CLI authentication continued to work.

The issue was ultimately resolved by a fully clean reinstall of Codex Desktop, including removal of its local state before reinstalling. Restoring only conversation/project data afterward did not reintroduce the authentication problem.

This report intentionally omits account identifiers, tokens, local project names, thread IDs, session IDs, and other potentially sensitive values.

Environment

• OS: Windows x64
• Affected Codex Desktop build: 26.820.7780.0
• App-server version observed in logs: 26.820.60940
• Authentication method: ChatGPT
• Codex CLI tested separately: 0.149.1
• Advanced Account Security: not enabled
• Passkey: issue was also tested without relying on the passkey
• CLI authentication remained functional while Desktop was affected

Reproduction

The most reliable reproduction sequence was:

1. Launch Codex Desktop.
2. Sign in successfully.
3. Open an existing conversation.
4. Start a simple task.
5. While that task is still running, switch to another conversation.
6. Codex Desktop immediately returns to the authentication/login screen.

Simply opening a conversation did not consistently trigger the issue. Running a task without switching conversations could also work normally.

The combination active task + conversation switch was the reliable trigger.

Important observation: auth.json did not change

A clean controlled reproduction was performed with all custom auth watchdog/workaround scripts disabled.

Immediately before the failure, the SHA-256, timestamp, and size of auth.json were recorded. Immediately after Codex returned to the login screen, all three were identical.

Therefore, in this reproduction, the logout did not require auth.json to be modified or corrupted on disk.

Authentication chronology

A fresh login succeeded normally:

account/login/start
login callback: has_code=true, has_state=true, state_valid=true
OAuth token exchange -> 200 OK
account/login/completed
Reloading auth
Reloaded auth, changed: false

Roughly two minutes later, during the task + conversation-switch reproduction:

thread/resume
thread/turns/list
thread/items/list
thread/goal/get
getAuthStatus
Reloading auth
Reloaded auth, changed: false
Refreshing token
POST https://auth.openai.com/oauth/token -> 401 Unauthorized
refresh_token_invalidated

The significant point is:

Reloaded auth, changed: false
Refreshing token

The auth manager reloaded the existing credentials, detected no change, and then attempted a refresh anyway.

Tokens were not near expiration

At the time of the failure, local JWT metadata indicated approximately:

• ID token: ~58 minutes remaining
• Access token: ~10 days remaining
• last_refresh: approximately 132 seconds old
• Refresh token: present

So the refresh attempt was not explained by normal access-token expiration.

Desktop task authentication could still be working

Other logs around affected sessions showed successful Codex response/WebSocket activity with authentication attached, including:

endpoint="/responses"
auth_header_attached=true
auth_mode="Chatgpt"
auth_retry_after_unauthorized="false"

WebSocket connections to the ChatGPT Codex backend could succeed shortly before getAuthStatus independently entered the refresh path.

This suggests the Desktop UI/auth-status path could decide to refresh while an otherwise usable ChatGPT access token was still available.

OAuth refresh failure

Repeated affected sessions showed:

POST https://auth.openai.com/oauth/token
401 Unauthorized

followed by an error equivalent to:

Your refresh token has been invalidated. Please try signing in again.
code=refresh_token_invalidated

After this, Desktop would lose its usable authenticated UI state and return to login.

Restarting only internal processes treated the symptom but did not prevent recurrence.

Workarounds tested before reinstall

Restoring a known-good auth.json

Restoring a previously working auth.json while Codex was fully closed could recover the session after a failure. However, continuously restoring the file did not prevent the clean reproduction.

During one failure, the current auth.json and known-good copy had identical SHA-256 hashes while the UI was already at the login screen.

This strongly suggests the relevant failure can occur in Desktop/auth-manager runtime state rather than through corruption of the file on disk.

Reloading the UI

Normal reload / hard reload did not recover the authenticated state.

Restarting NetworkService

Restarting only the NetworkService process did not recover the UI.

Restarting app-server

Restarting app-server could eventually recover the UI after an interruption/restart sequence, but it was disruptive and did not remove the underlying trigger.

CLI

Codex CLI continued to authenticate and operate normally. This was a useful control indicating that the account and basic authentication capability were still usable while Desktop was failing.

Clean reinstall procedure that fixed the issue

The successful fix was a genuinely clean reinstall.

Before removal, all Codex data was backed up locally.

The following Codex-specific locations were then removed after uninstalling the Windows package:

%USERPROFILE%\.codex
%LOCALAPPDATA%\Codex
%APPDATA%\Codex
%LOCALAPPDATA%\OpenAI\Codex
%LOCALAPPDATA%\Packages\OpenAI.Codex_<package-family>

The Windows package was also removed completely.

Codex Desktop was then reinstalled and authenticated from scratch.

Crucially:

• the previous auth.json was NOT restored;
• the previous auth backup was NOT restored;
• the previous global state was NOT restored wholesale.

After the fresh installation, the previously reliable reproduction sequence no longer caused logout:

sign in
-> open conversation
-> start task
-> switch conversation while task is active
-> remains authenticated and functional

Restoring conversation history after the clean reinstall

Conversation/session files had been backed up before the reinstall.

Restoring the session data recovered the conversations, although their project categorization initially disappeared.

Relevant restored conversation data included:

sessions/
archived_sessions/
session_index.jsonl
history.jsonl
thread_history_1.sqlite

An old state_5.sqlite was also tested, but Codex detected/rebuilt that state, so restoring it is not recommended as part of the fix.

Restoring project categorization

Inspection of the old and new .codex-global-state.json showed that the old state contained project metadata such as:

local-projects
project-order
thread-project-assignments
sidebar-project-thread-orders
thread-workspace-root-hints
thread-projectless-output-directories
projectless-thread-ids
thread-writable-roots

The old state contained 12 properties under local-projects, 16 thread-project-assignments, project ordering metadata, and sidebar project/thread ordering metadata.

The fresh state had local-projects empty while also containing migration state equivalent to:

app-server-projects-migration-by-host
  projectsMigrated = true
  threadAssignmentsMigrated = true

The relevant project/thread metadata was selectively transferred from the backup into the fresh global state, and the stale migration marker was removed so Codex could reevaluate the restored project data.

This restored the conversation-to-project categorization successfully.

The old global-state file was NOT restored wholesale.

Final result

After:

1. clean uninstall,
2. deletion of Codex-specific local state,
3. fresh installation,
4. fresh authentication,
5. selective restoration of conversation/project metadata without restoring old authentication state,

Codex Desktop now works normally.

The previously reliable reproduction:

active task -> switch conversation -> login screen

no longer occurs.

Possible interpretation

The evidence appears consistent with a Desktop-local authentication state problem rather than simple corruption of auth.json.

In particular:

• fresh OAuth login succeeded;
• auth.json remained unchanged during the controlled failure;
• access/id tokens were still valid;
• last_refresh was fresh;
• authenticated response/WebSocket traffic could still work;
• conversation navigation caused getAuthStatus;
• the auth manager reloaded credentials with changed: false;
• it then attempted an apparently premature refresh;
• /oauth/token rejected the refresh token as invalidated;
• Desktop subsequently returned to login;
• removing all local Desktop state and authenticating from scratch fixed the problem.

I cannot determine from the logs alone why getAuthStatus chose to refresh a recently issued credential set, or why that refresh token was already considered invalidated.

Security / privacy note

No tokens, cookies, authorization headers, account IDs, project names, local filesystem project names, or complete thread/session identifiers are included in this report.

I can provide additional sanitized log sequences if maintainers need a specific event window.