[macOS][Desktop 26.814] getAuthStatus MCP timeout forces false logout during concurrent tasks

What version of the Codex App are you using?

ChatGPT/Codex Desktop 26.814.41407 (bundle build 6720)

What subscription do you have?

Personal ChatGPT account, authenticated using a Google Workspace-domain Google identity. This is not a ChatGPT Business/Enterprise workspace.

What platform is your computer?

macOS 26.6.2 (25G83), Apple Silicon / arm64

What issue are you seeing?

While several Codex tasks are active, the desktop app unexpectedly switches to the ChatGPT login screen even though the ChatGPT credential remains valid. Restarting the app immediately restores the same authenticated session.

The distinctive failure is that the desktop's request to the local app-server for getAuthStatus times out. The timeout is then treated as if no authenticated account exists:

Unable to extract account id and plan from auth token
errorMessage="Timed out waiting for MCP response to getAuthStatus"

Failed to retrieve authentication token
status=432

chatgpt-account-lookup
authenticatedAccountPresent=false
failureType=account_info_token_unavailable
result=failed

The UI then switches to the login screen. Shortly afterward, IPC reports write EPIPE and the app-server is stopped. After relaunch, account lookup immediately returns authenticatedAccountPresent=true without the underlying ChatGPT session needing repair.

The bundled/local CLI continues to report:

Logged in using ChatGPT

This suggests that an app-server responsiveness failure is being misclassified as loss of authentication.

What steps can reproduce the bug?

The trigger is not fully deterministic, but it reproduced repeatedly under concurrent task load:

1. Sign into the macOS desktop app using ChatGPT.
2. Keep several long-running Codex tasks, subagent operations, or tool calls active.
3. Continue working in another task.
4. The desktop may unexpectedly switch to the login screen while active work is still running.
5. Quit and relaunch the app.
6. Observe that the same authenticated account is immediately restored.

Two consecutive confirmed incidents occurred at:

• 2026-08-27 02:33:57 UTC
• 2026-08-27 02:35:52 UTC

What is the expected behavior?

A temporary timeout while requesting getAuthStatus from the local app-server should not clear the authenticated account or force the desktop UI to the login screen.

The desktop should retry or reconnect, preserve the known authenticated state, and retain its association with active task streams.

Additional information

The app-server process was alive and processing other task/tool events around both timeouts. After restart, the renderer logged completion events for an unknown conversation, consistent with tasks continuing while the desktop lost its UI association.

The logs also contain recurring requests to /accounts/{account_id}/settings that return:

401 Must use workspace account for this operation

Those responses also occur during otherwise healthy operation and may be unrelated to the getAuthStatus timeout.

No tokens, account IDs, task IDs, or local filesystem paths are included here.

Closest related report: #39162. That issue concerns the same desktop build and a sign-in redirect after an account-settings 401, whereas this report's immediate trigger is an MCP timeout waiting for getAuthStatus during concurrent task activity.