Windows Desktop: multiple 1–2 GB rollout sessions trigger ~71 Mbps upstream bursts during resume

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

26.715.2305.0

What subscription do you have?

ChatGPT subscription (exact tier was not exposed by the local diagnostics used for this report)

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

Codex Desktop intermittently saturates upstream bandwidth while multiple very large rollout/session files are active or being resumed.

This was measured locally rather than inferred from Task Manager alone:

• During an 8-second affected interval, the active WLAN adapter averaged about 8.9 MB/s upload (~71 Mbps) while download was about 0.27 MB/s.
• The I/O spike was concentrated in the Codex Desktop app-server process and ChatGPT renderer/network-service processes.
• The traffic used HTTPS connections directly and through a local loopback proxy. The proxy was only forwarding the traffic; Codex/ChatGPT processes were the source.
• During a later 12-second idle interval, upload dropped to about 0.03 MB/s average (0–0.15 MB/s), so this is a burst associated with active/resuming work rather than constant background traffic.
• The local session store contained 245 rollout JSONL files totaling about 23.9 GB.
• 15 rollout files were larger than 1 GB; the largest was about 2.0 GB.
• Several 1.6–2.0 GB rollout files were being modified during the affected period.
• More than 20 node_repl tool-runtime child processes were present under Codex.

No packet payloads, account identifiers, local paths, repository names, remote addresses, credentials, or session contents are included in this report.

This appears related to #19643, #20805, and #21948, but the observed failure mode here is specifically Codex Desktop on Windows with multiple 1–2 GB rollout files and measurable high-upstream bursts during active/resume behavior.

What steps can reproduce the bug?

The exact minimal trigger is not yet known, but this is the observed workflow:

1. Use Codex Desktop on Windows for long-running browser, computer-use, image, or tool-heavy sessions.
2. Accumulate multiple large rollout JSONL files; in this case several reached approximately 1.6–2.0 GB.
3. Leave several such sessions active/unarchived, or resume/open them while Codex tool runtimes are still present.
4. Monitor adapter throughput and per-process I/O.
5. Observe Codex/Desktop processes producing large upstream bursts that can saturate the connection.
6. Let the work become idle; upstream traffic returns close to zero.

Session IDs are intentionally omitted because the associated rollouts may contain private repository and browser context. I can provide additional sanitized aggregate diagnostics if maintainers specify what counters are needed.

What is the expected behavior?

• Session resume/hydration should not retransmit or repeatedly process unbounded embedded history.
• Oversized image/browser/tool artifacts should be deduplicated, externalized, or incrementally referenced.
• Inactive oversized sessions should not cause network activity in unrelated active work.
• Upload bandwidth should be bounded and backpressured.
• The app should identify which session/task is sending data and warn when rollout size becomes abnormal.
• Tool-runtime child processes should be cleaned up when their task has finished.

Additional information

The strongest local correlation is between the upload bursts and several concurrently active 1.6–2.0 GB rollout files. This does not prove that every byte of those files was uploaded, but it strongly suggests an unbounded session hydration/reconnect or artifact-handling path.

Related issues:

• #19643 — sustained upload saturation during image-related Codex tasks
• #20805 — image-heavy chats repeatedly reconnect
• #21948 — oversized browser-heavy session degrades the whole Windows app
• #22004 — very large rollout JSONL files and desktop process limits