›_ Codex Issues
Codex Issues / #39696

Windows Stable: opening a thread immediately invalidates fresh OAuth refresh token with Advanced Account Security enabled; Beta works

Open 💬 12 comments Opened Aug 20, 2026 by gokdeniz-cakir
💡 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.21641

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

After enabling Advanced Account Security on my OpenAI account, the stable Windows Codex app can successfully sign in, but opening/resuming a Codex thread causes the app to lose the session and return me to the login screen.

The initial OAuth login itself succeeds. A fresh ~/.codex/auth.json is written and the newly issued access token is usable.

However, shortly after opening a thread, Stable calls getAuthStatus, attempts to refresh the OAuth token, and the refresh request is rejected by https://auth.openai.com/oauth/token with:

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

The app then treats the account as signed out.

This is reproducible after a fresh login.

Important control case: the Codex Beta app works correctly on the same PC, Windows installation, network, OpenAI account, Advanced Account Security configuration, and shared ~/.codex directory.

Installed Beta package:

OpenAI.CodexBeta 26.727.4816.0

Beta app-server logs identify its client version as:

26.727.40816

With Beta, I can open the same existing thread and send prompts normally. Requests to /backend-api/codex/responses have:

auth_header_attached=true
auth_mode="Chatgpt"
auth_error=""
auth_error_code=""

During the same operation, Beta does NOT perform the immediate getAuthStatus -> Refreshing token -> /oauth/token sequence seen in Stable, and there are no 401 Unauthorized, token_revoked, or refresh_token_invalidated errors.

This problem started immediately after I enabled Advanced Account Security.

What steps can reproduce the bug?

  1. Use a Windows account with Advanced Account Security enabled.
  1. Launch stable Codex for Windows:

About version: 26.818.21641
AppX package: OpenAI.Codex 26.818.2441.0

  1. Sign in with ChatGPT through the browser OAuth flow.
  1. Browser authentication succeeds and Codex reports the login as completed.

Example log sequence:

received login callback ... has_code=true ... state_valid=true
starting oauth token exchange
oauth token exchange succeeded status=200 OK
account/login/completed

  1. Open or resume an existing Codex thread.
  1. Stable subsequently performs:

getAuthStatus
Reloading auth
Refreshing token

  1. Codex sends:

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

and receives:

401 Unauthorized

{
"error": {
"message": "Your refresh token has been invalidated. Please try signing in again.",
"type": "invalid_request_error",
"code": "refresh_token_invalidated"
}
}

  1. Codex returns to the login screen.

In one reproduction, the fresh OAuth login completed at approximately 13:14:57 local time and the refresh token was rejected at approximately 13:15:04 — only a few seconds after the successful login.

The access token itself was still usable: the Codex /responses WebSocket successfully connected with an attached ChatGPT authorization header around the same time the refresh operation failed.

Failed refresh request ID from that reproduction:

bad1fcb3-a0c8-4634-a078-c8079f502dce

Stable vs Beta A/B test

I also tested Codex Beta with Stable completely closed.

Process inspection confirmed the only running Codex backend was:

C:\Program Files\WindowsApps\OpenAI.CodexBeta_26.727.4816.0_x64__2p2nqsd0c76g0\...

With Beta:

  • The same existing thread resumes successfully.
  • Prompts can be sent and responses are received.
  • ChatGPT authorization is attached successfully.
  • No immediate OAuth refresh occurs when opening/using the thread.
  • No refresh_token_invalidated error occurs.
  • The app remains logged in.

Therefore this appears to be a behavioral regression between the current Stable and Beta Windows clients rather than a general inability of the account to authenticate.

What is the expected behavior?

After a successful OAuth login, opening or resuming a Codex thread should keep the authenticated session active.

If the current access token is valid, the Stable app should be able to use it normally, as the Beta app does.

A newly issued refresh token should not be reported as refresh_token_invalidated only a few seconds after a successful OAuth exchange.

If a token refresh fails while the existing access token is still valid, the desktop app also should not immediately discard an otherwise working authenticated session and return the user to the login screen.

Additional information

Troubleshooting already performed

  • Manually logged out individual old Codex sessions from ChatGPT Security settings.
  • Reset the Windows app data.
  • Performed fresh OAuth logins.
  • Confirmed a new Codex active session is created server-side after login.
  • Confirmed ~/.codex/auth.json is freshly rewritten by the login.
  • Confirmed no CodexBeta or legacy ChatGPT Desktop process was running during Stable reproduction.
  • Confirmed only the expected Stable ChatGPT.exe processes and its child codex.exe were running.
  • Reproduced the problem after resetting the application.
  • Tested Beta as a control, where the same account works normally.

EDIT: IF YOU SUFFER A SIMILAR ISSUE, YOU MAY WANT TO TRY USING CHATGPT BETA 26.727.4816.0 AS A TEMPORARY FIX

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 8 days ago

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

  • #39199
  • #39685
  • #39170
  • #39581

Powered by Codex Action

TheWhiteWarlock · 7 days ago

Seeing the same issue, started yesterday after i moved over to passkeys. It has also been posed in: https://github.com/openai/codex/issues/39803

gokdeniz-cakir · 7 days ago
Seeing the same issue, started yesterday after i moved over to passkeys. It has also been posed in: #39803

I have been using the beta build without any issues since yesterday, if you havent, I would suggest trying that if you do not wish to disable your advanced account security setting.

TheWhiteWarlock · 7 days ago

Works a treat now, thank you

brianiup · 6 days ago

Same issue happening with me, removed my passkey, yubikey and disabled advanced security and still closing on every time i click a chat and asking me to sign in again currently on desktop app version 26.818.21641

TheWhiteWarlock · 6 days ago
Same issue happening with me, removed my passkey, yubikey and disabled advanced security and still closing on every time i click a chat and asking me to sign in again currently on desktop app version 26.818.21641

Try using the beta app until they get it fixed, that worked for me

ooouuu7997-hue · 6 days ago
> 我也遇到了同样的问题，我已经移除了密码密钥、Yubikey，并禁用了高级安全设置，但每次点击聊天窗口时，应用仍然会关闭并要求我重新登录。我目前使用的是桌面应用版本 26.818.21641。 在他们修复这个问题之前，可以先试试测试版应用，对我来说这样有效。

我已崩溃，一直不能登陆，win10商店最新版，

another-Sean · 6 days ago

I am experiencing the same issue on Windows 11 Pro after enabling Advanced Account Security.

Windows Hello authentication succeeds and the desktop app initially signs me in. However, opening any ordinary ChatGPT conversation immediately returns me to the sign-in screen.

I also reproduced the problem in Codex. I created a new Codex chat and sent “testing.” Codex thought for approximately seven seconds and began streaming a response, but after displaying only two or three words, the app returned to the sign-in screen.

ChatGPT web and the iOS app work normally.

Troubleshooting attempted: app update, Windows restart, Terminate, Repair, and revoking recent Codex sessions. The fault remains.

Current Windows app version: 26.818.3698.0

Feedback ID: no-active-thread-01a0255d-303e-7940-a396-cc9851b1bbfd

I have not Reset or uninstalled the app because I have local Work chats that may not be synchronised.

zebbern · 5 days ago

I'm experiencing the same issue.

Temporary workaround that currently works for me:

Use Codex CLI or ->

  1. Log into the Codex desktop app
  2. Don’t click anything or switch chats/projects inside the desktop app
  3. Open the ChatGPT mobile app → go to Remote
  4. Control and send messages from the phone

This at least lets me keep using Codex while the desktop app auth is broken.

hugepaper · 5 days ago

Reporting another independently observed Windows Stable reproduction of the same core failure sequence.

Environment

  • Codex Desktop client: 26.818.41509
  • Platform: Windows x64
  • Local timezone: KST (UTC+09:00)

Sanitized timeline from local app logs

On 2026-08-22, browser OAuth callbacks were accepted (state_valid=true, has_error=false) and token exchanges succeeded with HTTP 200 at approximately:

  • 20:28:53 KST
  • 20:30:50 KST
  • 20:36:57 KST
  • 20:38:07 KST

The desktop auth manager then attempted to refresh authentication and received 401 Unauthorized with code: refresh_token_invalidated five times at approximately:

  • 20:29:02 KST
  • 20:31:05 KST
  • 20:35:09 KST
  • 20:37:05 KST
  • 20:38:29 KST

The server message was:

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

Thus, fresh OAuth login/token exchange repeatedly succeeded, but the issued authentication state became unusable seconds later, producing a sign-in loop.

The same local log database contains an earlier run from client 26.818.31338 at 07:15 KST with a token-refresh attempt but no corresponding codex_login::auth::manager error. All five recorded auth-manager errors occurred later under 26.818.41509. This version correlation is diagnostic context, not proof that the client update is the root cause.

I have not established whether Advanced Account Security was enabled for this account, so this reproduction confirms the immediate refresh-token invalidation symptom but not that particular trigger.

No token values, account IDs, request IDs, thread IDs, conversation contents, email addresses, or raw log archives are included.

hugepaper · 5 days ago

Follow-up from the same affected Windows machine: after the refresh_token_invalidated sign-in loop, restarting Codex Desktop also makes the existing conversation history disappear from the UI.

Read-only inspection shows this is not deletion: all 63 user-created local threads remain unarchived and present in the state database, session index, local display catalog, and rollout files, with successful SQLite integrity checks.

One affected long paginated thread has an exact duplicate-ordinal boundary: ordinal 591 is written first as token_count and again as thread_settings_applied. The stored projection cursor expects ordinal 592, encounters 591, and then logs thread history projection expected ordinal 592, got 591 on every advancement attempt. The error persisted across 3 Desktop/app-server processes and accumulated at least 542 times while the canonical rollout continued growing intact.

Full sanitized measurements and the catalog/host mismatch observed after reauthentication are documented here:

https://github.com/openai/codex/issues/40178#issuecomment-5385380415

The projection failure began after the authentication loop on the same day, but this is temporal correlation only; I am not claiming that the authentication failure is proven to have caused the duplicate ordinal.

No credentials, identifiers, conversation content, filenames, absolute paths, or raw logs/databases are included.

gokdeniz-cakir · 5 days ago
Follow-up from the same affected Windows machine: after the refresh_token_invalidated sign-in loop, restarting Codex Desktop also makes the existing conversation history disappear from the UI. Read-only inspection shows this is not deletion: all 63 user-created local threads remain unarchived and present in the state database, session index, local display catalog, and rollout files, with successful SQLite integrity checks. One affected long paginated thread has an exact duplicate-ordinal boundary: ordinal 591 is written first as token_count and again as thread_settings_applied. The stored projection cursor expects ordinal 592, encounters 591, and then logs thread history projection expected ordinal 592, got 591 on every advancement attempt. The error persisted across 3 Desktop/app-server processes and accumulated at least 542 times while the canonical rollout continued growing intact. Full sanitized measurements and the catalog/host mismatch observed after reauthentication are documented here: #40178 (comment) The projection failure began after the authentication loop on the same day, but this is temporal correlation only; I am not claiming that the authentication failure is proven to have caused the duplicate ordinal. No credentials, identifiers, conversation content, filenames, absolute paths, or raw logs/databases are included.

As stated in the main thread, please try installing ChatGPT (Beta) from the windows store, "Version 26.727.40816 • Beta" seems to not suffer from this issue. This is the only known reliable work around so far.