Windows Desktop composer input lags with 70 GB of active rollout histories (mostly subagent sessions)

Start by tracing how Codex Desktop and the app-server discover and load files under ~/.codex/sessions, focusing on whether inactive subagent histories enter the renderer or app-server hot path. Use the reversible move-out/A-B test described in the report, then verify that a large session store no longer causes composer lag while opening a small conversation.

What version of the Codex App are you using?

26.721.4979.0 (OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0).

The problem was first diagnosed while 26.721.3996.0 was running. The app auto-updated/restarted to 26.721.4979.0 during the investigation; the pathological local session store described below remains present.

What platform is your computer?

• Windows 11 Pro, build 26200, x64
• AMD Ryzen 7 3800X
• 64 GB RAM

What issue are you seeing?

After entering a conversation, typing in the composer itself becomes very slow/stuttery. This is local UI input lag, not slow model inference or network streaming: characters are delayed while the rest of the machine remains responsive.

The currently selected thread is small (about 0.58 MB), but the active Codex session store is extremely large:

Active rollout files:          710
Active logical size:           70.2 GB
Files larger than 100 MB:       72
Files larger than 500 MB:       70
Files larger than 1 GB:         28
Largest rollout:              2052.9 MB
Current selected rollout:        0.58 MB

A first-line metadata scan (without reading the rollout bodies) shows:

source       files   logical size
subagent       543       57.43 GB
vscode         128       12.66 GB
cli             10        0.10 GB
exec            28       negligible

Most of the accumulated history was created by Codex Desktop subagent sessions. This appears important because the lag affects a small active thread, suggesting that inactive/global session history is still on a hot UI or app-server path.

Process/resource snapshots while the problem was present:

• Codex/ChatGPT desktop processes: approximately 1.7–1.95 GB working set in total
• Largest renderer process: approximately 748 MB–1.12 GB working set
• Codex app-server: approximately 1.3–1.6 GB working set
• Available system RAM: 33–35 GB
• Disk queue: 0
• WSL and Docker were not running

An 8-second observation of the largest 25 rollout files showed no growth, so the immediate lag did not require an actively growing large file. The accumulated active history alone appears sufficient to keep the Desktop renderer/app-server heavy.

Steps to reproduce

1. Use Codex Desktop and other Codex clients long enough for ~/.codex/sessions to accumulate many large rollout JSONL files, especially Desktop-created subagent sessions.
2. Start Codex Desktop.
3. Open a small/new conversation.
4. Focus the composer and type normally.
5. Observe delayed/stuttering character rendering and generally heavy UI interaction even though the selected conversation is small and system resources are available.

I have not deleted or moved the session files yet because they contain recoverable work. A reversible move-out/A-B test can be performed if maintainers need confirmation, but the current state was preserved for diagnosis.

Expected behavior

Composer input and thread navigation should remain responsive regardless of total historical rollout size. Inactive histories—especially subagent rollouts—should be indexed by bounded metadata and loaded lazily only when needed.

Potential safeguards:

• Avoid eagerly scanning/parsing all files under ~/.codex/sessions.
• Keep inactive subagent rollout bodies off the renderer/app-server critical path.
• Virtualize or lazily hydrate large histories.
• Warn when active session storage or an individual rollout exceeds a safe threshold.
• Provide a supported archive/cleanup UI that preserves recoverability.

Related issues

This appears closely related to:

• #18693 — large histories cause typing/scrolling lag
• #20864 — Desktop scans all rollout files instead of respecting indexed/visible sessions
• #21948 — one large active session causes global freezes
• #25390 — Windows Desktop becomes sluggish when opening a large local thread

The additional signal here is the scale (70.2 GB / 710 active files) and source distribution (57.43 GB across 543 subagent rollouts) on a current Windows Desktop build, while the selected thread itself is only 0.58 MB.

Privacy

No raw rollout JSONL files, local usernames, thread IDs, or unsanitized logs are attached because the histories may contain private repository and conversation data. I can provide additional sanitized metadata if requested.