macOS Desktop 26.818: task switching becomes multi-second again shortly after restart

Summary

On the current ChatGPT/Codex Desktop build for macOS, switching between long-running local tasks becomes multi-second again shortly after a full app restart. The slowdown correlates strongly with active task-history size and app-server memory growth. It does not correlate with system-wide memory pressure.

This is a current-build reproduction of the broader history-hydration problem tracked in #21211. It additionally shows that restarting the app is only temporary and that plugin/MCP status requests can add several seconds on the same navigation path.

Environment

• ChatGPT/Codex Desktop: 26.818.31338 (build 6892)
• Bundled Codex CLI: 0.149.0-alpha.4
• macOS 26.6.1, Apple Silicon

Steps to reproduce

1. Keep several long-running local Codex tasks with large persisted histories.
2. Fully quit and restart the desktop app.
3. Repeatedly switch between a small task and several large tasks.
4. Continue normal use for less than one hour.
5. Observe task-switch latency, app-server memory, and desktop logs.

No compaction, deletion, or modification of task histories is required to reproduce this.

Observed behavior

In a fresh app process approximately 51 minutes after restart:

• thread/turns/list: 28 calls, median 2047 ms, p95 2794 ms, maximum 2828 ms.
• A small task completed the same method in approximately 56 ms.
• Large tasks were generally in the 1.9-2.6 s range.
• thread/resume: median 258 ms, maximum 5002 ms.
• thread/list: maximum 3556 ms.
• plugin/list: median 644 ms, p95 4935 ms, maximum 5066 ms.
• mcpServerStatus/list: one observed call took 12882 ms.
• The app-server RSS was approximately 1.07 GB; a process sample reported a physical-footprint peak of approximately 3.0 GB.
• The main renderer used approximately 596 MB RSS.
• macOS still reported approximately 63% free memory-pressure capacity, so this was not system-wide memory exhaustion.
• The desktop log recorded 153 ResizeObserver loop completed with undelivered notifications errors during the same approximately 51-minute app lifetime.

The app-server had several active local history files open. The largest were approximately 822 MB, 634 MB, and 401 MB. Archived histories were not open in the sampled process. This is correlation evidence, not proof that file size is the sole cause.

The visible result is delayed task navigation. Restarting temporarily reduces accumulated state, but the same slowdown returns during normal task switching.

Expected behavior

• Task navigation should remain responsive regardless of total persisted task-history size.
• Initial task rendering should load a bounded recent tail and lazy-load older or large tool-output records.
• App-server memory should remain bounded after navigating among completed or idle tasks.
• Plugin/MCP status discovery should not block task navigation.
• Switching tasks should not trigger repeated renderer observer-loop errors.

Additional notes

• Compacting or deleting histories is not an acceptable product-level fix; those histories are user data and may still be needed.
• The evidence supports a local desktop history-hydration/navigation problem. It does not establish remote model-resource throttling.
• Related: #11011, #18693, #21211, #25779.

Privacy

No account details, names, task titles, task IDs, project names, local paths, prompts, responses, chat contents, session transcripts, screenshots, raw logs, tokens, cookies, or other personal data are included or attached.

Start by reproducing the regression after a full restart while measuring thread/turns/list, thread/resume, thread/list, plugin/list, and mcpServerStatus/list latency, app-server memory, and renderer logs. Read the history-hydration context in #21211 and related issues; done means task switching stays responsive with large persisted histories, memory remains bounded, and plugin/MCP discovery does not block navigation.