›_ Codex Issues
Codex Issues / #31459

Codex Desktop keeps using revoked ChatGPT OAuth token after logout/login

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

Codex Desktop repeatedly uses revoked ChatGPT OAuth token after logout/login and profile reset

Summary

Codex Desktop can successfully connect to SSH remotes, but Desktop requests to chatgpt.com/backend-api/wham/* continue returning 401 token_expired / 401 token_revoked after full logout/login, local profile reset, CLI auth reset, bundled CLI auth reset, and Desktop restart.

This appears to be a Desktop/web account auth refresh issue rather than an SSH/remote-machine issue.

Environment

  • macOS
  • Codex Desktop app
  • Codex CLI version: 0.142.5
  • Bundled Desktop CLI: /Applications/Codex.app/Contents/Resources/codex
  • SSH remotes

Observed behavior

After a clean Desktop restart, remote SSH connections succeed:

Immediately afterward, Desktop account/app metadata requests fail:

failed to list apps: Request failed with status 401 Unauthorized:
{
  "error": {
    "message": "Provided authentication token is expired. Please try signing in again.",
    "code": "token_expired"
  },
  "status": 401
}

Additional requests also fail:

GET https://chatgpt.com/backend-api/wham/accounts/check
401 token_revoked
"Encountered invalidated oauth token for user, failing request"

Thread-title generation also reports:

Your access token could not be refreshed because your refresh token was revoked.
Please log out and sign in again.

Things already tried

  • Full Codex Desktop logout/login
  • Full Codex Desktop restart
  • Reset local Desktop profile/cache:
  • ~/Library/Application Support/Codex
  • ~/Library/Caches/Codex
  • ~/Library/Caches/com.openai.codex
  • Reset standalone CLI auth:
  • codex logout
  • codex login --device-auth
  • Reset bundled Desktop CLI auth:
  • /Applications/Codex.app/Contents/Resources/codex logout
  • /Applications/Codex.app/Contents/Resources/codex login --device-auth
  • Verified both local CLIs report:
  • Logged in using ChatGPT
  • Verified SSH remotes connect and app-server handshakes succeed.

Expected behavior

After logout/login and fresh device auth, Codex Desktop should stop using the invalidated token and should successfully refresh/reload account/app metadata.

Actual behavior

Codex Desktop continues to make authenticated chatgpt.com/backend-api/wham/* requests with a token the backend considers revoked/expired, even though local CLI auth and bundled CLI auth both report successful login.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31162
  • #30775

Powered by Codex Action

tg12 · 1 month ago

Came here from Google, I am getting the same error!

AryanRG · 8 days ago

I reproduced what appears to be the same failure with:

  • Codex App 26.814.41407
  • Bundled CLI 0.148.0-alpha.15
  • Darwin 27.0.0 arm64 arm
  • ChatGPT account authentication

In this case, the evidence strongly suggests a stale in-memory credential after a shared credential-store rotation:

  1. The Desktop main app-server remained running.
  2. A second Codex app-server / CLI authentication flow was also running, and both clients used the file-backed ~/.codex/auth.json store.
  3. After authentication was refreshed by the second client, Desktop continued with its older in-memory credential.
  4. At a thread switch or the end of a turn, the next authenticated account lookup returned refresh_token_invalidated; Desktop changed from an authenticated account being present to no authenticated account and logged out.

Sanitized log sequence from one occurrence:

T+0.000  final-response reasoning summary completes
T+0.866  app-server auth state reports no token
T+0.915  account lookup reports authenticatedAccountPresent=false
           reason=account_info_token_unavailable
T+1.010  backend reports refresh_token_invalidated
T+2.649  turn-complete notification is emitted

Recovery/workaround that has remained stable:

  1. Set cli_auth_credentials_store = "keyring" in ~/.codex/config.toml.
  2. Stop the extra helper app-server, leaving only the Desktop-owned process.
  3. Perform one fresh login with the bundled CLI.
  4. Confirm the file-backed ~/.codex/auth.json is gone.

After that, repeated thread switches and a completed probe turn did not produce refresh_token_invalidated, and the account remained signed in. Auth, network, and WebSocket diagnostics also passed.

Because changing the credential store and removing the second process were done together, this does not prove which change is individually sufficient. It does narrow the likely failure mode to multi-client credential rotation plus stale in-memory auth.

Expected behavior:

  • Token refresh/rotation should be coordinated across Codex clients that share authentication state.
  • A long-running Desktop app-server should reload the current credential after another Codex client logs in or refreshes it.
  • A stale process should not invalidate the newly issued shared session.
  • If reauthentication is unavoidable, Desktop should preserve the active thread and present an in-app recovery prompt instead of silently clearing the account state.

No account IDs, tokens, callback URLs, or unredacted logs are included here.

AryanRG · 8 days ago

Correction to my earlier diagnostic comment above: the multi-client credential-rotation / Keychain workaround was not durable, and that causal attribution should be treated as retracted.

A later controlled reproduction on Desktop 26.818.21641 (build 6849) showed the exact trigger:

  1. An existing task resumed successfully.
  2. The renderer then called /backend-api/accounts/:account/settings for a personal paid account.
  3. That request returned 401.
  4. Desktop transitioned to hasToken=false, nullReason=auth_token_missing, while still reporting refreshToken=true.
  5. Cmd+Q and reopen restored the account without a new OAuth login.

The failure recurred despite the earlier credential-store/process changes and despite disabling Remote Control, Computer History/Chronicle, Advanced Account Security changes, and the ChatGPT Chrome extension. A same-machine rollback to signed build 26.810.52044 removed the settings request and survived repeated Codex-task and ChatGPT-chat switches with no auth drop.

The canonical match is now #39162, where I posted the newer-build failure timeline and rollback A/B evidence: https://github.com/openai/codex/issues/39162#issuecomment-5353505977

This may still share auth-state symptoms with this issue, but the evidence no longer supports my earlier claim that a competing client was the root cause in this incident.