[macOS Desktop] Restoring one large VS Code-origin thread floods thread/items/list and resets IPC

What version of the Codex App are you using (From “About Codex” dialog)?

• Codex Desktop: 26.820.60940 (build 7119)
• Bundled codex-cli/app-server: 0.150.0-alpha.8

What subscription do you have?

ChatGPT paid plan. The exact tier does not appear relevant because the failure occurs in the local Desktop renderer and IPC path before model execution.

What platform is your computer?

• macOS 26.5.2 (build 25F84), Apple Silicon
• uname -mprs: Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Desktop repeatedly becomes unresponsive while restoring a large, recent, pinned thread that originated in the VS Code extension. The VS Code app and its app-server were fully closed during the reproduction, so this is not caused by two concurrently running app-servers.

The affected thread is unarchived, uses paginated history, and has approximately:

• 15,386 persisted display items
• 1.84 million reported tokens
• three persisted Desktop route entries

On one clean Desktop launch, the client issued 122 thread/items/list requests for only two threads within about 2.5 seconds. Of those, 114 targeted the affected thread. The app-server responses were fast:

• mean response time: 9.37 ms
• maximum response time: 60 ms

Immediately afterward, the Desktop main-process log recorded four window missing events, three ipc-connection-reset broadcasts, and one Stopping app-server transport event. The UI stopped progressing even though the app-server had answered the history requests quickly.

This sequence reproduced across five Desktop launches:

By contrast, a later launch that did not restore/open the large thread made only eight thread/items/list calls and recorded zero IPC resets, zero missing-window events, and zero transport stops. It remained responsive.

The evidence points to an unbounded or duplicated renderer hydration/restoration path, possibly amplified by stale or repeated window/tab routes. It does not look like slow rollout parsing or a slow app-server query.

No data loss has been observed, but the Desktop UI can become unusable and require relaunching.

What steps can reproduce the bug?

1. Create or retain a very large local Codex thread in the VS Code extension. The reproduced thread had about 15.4k display items and 1.84M reported tokens.
2. Keep that thread unarchived and pinned so it remains represented in shared/persisted Codex state.
3. Fully quit VS Code and verify that its Codex app-server is no longer running.
4. Launch Codex Desktop on macOS.
5. Let Desktop restore the previous UI state, or open the pinned VS Code-origin thread.
6. Observe a burst of more than 100 thread/items/list requests for that single thread.
7. Observe that the Desktop window becomes unresponsive, followed by missing-window messages, IPC resets, and app-server transport shutdown in the main-process log.
8. Relaunch Desktop without restoring/opening that large thread. The request burst and IPC reset sequence do not occur.

A minimal synthetic thread is not yet available. Private thread IDs, prompts, outputs, local paths, and raw logs are intentionally omitted. I can provide narrower sanitized diagnostics if maintainers specify what is needed.

What is the expected behavior?

• Desktop should remain interactive while restoring a large paginated thread.
• Initial hydration should have bounded item and byte budgets and should render the newest useful content first.
• Concurrent or repeated history requests for the same thread should be coalesced, deduplicated, or cancelled when the owning view/window disappears.
• Stale route or window state should be discarded without resetting IPC or stopping the app-server transport.
• Older history should load progressively and must not block the composer, task navigation, or active status.
• A single large pinned thread should not make the whole Desktop app unusable.

Additional information

Isolation checks performed:

• VS Code was fully closed.
• Only one Codex Desktop app-server remained running.
• The Chrome companion extension host was idle and did not correlate with the freezes.
• No plugin or MCP error correlated with the failure.
• Archiving old sessions and rotating a multi-gigabyte log database reduced local storage pressure but did not remove this failure, because the triggering thread is recent and pinned.
• The current small thread remains stable in the same Desktop installation.

Potentially related but not exact duplicates:

• #38653: count-only bootstrap budget for a large paginated turn
• #33786: repeated full replay of a completed large thread
• #39228: IPC churn and EPIPE in the macOS Desktop main process
• #40934: broad instability and eager restoration of long-running threads

The distinguishing signal here is the combination of a fast app-server, more than 100 item-list requests for one VS Code-origin thread during a short restoration burst, renderer/window loss, and the deterministic IPC reset/transport-stop sequence.

Start at Desktop restoration of the pinned thread and trace the thread/items/list entry point through renderer hydration and the main-process IPC logs. Reproduce the burst with the large VS Code-origin thread and compare it with a launch that does not restore it. Done means restoration stays bounded and repeated requests are controlled without missing-window events, IPC resets, or transport shutdown.