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

Open 💬 3 comments Opened Jul 25, 2026 by jixianyihao

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Use Codex Desktop and other Codex clients long enough for ~/.codex/sessions to accumulate many large rollout JSONL files, especially Desktop-created subagent sessions.
Start Codex Desktop.
Open a small/new conversation.
Focus the composer and type normally.
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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#34450
#34915
#34572

Powered by Codex Action

boombx403-byte · 9 days ago

Hi @jixianyihao, this subagent persistence/history issue aligns with some boundary anomalies observed in multi-agent rollouts. Codex Rescue Alpha5 provides read-only lifecycle and subagent boundary diagnostics, cleanly separating historical start markers from current live execution state without altering the source rollout.

If you have access to the local session, you can run a non-destructive check:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw session data is required, and please redact private paths if you share any output.

krutftw · 3 days ago

Additional Windows reproduction on a newer build where this progresses beyond typing lag into thread hydration/resume stalls.

Environment (observed 2026-08-24):

Windows 11 Pro 10.0.26100, x64; Ryzen 9 3900X; 32 GB RAM
Codex Desktop MSIX 26.818.8289.0
bundled app-server 0.149.0-alpha.4.3

Privacy-safe inventory captured before making any session changes:

August rollout files:            579
August logical size:          131.01 GiB
Subagent rollouts:               527 / 130.20 GiB
Non-subagent rollouts:            52 /   0.81 GiB
Files >100 MiB:                  183
Files >250 MiB:                  138
Largest 30:             all forked subagents / 39.89 GiB

The representative large files were ordinary, non-sparse, single-link JSONL files. One 1.31 GiB child contained 111,876 records; its first-record metadata identified it as a full-history subagent fork. No rollout contents were printed or shared.

The completed Desktop logs give a direct latency/error signature:

On the latest run, two thread/resume responses took 8,241 ms and 39,641 ms.
Seven thread/turns/list calls averaged 20,198 ms and reached 29,976 ms.
An earlier run emitted 1,422 maybe_resume_started events in 17.67 seconds (about 80/s), almost all with previousResumeState=resuming.
That run then logged 12 thread/read hydration timeouts at the 15-second limit, app-server queue expiry/time-out errors (-32001), and an IPC EPIPE reset.
Recent logs also contain Received turn/started for unknown conversation; that part appears related to #32737, but I am not assuming it is the cause of the general resume latency.

PRAGMA quick_check returned ok for state_5.sqlite, thread_history_1.sqlite, and queue_1.sqlite. There were no matching Windows app-hang/crash, Resource Exhaustion 2004, disk, or NTFS events in the checked window.

The immediate whole-PC lag was amplified by an active Codex task that had spawned several long-running rg.exe searches. Closing only Desktop cleared that load. However, the resume storm, 15-second hydration queue failures, and multi-second RPC timings are independently present in the Desktop logs and align with the oversized subagent-heavy store.

A full Desktop exit released all Desktop-owned writer locks. The remaining lock files mapped one-to-one to still-running CLI codex.exe PIDs, so this snapshot did not show an orphaned writer lock.

This looks consistent with inactive/full-history subagent rollouts remaining on a hot app-server hydration path. Bounded/lazy hydration plus a supported retention/archive path would prevent the UI from appearing to restore a transcript but never becoming usable.

No raw logs, local paths, thread IDs, titles, or conversation data are attached.