Codex Desktop repeatedly signs out on macOS while CLI and web remain authenticated

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

• #39718
• #39695
• #40632
• #39491
• #40664

Powered by Codex Action

Adding a more specific occurrence from #41032 that appears to match this issue.

On macOS 26.6.2 with Desktop 26.814.41407 (build 6720), this reproduced repeatedly while several long-running tasks/tool operations were active. The credential remained valid (codex login status still reported Logged in using ChatGPT), and relaunch immediately restored the same account.

The immediate transition in two incidents was not an expired credential: the desktop timed out waiting for the live local app-server's getAuthStatus response, then treated that transport timeout as an absent account:

<details>
<summary>Sanitized transition</summary>

Timed out waiting for MCP response to getAuthStatus
Failed to retrieve authentication token (status=432)
authenticatedAccountPresent=false
failureType=account_info_token_unavailable
write EPIPE

Incidents: 2026-08-27 02:33:57Z and 02:35:52Z.

</details>

The app-server was still processing task/tool events around the timeout, and after restart the renderer received completions for an unknown conversation. This suggests the desktop may be misclassifying a temporarily unresponsive/broken app-server RPC path as logout, while background work survives. A useful fix invariant may be: retry/reconnect getAuthStatus without clearing the last known authenticated account, then reconcile active task ownership.

Additional Windows evidence: auth-status timeouts and an unresponsive sign-in screen

Sharing an additional Windows occurrence for triage alongside the getAuthStatus timeout evidence already collected in this issue from #41032. The diagnostic signature overlaps, but a shared root cause has not been confirmed.

Environment: Windows 25H2, OS build 26200.9168; desktop app package version 26.820.9563.0. Incident date: 27 August 2026.

While already signed in and using the desktop app, it suddenly switches to the "Sign in to ChatGPT" screen. Clicking "Continue login" has no visible effect and does not open a browser. Ending all ChatGPT.exe processes and reopening the app temporarily restores the existing signed-in state. The problem recurs. Opening an ordinary HTTPS link through Windows launches Chrome normally.

The user also reports that the app has become progressively slower and less stable, including hangs/crashes, after recent upgrades. This is a suspected regression, not a proven version-specific cause. The exact last known good version has not been identified.

Verified diagnostic sequence:

• 19:44:55 Beijing time (UTC+08:00; 11:44:55Z): local app-server handshake succeeds. At 19:45:01 / 11:45:01Z, account lookup succeeds with authenticatedAccountPresent=true.
• 19:46:51 / 11:46:51Z: getAuthStatus times out, followed by authenticatedAccountPresent=false and failureType=account_info_token_unavailable.
• After another startup, the same failure recurs at 19:56:31 / 11:56:31Z.
• Following process termination and restart, account lookup succeeds at 19:59:02 / 11:59:02Z.
• A third matching failure occurs at 21:03:14 / 13:03:14Z. After another restart, account lookup succeeds at 21:05:50 / 13:05:50Z.

Representative diagnostic text:

"Timed out waiting for MCP response to getAuthStatus"
"Timed out waiting for MCP response to account/read"
"authenticatedAccountPresent=false"
"failureType=account_info_token_unavailable"

Other local RPCs still succeed during these authentication failures. For example, configRequirements/read completes in 4 ms at 19:47:04 / 11:47:04Z, and config/read completes in 11 ms at 19:56:31 / 11:56:31Z. This does not look like a complete loss of the local backend connection.

The account-settings endpoint also produces repeated 401 responses with hadToken=true, tokenSource=cached and willRetry=true. Such a 401 also occurs after a successful restart, so it alone does not establish the cause. The evidence does not confirm a deadlock, revoked credentials, a token-refresh failure, or a backend process exit. The sign-in button's internal failure path remains unverified.

Please investigate authentication RPC hangs/timeouts, why Continue login becomes unresponsive, and graceful recovery without requiring users to terminate processes. A temporary authentication-read failure should provide a useful error/retry path instead of leaving the app stuck on an unusable sign-in screen.

Observed reproduction sequence

1. Start the desktop app with an existing signed-in account and use it normally.
2. During use, the UI unexpectedly changes to the sign-in screen. The precise trigger is not yet deterministic.
3. Click Continue login: no visible response and no browser opens.
4. End all ChatGPT.exe processes and reopen the app. The existing signed-in UI is restored temporarily.
5. Continue using the app; the same failure can recur, as shown by the three incidents above.

This repeatedly interrupts normal work and significantly degrades the user experience.

Privacy

Only the sanitized technical summary is included. No raw logs, chat transcripts, account identifiers, billing information, local filesystem paths, device identifiers, or credentials are attached.

This is currently making the MacOS app unusable for me. I get kicked out in the middle of tasks running. Sometimes multiple occurences within the span of 5 minutes.

Adding an independent macOS occurrence with a release comparison and a more specific upstream trigger.

Environment

• macOS 26.3.2, Apple Silicon
• Desktop 26.820.60940 (build 7119)
• Bundled app-server / CLI: 0.150.0-alpha.8
• ChatGPT account authentication

Regression window

Sparkle installed build 7119 on 2026-08-26 at 13:03 China Standard Time, replacing build 6662 / bundled 0.148.0-alpha.9. The first matching 401 appeared 38 minutes later. In the available Aug 20–25 logs (before this update), there were zero cached-token 401s, token-retrieval failures, getAuthStatus timeouts, or failed account lookups.

Observed failure chain on build 7119

1. The account-settings endpoint returns 401 while the desktop wrapper records hadToken=true, tokenSource=cached, and willRetry=true.
2. There are 108 such 401s: 102 explicitly say Must use workspace account for this operation; six end as Failed to refresh authentication token.
3. Authentication then degrades across unrelated tasks, usage, settings, accounts, and onboarding requests: 54 local responses fail with status 432 and Failed to retrieve authentication token.
4. getAuthStatus times out 13 times. Account lookup then reports account_info_token_unavailable five times and account_ordering_empty once.
5. Relaunch restores the same authenticated account within seconds, without re-login, but the failure recurs.

Inspecting the shipped Electron bundle shows a 30-second getAuthStatus timeout. The fetchAuthToken error path invalidates the in-memory token cache on an exception; the local fetch handler converts token acquisition failure to status 432; the renderer then treats the unavailable token as no authenticated account and enters onboarding. This appears to turn a workspace/account-selection business 401 or a transient auth-RPC timeout into a false logout.

Negative and trigger evidence

• No explicit logout/revocation, Keychain or secure-storage failure, renderer crash, fatal signal, watchdog termination, or process-gone event was found.
• One incident occurred 36 seconds after system wake and was preceded by a Trust evaluate failure: [leaf TemporalValidity]. Wake/network restoration may trigger the path, but it does not explain every incident.
• Persistent credentials remain valid; restarting the desktop process is sufficient to recover.

Build 7226 comparison

The staged 26.820.71523 / build 7226 cannot currently be considered a fix. A read-only reconstruction of its signed delta still bundles 0.150.0-alpha.8; the CLI bytes before the Mach-O signature are identical, and the Electron getAuthStatus, token-cache, force-refresh, and principal-parsing paths are semantically unchanged.

Suggested fix invariants: do not treat workspace account required as token expiry; do not clear the last known authenticated account on a transport timeout; retry/reconnect the auth RPC before routing to onboarding.

_Privacy: this comment contains only a sanitized technical summary. No raw logs, account identifiers, tokens, cookies, session transcripts, device identifiers, or local paths are attached._

Another affected macOS user is seeing the same recurring sign-out behavior in ChatGPT/Codex Desktop.

Environment observed in the sanitized desktop log:

• macOS / Darwin, Apple Silicon
• Packaged production desktop app
• Bundled app-server: 0.149.0-alpha.4.1
• Authentication method: ChatGPT

At startup, the local app-server initializes successfully and changes from connecting to connected. Account lookup also succeeds initially:

authenticatedAccountPresent=true
authMethod=chatgpt
failureType=undefined
hasEverErrored=false
result=succeeded

Despite the healthy initial authentication state, the desktop app repeatedly returns the user to a disconnected/signed-out state during use.

A separate stale Git lock was also observed under .codex/vendor_imports/skills/.git/index.lock, but process inspection confirmed there was no active Git command. This appears related only to recommended-skills refresh and does not explain the recurring authentication loss.

The currently captured filtered log covers startup and does not yet include the exact failure window. No raw logs, account identifiers, tokens, email addresses, conversation identifiers, or private filesystem paths are included here.