Repository navigation
Windows Desktop uploaded ~6.4 GB unexpectedly; codex.exe accounted for 98.8% of a controlled capture #38014
Description
What version of the Codex App are you using?
26.803.10989.0 (Microsoft Store/MSIX package OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0)
What subscription do you have?
ChatGPT Plus.
What platform is your computer?
Microsoft Windows 11, build 26300, x64.
What issue are you seeing?
Codex Desktop generated extremely large outbound traffic to chatgpt.com during a long, tool-heavy task.
The broader incident window showed an unexpected increase of approximately 6.4 GB in metered proxy/Azure traffic. Historical per-connection rows were not retained for that entire interval, so I cannot attribute every byte of the 6.4 GB total at process level.
I then ran a controlled per-process/per-host capture. In that capture:
- Total capture duration: 9 minutes 58 seconds.
- Total upload recorded across all processes: 184.472 MB.
codex.exe -> chatgpt.com: 182.266 MB, or 98.8% of all captured upload.codex.exe -> chatgpt.comhad 30 non-zero upload samples.- The concentrated Codex upload interval lasted 6 minutes 32 seconds.
- Total Codex upload including
ab.chatgpt.com: 183.033 MB. - Total download during the same capture was only 2.870 MB.
Representative sanitized samples, expressed as relative offsets rather than local timestamps:
T+00:00 codex.exe chatgpt.com 8.872 MB upload
T+00:01 codex.exe chatgpt.com 5.399 MB upload
T+03:31 codex.exe chatgpt.com 10.616 MB upload
T+03:47 codex.exe chatgpt.com 10.102 MB upload
T+05:07 codex.exe chatgpt.com 9.674 MB upload
The rows are sampling deltas, not cumulative counters. Consecutive rows may be chunks of one transfer, so I am not treating each row as a separate HTTP request. The aggregate byte totals are the relevant evidence.
Other suspected background applications were ruled out in the controlled capture:
- CrossDeviceService: approximately 0.028 MB uploaded.
- OneDrive Sync Service: approximately 0.002 MB uploaded.
- No other process/host pair was remotely close to Codex.
The executable was the Codex app-server binary bundled with the installed OpenAI Codex package. The destination was chatgpt.com over TLS. The capture proves the process, destination, relative timing, and byte volume; it does not inspect or claim to know the encrypted payload contents.
What steps can reproduce the bug?
The exact minimal trigger is not yet isolated, but the observed workflow was:
- Use Codex Desktop for a long-running task with many tool calls, local diagnostics, web research, and a long conversation history.
- Route the machine through a metered proxy and monitor outbound bytes by process and destination.
- Continue the active Codex task.
- Observe repeated multi-megabyte uploads from
codex.exetochatgpt.com. - When Codex becomes idle, the high upload rate subsides.
The affected connection had intermittent performance, so WebSocket reconnect/fallback may be an amplifier. However, the proxy was forwarding the traffic; codex.exe was the originating process.
Expected behavior
- Normal tool continuations should use bounded incremental requests.
- A long task should not silently upload hundreds of megabytes within minutes.
- Full-history retries/resends should be avoided, deduplicated, compressed, or preceded by compaction.
- The client should warn before a large full-history upload, especially on a metered connection.
- The UI should expose per-thread outbound byte counts and identify when retries or history replay are occurring.
- Users should be able to cancel or disable unbounded full-history retry behavior.
Actual behavior
A controlled 10-minute capture recorded 182.266 MB from codex.exe to chatgpt.com, while the broader metered-traffic anomaly was approximately 6.4 GB. There was no UI warning or indication that the active thread was sending this volume of data.
Additional information
This may be related to:
- Windows Desktop: multiple 1–2 GB rollout sessions trigger ~71 Mbps upstream bursts during resume #33796 — Windows Desktop upstream bursts with large rollout sessions
- Responses Lite: changing reasoning effort can strand a large session on “Request blocked.” until compaction #32533 — incremental WebSocket reuse invalidation followed by a full-history request
- Image generation tasks cause sustained upload saturation, network slowdown, and connection drops (Broken pipe / WebSocket fallback) #19643 — sustained upload saturation and WebSocket fallback
- Bug: image-heavy chats repeatedly reconnect and become very slow #20805 — reconnect behavior in large/image-heavy chats
- Large active session causes global freezes with no UI attribution #21948 — oversized active session affecting the whole desktop app
I have retained the original CSV capture and can provide a redacted copy or additional aggregate diagnostics if a maintainer specifies a safe private channel. I am not attaching raw rollout/session files because they may contain private prompts, tool output, local paths, and credentials.
Activity
github-actions commentedon Aug 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
bj008hb commentedon Aug 30, 2026
Adding a macOS and metered-VPN data point, plus a broader product-level request.
Across two consecutive days, server-side connection accounting measured:
chatgpt.comupload: 2.56 GiB and 4.39 GiBab.chatgpt.comupload: 0.22 GiB and 0.14 GiBThe accounting identifies destination domains and byte counts, not encrypted payload contents or the originating macOS process. However, the largest hourly peaks aligned closely with long, tool-heavy Codex Desktop tasks involving repeated validation, retries, and context-heavy phases.
The authoritative local state read by one of those tasks was only about 1.1 MB, and there is no evidence that locally built binary artifacts were intentionally uploaded. The observed GiB-scale upload therefore appears disproportionate to the actual new task input and is consistent with context replay, reconnect/fallback amplification, repeated tool output, or similar client-side behavior.
Project instructions and
AGENTS.mdcan reduce tool output, but they cannot control opaque client retries or background synchronization. This needs product/runtime-level support.Requested defaults:
No raw session files, IP addresses, private prompts, project content, or account identifiers are included in this report.
yuqyang0316-commits commentedon Oct 5, 2026
I have a very similar Windows Desktop case, but at a substantially higher observed rate.
Sanitized environment / workflow:
A read-only 5-minute diagnostic produced the following:
codex.exe -> chatgpt.com: 417.28 MB uploaded, 6.42 MB downloadedchatgpt.comwere observed during the sampleThe proxy layers also double-counted forwarded traffic in Windows/app-level statistics, so I do not treat proxy totals as physical-byte totals. However, the physical WLAN counters confirm that the Codex upload itself is real and very large.
Additional observations:
idle timeout waiting for SSEwas followed by a retry ~183 ms laterchatgpt-httpwithsupports_websockets=falseLonger-term Windows data-usage counters are also very large (hundreds of GB over 30 days), but because proxy stages are counted separately I am not presenting those as physical network totals.
The important point is that this controlled capture alone shows roughly 417 MB of Codex upload in ~5 minutes to
chatgpt.com, which is materially higher than the original report here.I have not decrypted request bodies, so I cannot prove whether the payload is repeated conversation history, project snapshots, images, tool output, or normal new request content. The next useful diagnostic would be identifying whether a particular thread/task causes the sustained large uploads, and whether retry/fallback behavior is resending large request bodies.
Please consider:
I can provide further sanitized aggregate diagnostics if useful, but I would prefer not to upload raw session contents because they may contain private prompts/files.
yuanxue127-byte commentedon Oct 10, 2026
Additional Windows data point for investigation:
Codex Windows app package version: 26.1007.2314.0.
On 2026-10-10, Windows Resource Monitor showed outbound traffic during both an image-processing task and an ordinary document/JS task. This also occurred in a newly opened Codex window. The observed path was
codex.exesending to a local Nano proxy, whilenano.exesimultaneously sent traffic to external servers. Rates were approximately 1–1.5 MB/s fromcodex.exeto the local proxy and 1–1.7 MB/s fromnano.exeto external servers. After the Codex task was paused or ended, the rates gradually fell to a few KB/s.A read-only inspection of the local
logs_2.sqlitefound 60Compressed request body with zstdrecords between 23:05 and 23:40 (Beijing time) on 2026-10-10. The recorded post-compression size averaged about 15.4 MB, with a maximum of about 23.5 MB; 55 records were associated with one thread.These 60 compression records begin at 23:05, after the first observed upload spike at approximately 22:59, so they do not directly explain that initial peak.
These compression records only show that request bodies were compressed. They do not establish that the requests were actually sent, that any payload was uploaded more than once, or that a WebSocket-to-HTTP fallback occurred. I found no explicit evidence of such a fallback or a network retry in the inspected logs. The payload composition and whether the large bodies contained repeated context remain unknown.
The root cause is not confirmed. Could the team investigate unusually large request payloads and outbound network usage during active Windows Codex tasks, including whether any requests are retransmitted or repeatedly include prior context? I have not attached raw databases, session files, or private project data.