Windows Desktop uploaded ~6.4 GB unexpectedly; codex.exe accounted for 98.8% of a controlled capture

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.com had 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:

1. Use Codex Desktop for a long-running task with many tool calls, local diagnostics, web research, and a long conversation history.
2. Route the machine through a metered proxy and monitor outbound bytes by process and destination.
3. Continue the active Codex task.
4. Observe repeated multi-megabyte uploads from codex.exe to chatgpt.com.
5. 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:

• #33796 — Windows Desktop upstream bursts with large rollout sessions
• #32533 — incremental WebSocket reuse invalidation followed by a full-history request
• #19643 — sustained upload saturation and WebSocket fallback
• #20805 — reconnect behavior in large/image-heavy chats
• #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.