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

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

• #33760
• #33786
• #32722
• #33735

Powered by Codex Action

<img width="864" height="135" alt="Image" src="https://github.com/user-attachments/assets/1b5c3b90-f7cc-4624-8f72-7fde20a7c111" />

<img width="648" height="716" alt="Image" src="https://github.com/user-attachments/assets/ee4a4aa7-2f7f-43b7-a5ce-bf9dd569d200" /> so slowww what we do my files only 209 MB but that 40GB and 3 hours still ...

Additional sanitized diagnostics from another affected Windows Desktop installation:

• Codex Desktop version: 26.727.6591.0
• Platform: Windows x64
• Proxy measurement source: Mihomo v1.19.29 /connections counters via its local named-pipe API (TUN enabled)
• Current Mihomo process uptime at measurement: 2.73 hours
• Cumulative traffic during that uptime: 2.21 GB uploaded vs 0.25 GB downloaded
• A 45-second connection-delta sample attributed about 87% of observed upload to codex.exe + ChatGPT.exe.
• The active long-running rollout was 873.3 MiB. During the same proxy-core window it grew by only 33.78 MiB, of which 29.84 MiB was 50 unique embedded image blobs.
• Applying the observed 87% process share gives roughly 1.92 GB of Codex/ChatGPT upload for 33.78 MiB of new rollout data (approximately 54x amplification; this is an estimate because closed Mihomo connections no longer retain per-process attribution).
• Mihomo logs recorded 1,256 new connections to chatgpt.com during this period, with bursts opening a new codex.exe connection every 1–2 seconds during tool-heavy activity.
• Independent HTTP trace analysis found 37 unique image payloads appearing 99 times in logged request bodies: 45.75 MiB transmitted vs 23.08 MiB unique. The same multi-megabyte image was present up to four times.
• The observed Responses requests used store: false, consistent with accumulated context/tool artifacts being sent again after tool continuations.
• Upload falls near idle when the long-running task is inactive, so this does not look like a constant background telemetry upload.

This provides direct evidence for the suspected amplification path: image/tool outputs are embedded in rollout history and image data is included again in later model requests. Long-running tool loops multiply that cost.

Suggested fix:

1. Do not include returned/generated image bytes or data URLs in later model requests after the model has consumed the tool result.
2. Store each image once as an asset and reference it by immutable asset ID/hash.
3. Deduplicate image/tool artifacts by content hash across continuations and compaction.
4. Keep binary image payloads out of rollout compaction/context unless explicitly reattached by the user.
5. Add an upload/context-size guardrail and surface which task is producing abnormal outbound traffic.

No session contents, images, local paths, credentials, account identifiers, proxy endpoints, or repository details are included here. This also strengthens the image-specific correlation reported in #19643.

I am seeing the same underlying problem on Windows: long Codex Desktop threads progressively become extremely slow and can saturate my upload bandwidth, even though compaction itself succeeds.

Same-instant NetLimiter evidence:

• Total real Internet upload: ~695 KB/s
• codex.exe upload: ~680.2 KB/s

So codex.exe was using about 98% of the available upload capacity at that moment. The NetLimiter chart also shows 269.95 MB uploaded by codex.exe in the displayed time window.

The primary symptom is progressive latency: the first messages in a thread are fast, then the conversation becomes so slow that switching to Fast mode makes little or no perceptible difference. The bottleneck is no longer model generation.

Local diagnostics of my affected active refactor thread:

• Rollout size: ~250 MB
• Local tokens_used counter: 175,455,695
• At least 45 embedded data:image/base64 payloads
• 2,218 tool_call markers
• 141 compaction markers

Compaction does not fail. However, it appears not to prevent old embedded images, browser/tool artifacts, and large local session state from continuing to cause excessive hydration, upload, or processing.

Expected behavior:

• Compaction should make long threads remain responsive.
• Old image/tool/browser artifacts should be externalized, deduplicated, or referenced incrementally rather than repeatedly processed or transmitted.
• Upload should be bounded/backpressured, especially on constrained uplinks.

Follow-up: I submitted in-product feedback from the same affected active refactor thread, including the current session logs. Feedback ID: 019fce40-a89f-7862-8a72-96e29ed664f1.

The feedback was submitted immediately after a fresh reproduction where the thread entered repeated “Reconnecting” states and its logs recorded stream disconnected - retrying sampling request for the same turn.

The combination of 1–2 GB rollouts and large upload bursts specifically during resume makes this a useful oversized-history test. Codex Rescue can inspect persisted records with bounded reads and flag oversized payloads without loading or rewriting the original session.

It cannot fix the Desktop hydration/retransmission path or the upstream network amplification. I’m looking to verify whether its local diagnosis identifies the right structural boundary before that path is exercised.

If one affected session still exists, would you try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized structural output is enough. Please don’t publish the raw rollout, embedded images, prompts, SQLite data, credentials, repository contents, or private paths.

https://github.com/shleder/codex-rescue

This is my solution :

i do it like this:

• [ ] Close Codex completely.
• [ ] Copy the large session JSONL from the Codex sessions folder to a separate folder as a backup.
• [ ] Open a new Codex chat and ask it to create a safe, reduced version without modifying the original file.
• [ ] When it finishes, close Codex again.
• [ ] Rename the reduced JSONL so its filename is exactly the same as the original session file.
• [ ] Put it back into the original sessions folder, replacing the large file.
• [ ] Reopen Codex and continue the old conversation.
• [ ] Always keep the original file somewhere safe in case the reduced version does not load correctly.

After all this, your file will be around 10MB - 15MB and your last conversations will be saved.

Current-build Windows reproduction with a still-running inherited child

Reporter: @berkyuo2-cpu
Affected ChatGPT/Codex profile: berky1905

Environment:

• Codex Desktop AppX: 26.803.10989.0
• codex-cli 0.144.1
• Windows x64: 10.0.19045

I reproduced the same upload amplification and was able to identify the exact logical task that remained live.

Evidence while affected

• The parent media-heavy task was shown as idle in the Desktop task list, but two full-history subagents were still active.
• Their persisted rollout sizes were 568.8 MiB and 584.7 MiB.
• The 584.7 MiB child had a local tokens_used value of 117,782,759 and its spawn edge remained open.
• The child's state timestamp continued advancing while the parent was idle and while the upload bursts were occurring. This was not a stale file-size correlation.
• A 10-second NetLimiter database delta attributed 33.33 MiB outbound to the Codex app-server (codex.exe, about 3,413 KiB/s), while all node.exe processes together sent only about 89 KiB.
• One 2-second interval showed 41.02 MiB outbound on the Codex chatgpt.com:443 flow.
• The Desktop eventually became stuck on the black loading/splash screen with the OpenAI logo and had to be closed and reopened.

This separates the direct network source from the MCP process problem: the idle MCP Node processes were a large RAM cost, but the quota-consuming upload was the Codex app-server carrying/retrying the inherited media-heavy model context.

Restart A/B

After closing and reopening Codex Desktop:

• the affected parent and children were no longer active/loaded;
• adapter upload fell to 0.086 Mbit/s over an 8-second sample;
• Node count fell from 122 to 8 and aggregate Node working set fell from roughly 7 GiB to 183 MiB;
• the previously duplicated heavy local MCP families did not restart.

The restart was the emergency stop; it is not an acceptable normal recovery path because active work can be lost.

This field reproduction appears to connect the mechanisms already reported in #34268 / #33235 (full-history media inheritance and upload amplification), #36141 (child outliving an idle/completed parent), and #37541 (Desktop splash/renderer stall).

Suggested invariants:

1. A full-history fork must not physically clone inline image/data-URL payloads; immutable asset references should be shared and deduplicated.
2. A parent must not be reported idle/completed while a child is still actively sampling without a visible lifecycle control.
3. Parent checkpoint/stop must be able to interrupt its exact running children without reopening and retransmitting the full parent history.
4. Add upload/context-size backpressure and surface the task/child responsible for abnormal outbound traffic.

Usage restoration request

This defect repeatedly retransmitted inherited context and consumed a substantial portion of the affected profile's weekly Codex allowance while the UI appeared idle and again during diagnosis/recovery. Please restore/reset the weekly Codex usage allowance for profile berky1905, or route this evidence to the account-support team that can perform the restoration. The authenticated GitHub reporter is @berkyuo2-cpu.

I have kept private project paths, prompts, media, rollout contents, credentials, and session IDs out of this public comment.

Current-build follow-up: domain-attributed upload amplification with a much smaller multimodal rollout

This is a fresh reproduction on:

• Codex Desktop MSIX 26.818.2441.0 x64
• app-server 0.148.0-alpha.21
• Windows 10 22H2 build 19045

NetLimiter's per-process/per-connection counters were used so combined Windows process I/O was not misreported as network traffic.

During a 12:47–15:19 local observation window:

• Main codex.exe: 8,265,306,320 bytes sent, 713,924,833 bytes received.
• 8,262,947,034 bytes sent (about 99.97%) were attributed directly to chatgpt.com.
• Average app-server upload over that window was about 7.26 Mbit/s, or about 3.27 GB/hour.
• The ChatGPT.exe UI/network process received 604,388,909 bytes and sent 10,420,717 bytes.
• Provider/MCP traffic was tiny by comparison (each measured provider was below 1 MB sent).

This was not an active static-asset/cache download loop:

• One startup connection to persistent.oaistatic.com downloaded 525,906,987 bytes.
• The next seven connections to that host transferred only about 5 KB total.
• Plugin/runtime cache roots were stable during the affected interval.

The chatgpt.com connection history instead contained repeated outbound connections in the 83–112 MB range.

Local structural correlation:

• The active rollout was 54,505,185 bytes.
• It contained 22 data:image markers and 7 input_image markers.
• Another active task rollout was 338,574,701 bytes.
• A 15.2-second adapter sample measured 27,713,113 bytes sent versus 915,147 bytes received system-wide.

TLS payloads were not decrypted, so I am not claiming byte-for-byte proof of a particular request body. However, the exact destination, outbound connection sizes/timing, and embedded multimodal context strongly support repeated model-context upload rather than telemetry, MCP provider traffic, or a static-cache loop.

The current app also had repeated idle MCP helper batches, but those helpers had zero established TCP connections during the sample. They are a separate RAM/IPC problem, not the source of this upload.

Requested safeguards:

1. Externalize image/tool binaries once and reuse immutable asset IDs/hashes.
2. Deduplicate previously consumed data:image and tool-result artifacts across continuations, compaction, and subagent inheritance.
3. Send incremental context rather than retransmitting an unbounded hydrated history.
4. Add per-task outbound/context-size attribution in the UI.
5. Add upload backpressure and a warning/circuit breaker before a task consumes gigabytes.
6. Default subagent handoff to a compact checkpoint instead of full multimodal history.

No packet payloads, images, prompts, local paths, task IDs, account identifiers, or credentials are included.

Seconding the backup-first instinct from earlier replies, with one hardening: copy through a verified snapshot rather than plain file copies, so a partially-written source does not become your backup. vetto rescue snapshot <rollout> --output <dest> double-reads the source, fails closed on mid-read changes, and never writes inside the state root.