Desktop: hard quit required after account switching to recover hidden threads, turn/start, and slow thread resume

What version of the Codex App are you using?

Codex Desktop 26.608.12217 / build 3722

Bundled CLI:

codex-cli 0.138.0-alpha.7

Global CLI:

codex-cli 0.138.0

What subscription do you have?

ChatGPT auth; exact plan/account details intentionally omitted.

What platform is your computer?

macOS 26.3 (25D125)
Darwin 25.3.0 arm64
Apple Silicon

Summary

Codex Desktop can become unusable after signing out / signing into another ChatGPT account during heavy multi-thread use. The only reliable recovery I have found is to hard quit Codex Desktop and reopen it. After that, previously hidden/blank/slow threads often become visible/loadable again, and message submission errors stop temporarily.

This appears to be a combined Desktop live-state problem rather than local data loss:

• local thread DB remains healthy
• session index remains complete
• old threads still exist locally
• hard quit/reopen clears enough live app/sidebar/app-server state for the UI to work again for a while
• normal sign-out/sign-in or state repair while Desktop is live is not enough

User-visible symptoms

During normal heavy use, especially after account switching or reaching usage limits:

• Some old threads do not load, or load only after an extremely long wait.
• Some projects/threads disappear from the visible Desktop UI even though local state still contains them.
• Sending a message can fail with an inline Error submitting message / message creation failure.
• Creating/sending may start working again after a full Desktop quit/reopen.
• The CLI may recover after relaunch/login refresh, while Desktop remains wedged until the GUI process is restarted.

This is severe because the app becomes unreliable for the base workflow: open an existing thread, read it, and send a message.

Local evidence: data is not lost

Current local storage is healthy:

sqlite integrity: ok
state_5.sqlite thread count: 5131
unarchived thread count: 2690
session_index.jsonl rows: 5131

The current Desktop workspace scope was repaired to the parent workspace root:

{
  "active-workspace-roots": ["<parent-workspace-root>"],
  "saved_workspace_roots_count": 27,
  "project_order_count": 30
}

Before repair, after a restart / account-switching session, active-workspace-roots had drifted to a single child workspace. That made other workspace histories appear missing/unloaded even though the DB and session index were healthy. Reopening Desktop against the parent workspace root restored it without killing active worker processes:

/Applications/Codex.app/Contents/Resources/codex app <parent-workspace-root>

Local evidence: thread loading can take minutes

From one day of Codex Desktop logs:

thread/resume successful responses: 2464
over 30s: 411
over 60s: 103
over 120s: 16
max thread/resume duration: 260777 ms
max thread/read duration: 158955 ms
mcp_request_timeout events: 10

This matches the user experience: a thread may look stuck for one or more minutes, and it is impossible to tell whether it will eventually load or has failed.

Local evidence: message send failure via turn/start timeout

Observed repeated Desktop renderer timeouts while trying to start a turn:

mcp_request_timeout method=turn/start pendingCount=86 timeoutMs=30000
mcp_request_timeout method=turn/start pendingCount=87 timeoutMs=30000
mcp_request_timeout method=turn/start pendingCount=86 timeoutMs=30000

Retrying later can succeed, and hard quit/reopen makes the problem less likely temporarily.

Local evidence: helper/FD pressure class

Current process counts after some recovery work:

codex app-server --listen stdio:// helpers: 40
node_repl helpers: 40
launchctl maxfiles soft limit: 256

Earlier in the same investigation, counts were higher, and the main GUI/app-server path showed hundreds of FDs / many pipes. This looks related to cumulative sidecar/helper lifecycle pressure.

Mitigations attempted

These helped temporarily or partially, but did not solve the root problem:

1. Verified SQLite integrity and session index completeness. Result: storage was healthy; this is not local data loss.
2. Repaired local visibility/session metadata. Result: hidden-thread metadata could be reconciled, but Desktop live state could still drift again.
3. Repaired workspace scope back to the parent workspace root. Result: missing workspace histories became discoverable again.
4. Tried repair while Desktop was still running. Result: the running app could overwrite repaired workspace scope back to a child workspace.
5. Reopened the parent workspace root through the bundled launcher without killing active workers. Result: active workspace scope stuck correctly afterward.
6. Full hard quit/reopen. Result: clears enough live sidecar/sidebar/auth/thread-manager state that loading and sending work again temporarily.

Likely fix directions

This likely needs product/runtime fixes in several places, not only a docs workaround:

1. On sign-out/sign-in or account switch, Desktop should fully invalidate/rebuild app-server/auth/thread-manager state. If that cannot be done safely, the app should explicitly require/recommend a Desktop restart rather than silently continuing with stale live state.
2. active-workspace-roots should not collapse to a single child workspace after restart/account switch when the user is operating from a parent workspace scope. The app should preserve or validate the intended parent root and avoid overwriting repaired state with stale renderer state.
3. Project/sidebar hydration should not depend only on a recent global subset. When a project/workspace is opened, Desktop should query/paginate that project scope from durable local state rather than rendering No chats from an incomplete loaded set.
4. thread/read and thread/resume need visible progress and a real retry/error state. If a load can take 60-260s, the UI should say it is still loading and should not look indistinguishable from a permanent failure.
5. turn/start should handle app-server backlog explicitly: clear stale pending requests, surface a retryable reason, or reset the affected manager instead of only showing Error submitting message after a 30s timeout.
6. Stdio helper/app-server/node_repl lifecycle needs cleanup or reuse. Long Desktop sessions should not accumulate enough helpers/fds/pipes that normal thread loading and turn start become unreliable.
7. Add a Desktop health/recovery action: reload auth, rebuild sidebar/index state, reopen parent workspace root, reap stale helpers, and restart only the local app-server sidecar without killing active completed threads or requiring a full app quit.

Why this feels tied to account switching

The worst recurrence pattern is:

1. Use Codex Desktop heavily across many local threads/workspaces.
2. Hit usage/account limit.
3. Sign out and sign into another account.
4. Some old threads no longer load or disappear from the project UI.
5. Sending messages fails intermittently.
6. Codex CLI can often be fixed by exiting/relaunching/login refresh.
7. Codex Desktop remains bad until the GUI app is hard quit and reopened.

I am not claiming a proven billing attribution bug here. The concrete claim is that Desktop live state after account switching does not get fully refreshed, and a hard quit clears state that sign-out/sign-in does not.

Expected behavior

• Account switching should invalidate/reload all relevant Desktop app-server/auth/sidebar/thread manager state without requiring a hard quit.
• Existing local threads should remain discoverable and loadable if state_5.sqlite and session_index.jsonl are healthy.
• If thread/resume or thread/read takes minutes, the UI should expose progress or a meaningful timeout/retry path.
• turn/start should not fail just because the Desktop sidecar has accumulated pending requests/helpers.
• Desktop should clean up or reuse app-server/node_repl helpers so long sessions do not degrade into timeout behavior.

Related issues

This report seems to span several existing issue families:

• Error submitting message / turn/start timeout: #27395
• thread extremely slow and recovers after restart: #27559
• hidden local threads / project sidebar/search hydration: #25463, #22796, #25084, #23979, #27251, #27314, #27159, #21128
• helper/fd/process lifecycle pressure: #26984, #25744
• account/auth switching live-state problems: #21314, #25443, #27497

Current workaround

The only reliable workaround is disruptive:

1. Let active turns finish if possible.
2. Hard quit Codex Desktop.
3. Reopen Desktop against the parent workspace root.
4. Avoid hot account switching inside the same long-lived Desktop process.
5. Pin critical threads so they are less likely to disappear from the sidebar.

This is not an acceptable steady-state workflow for heavy multi-thread Desktop use.