›_ Codex Issues
Codex Issues / #40632

[Windows][26.818.8289.0] Codex Desktop loses ChatGPT auth while CLI and server session remain active

Open 💬 7 comments Opened Aug 25, 2026 by tokufa
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.818.8289.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 10 x64

What issue are you seeing?

Codex Desktop repeatedly loses its ChatGPT authentication during normal use and returns to the "Sign in to ChatGPT" screen.

The underlying Codex authentication remains valid: while Desktop is already showing the login screen, codex.cmd login status still reports:

Logged in using ChatGPT

I performed additional diagnostics to determine whether this was caused by corrupted local credentials.

I completely closed Codex Desktop and backed up/removed:

C:\Users\<user>\.codex\auth.json
C:\Users\<user>\.codex\auth.json.old

I then launched Codex Desktop and performed a completely fresh ChatGPT login.

The fresh login succeeds:

account_login_completed ... success=true

and the account is initially recognized correctly.

However, after normal use / ChatGPT conversation activity, Desktop loses its access-token state and logs out again.

A reproduction showed:

chatgpt_conversation_refetch_started ... reason=explicit_update

followed almost immediately by:

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

Then:

authenticatedAccountPresent=false
authMethod=chatgpt
failureType=account_info_token_unavailable
result=failed

Authenticated requests subsequently fail with HTTP 401:

"Missing valid access token or actor biscuit"

Important control test:

After Desktop has returned to the login screen, without logging in again:

codex.cmd login status

still returns:

Logged in using ChatGPT

I also checked ~/.codex/auth.json before and after the Desktop logout.

The file did NOT change:

  • Size remained identical
  • LastWriteTime remained identical
  • SHA-256 remained identical

Therefore the underlying auth.json does not appear to be deleted, rewritten, or corrupted when Desktop loses authentication.

In an earlier reproduction, the Desktop logs also showed:

Failed to refresh token: 401 Unauthorized
Your refresh token has been invalidated. Please try signing in again.
code: refresh_token_invalidated

There are also messages around successful login such as:

RPC session was shut down by disposing the main stub

but Desktop successfully recognizes the account after this event, before authentication later collapses.

This appears to be a Desktop runtime/auth synchronization issue rather than loss of the underlying Codex/ChatGPT credentials.

Similar reports exist in #39170, #39685, #39491, and #39696, but I am reporting this separately because the issue is still reproducible on Codex Desktop 26.818.8289.0 and I performed additional auth.json/CLI control tests.

What steps can reproduce the bug?

  1. Launch Codex Desktop 26.818.8289.0 on Windows.
  2. Sign in using ChatGPT.
  3. Confirm that login succeeds and Codex is usable.
  4. Use Codex normally and interact with ChatGPT.
  5. After conversation activity/background synchronization, Codex Desktop eventually returns to the "Sign in to ChatGPT" screen.
  6. Do NOT sign in again.
  7. Open PowerShell and run:

codex.cmd login status

  1. Observe that CLI still reports:

Logged in using ChatGPT

  1. Check ~/.codex/auth.json and observe that it has not been modified by the Desktop logout.

The issue also reproduces after removing auth.json/auth.json.old and performing a completely fresh ChatGPT authentication.

What is the expected behavior?

Codex Desktop should remain authenticated as long as the underlying ChatGPT/Codex credentials are valid.

Desktop should not lose its access-token state while Codex CLI remains successfully authenticated using the same ChatGPT credentials.

Additional information

Troubleshooting / diagnostics already performed:

  • Located and inspected Codex Desktop logs.
  • Confirmed successful ChatGPT login.
  • Observed auth_token_missing with refreshToken=true.
  • Observed account_info_token_unavailable.
  • Observed HTTP 401 "Missing valid access token or actor biscuit".
  • Observed refresh_token_invalidated in an earlier reproduction.
  • Completely reset ~/.codex/auth.json and auth.json.old.
  • Performed a fresh ChatGPT login.
  • Issue still reproduced.
  • Verified auth.json does not change when Desktop logs out.
  • Verified Codex CLI remains logged in while Desktop is logged out.
  • Windows Credential Manager does not contain an obvious OpenAI/Codex credential entry.

I can provide sanitized Desktop logs containing the full reproduction if needed.

For security reasons, I will not attach auth.json because it contains authentication credentials.

Additional server-side verification:

While Codex Desktop is already showing the "Sign in to ChatGPT" screen:

  • codex.cmd login status still returns Logged in using ChatGPT.
  • ChatGPT Settings → Security and sign-in → Active sessions still shows the corresponding Codex session as active.
  • ~/.codex/auth.json remains unchanged.

Each successful Desktop re-login creates another Codex entry in Active sessions, while previous Codex sessions remain listed.

This further suggests that the server-side session and underlying credentials remain valid, while Codex Desktop loses its local/runtime authentication state.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 2 days ago

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

  • #40374
  • #39850
  • #39491
  • #39718
  • #40395

Powered by Codex Action

tokufa · 2 days ago

Additional confirmation after comparing this reproduction with #39850:

I searched the full Desktop logs for the initial failure trigger.

The same sequence is repeatedly reproducible on my Windows 26.818.8289.0 build:

  1. Desktop sends:

GET /backend-api/accounts/{account_id}/settings

with:

hadToken=true
tokenSource=cached
willRetry=true

  1. That request receives HTTP 401.
  1. Within roughly 0.6–1.5 seconds, the account settings request reports:

"Missing valid access token or actor biscuit"

  1. Subsequent requests immediately transition to:

hadToken=false
skipRetryReason=no_token_attached

This occurred multiple times, including after a completely fresh auth.json/login.

This strongly matches the process-local auth-cache failure described in #39850.

One difference: I did NOT find the specific response:

"Must use workspace account for this operation"

in my logs, so I cannot confirm that workspace/account scope is the cause of the initial 401 in my case.

The strongest common trigger appears to be:

cached Desktop token
-> /accounts/{account_id}/settings HTTP 401
-> Desktop access-token state collapses
-> subsequent requests have no token
-> Desktop UI returns to login

Persistent credentials remain valid:

  • auth.json unchanged
  • CLI remains logged in
  • ChatGPT account still shows the Codex session as active
tokufa · 2 days ago

Additional rollback/A-B test results:

I tested an older Windows Codex build to determine whether this is a regression in the current 26.818 line.

Affected build:

  • Windows MSIX package: 26.818.8289.0
  • Powered by Codex & OWL: 26.818.61809
  • Result: logout/auth collapse is reproducible.

Rolled-back build:

  • Windows MSIX package: 26.803.10989.0
  • Powered by Codex & OWL: 26.803.81509
  • Result: the app initially remained stable and did not reproduce the logout behavior during normal use.

The old package was installed from the official OpenAI CDN and its Authenticode signature validated successfully (Status: Valid, Microsoft Marketplace CA issuer).

Important updater observation:

After installing 26.803, Codex automatically staged 26.818 again in the background. Windows AppX logs showed that an update attempt was already pending while 26.803 was running, and later completed once the app could be replaced. The AppX log explicitly recorded:

OpenAI.Codex_26.803.10989.0 ... is updating to OpenAI.Codex_26.818.8289.0

Once 26.818 was restored, the logout problem returned.

I then disabled the Codex internal updater for the user with:

CODEX_SPARKLE_ENABLED=false

A fresh startup log on 26.803 confirms:

enableSparkle=false enableUpdater=false

This gives a temporary workaround for continued use of the older build while avoiding automatic re-upgrade.

Current working workaround:

  1. Install 26.803.10989.0 / Codex & OWL 26.803.81509.
  2. Set CODEX_SPARKLE_ENABLED=false for the user.
  3. Verify startup log shows enableUpdater=false.
  4. Do not manually trigger the update prompt.

This A/B behavior strongly suggests the authentication regression was introduced somewhere after the 26.803 line and is present in 26.818.

tokufa · 1 day ago

Update: the authentication/logout bug is still reproducible on the newer 26.820 release.

Affected newer build:

  • Windows MSIX package: 26.820.7780.0
  • Powered by Codex & OWL: 26.820.60940
  • Release date shown in About: Aug 25, 2026

Behavior is unchanged: Codex Desktop again loses ChatGPT authentication / returns to the sign-in screen during normal use.

This confirms the regression is not limited to 26.818 and remains present in 26.820.

Known comparison point:

  • 26.803.10989.0 / Codex & OWL 26.803.81509 was stable during rollback testing.
  • 26.818.8289.0 / Codex & OWL 26.818.61809 reproduced the bug.
  • 26.820.7780.0 / Codex & OWL 26.820.60940 also reproduces the bug.

So the affected range is at least 26.818 through 26.820, with 26.803 serving as a working baseline in my testing.

tokufa · 1 day ago

Additional updater diagnostics from Windows Store logs:

After rolling back again to 26.803.10989.0, I confirmed there are two separate update paths involved:

  1. Codex internal updater is disabled with CODEX_SPARKLE_ENABLED=false and startup logs show enableUpdater=false.
  2. Windows Store Install Service can still receive an external install/update request for Codex.

The previous forced return to 26.820.7780.0 was initiated through Store Install Service with:

ClientAppId = Acquisition;StoreInstaller-ChatGPT Installer (3)-StartProductInstallWithOptionsAsync

and the work properties included:

AutomaticallyDownloadAndInstallUpdateIfFound = 1

That request downloaded ~773,923,873 bytes and installed OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0.

After re-enabling the Microsoft Store policy HKLM\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\\AutoDownload = 2, the subsequent Codex update work item is still created, but now logs show:

AutomaticallyDownloadAndInstallUpdateIfFound = false
IsMandatory = false
IsUpdateNow = false

and the checkpoint is InstallType = Update with AutomaticallyDownloadAndInstallUpdateIfFound:false.

So the Store pipeline still probes/queues Codex, but it no longer appears permitted to automatically download/install the newer package. I am currently testing whether 26.803.10989.0 survives subsequent restarts with both barriers enabled:

  • CODEX_SPARKLE_ENABLED=false
  • Microsoft Store AutoDownload=2

This is a workaround for keeping the known-good 26.803 build installed while the auth regression remains present in 26.818 and 26.820.

toBerlinWay · 1 day ago

I’m hitting the same issue on Windows with a newer build: OpenAI.Codex_26.820.9563.0_x64.

Codex works normally after launch, but it suddenly returns to the “Sign in to ChatGPT” screen during use. Fully quitting and reopening the app is the only way to recover. This is temporary—the login screen comes back later.

Windows recorded this error on the same day:

  • Time: 2026-08-27 15:24:49 (UTC+8)
  • Event ID: 1001
  • Type: RADAR_PRE_LEAK_64
  • Process: ChatGPT.exe

I can’t confirm that the memory warning caused the login problem, but it may help with debugging.

I have not reinstalled, downgraded, switched to Beta, or deleted any .codex files because I need to preserve my existing work and conversation history.

Screenshot attached below.

<img width="960" height="509" alt="Image" src="https://github.com/user-attachments/assets/457c4e09-faa5-4c5b-86ca-acb3043a5335" />

tokufa · 22 hours ago

Further update diagnostics: the rollback still does not persist even with both previous barriers enabled.

At the time Windows replaced the rollback build, the system state was:

  • Installed Codex before replacement: 26.803.10989.0
  • CODEX_SPARKLE_ENABLED=false
  • HKLM\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\\AutoDownload = 2

Despite that, Windows updated Codex to:

  • 26.820.9563.0

The newest Store telemetry shows a different initiator than the earlier StoreInstaller-ChatGPT Installer flow. This time the update was initiated by Windows Update Orchestrator:

ClientAppId = Update;MoUpdateOrchestratorUserScan-MoUsoCoreWorker-SearchForAllUpdatesWithUpdateOptionsAsync

The operation was:

  • OperationType = Update
  • IsInteractive = false
  • IsMandatory = false
  • AutomaticallyDownloadAndInstallUpdateIfFound = 0

Nevertheless, Store telemetry records a successful download of 719116011 bytes and a successful install of OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0.

AppX deployment logs then show the old 26.803.10989.0 package being moved to WindowsApps\\Deleted and 26.820.9563.0 being registered successfully.

This means the following two controls are insufficient to keep the rollback build pinned on this machine:

  • CODEX_SPARKLE_ENABLED=false
  • Store AutoDownload=2

The updater that actually forced the latest package in this reproduction was the Windows Update Orchestrator (MoUsoCoreWorker), not the Codex internal updater.