Windows Codex Desktop continuously downloads ~9–10 Mbit/s while idle when IPv6 is enabled
Environment
- Windows 11
- Codex Desktop version: 26.818.3698.0
- IPv4 + native IPv6 Internet connectivity
- Traffic attributed to the Codex/ChatGPT Chromium NetworkService process
- Analytics explicitly disabled in config.toml
Problem
Codex Desktop continuously receives approximately 9–10 Mbit/s
(~1.1 MB/s) while completely idle.
The traffic stops almost immediately when IPv6 is disabled on the
Windows network adapter. Codex continues to work normally over IPv4
and idle network usage drops to approximately zero.
Re-enabling IPv6 causes the problem to return.
Observed behavior
Windows Task Manager / Resource Monitor attributes the traffic to the
ChatGPT.exe Chromium NetworkService process used by Codex.
A packet capture shows a continuous TCP download over IPv6/443.
In one capture, the dominant remote endpoint was:
2a06:98c1:310b::ac40:9262:443
Approximately 43.7 MB was received from this endpoint during a ~38.7
second capture, corresponding to roughly 9 Mbit/s.
The packets consist of a continuous stream of TCP payloads rather than
occasional keepalives or connection attempts.
After restarting Codex, the application selected a different Cloudflare
IPv6 endpoint:
2606:4700:4408::ac40:9bd1:443
Windows DNS cache associated this address with:
chatgpt.com
The high idle traffic returned after the restart. Therefore, blocking
one individual Cloudflare IPv6 address is not a persistent workaround.
Tests performed
- Codex idle with IPv6 enabled:
~9–10 Mbit/s continuous receive traffic
- Disable IPv6 on Ethernet adapter:
traffic drops to approximately 0
- Codex remains functional over IPv4
- Re-enable IPv6:
high idle traffic returns
- Analytics explicitly disabled:
no change
- Start with --disable-quic:
no change
- Start with --disable-quic --disable-http2:
no change
- Temporarily block the currently active Cloudflare IPv6 endpoint:
idle traffic drops to approximately 0
- Restart Codex:
another Cloudflare IPv6 endpoint is selected and high traffic returns
- Configure Windows DisabledComponents=0x20 ("Prefer IPv4 over IPv6"):
Windows prefix policy changes correctly, but Codex/Chromium still
establishes IPv6 connections and the problem remains
Connection behavior
While the issue is occurring, the NetworkService maintains multiple
connections to the Cloudflare IPv6 endpoint on TCP/443.
IPv4 connections are present at the same time.
Local IP addresses, hostnames, and unrelated endpoints have intentionally
been omitted from this report for privacy.
Expected behavior
Codex Desktop should not continuously download approximately 9–10 Mbit/s
while idle.
IPv6 and IPv4 should exhibit comparable idle network behavior.
Workaround
Disabling IPv6 on the Windows network adapter completely stops the
excessive idle traffic.
Codex continues to work normally over IPv4.
This is currently the only reliable workaround I have found.
Additional information
The issue is reproducible after rebooting Windows and after restarting
Codex.
It also occurs with Codex Desktop version 26.818.3698.0.
I have a Windows PktMon packet capture demonstrating the traffic, but I
am intentionally not attaching the original capture publicly because it
contains local network addresses and unrelated network activity.
I can provide additional sanitized diagnostics if needed.
Possibly related issues
- #18484 – "Codex is increasing network usage"
Similar Windows/Codex network-related report, but does not document
the IPv6-dependent continuous idle download described here.
- #23434 – IPv6-related WebSocket connectivity issue
Different symptom/platform, but potentially related to IPv6/IPv4
connection selection for chatgpt.com in Codex.
- #34542 – Excessive network traffic in Codex Desktop
Different direction and trigger (large upload during an active task),
but potentially relevant to excessive Desktop network activity.
2 Comments
Important additional finding: toggling IP protocols while Codex is running clears the excessive traffic
I performed additional tests and found a reproducible behavior that changes my initial assumption that IPv6 itself is the direct cause.
The excessive idle traffic appears to be related to the network connection state established when Codex starts.
Test 1 – Start with IPv6 disabled
Initial state:
Steps:
Final state:
Test 2 – Start with IPv6 enabled
Initial state:
Steps:
Final state:
Conclusion
The problem is therefore not simply caused by IPv6 being enabled.
In both tests, changing the available IP protocols while Codex is already running immediately clears the excessive network traffic. After restoring the normal dual-stack configuration (IPv4 + IPv6), the excessive traffic does not return as long as the same Codex instance remains running.
Restarting Codex causes the excessive idle traffic to occur again.
This suggests that the issue may be related to connection initialization or a bad/stale connection state in the Chromium/ChatGPT NetworkService when Codex starts.
Changing the available IP protocols while the application is running appears to force the NetworkService to recreate its connections, after which network behavior becomes normal.
This also explains why disabling IPv6 previously appeared to be a workaround: changing the network protocol availability while Codex was running was likely resetting the problematic connection state rather than IPv6 itself being the root cause.
Reproducible pattern
Codex start
→ ~9–10 Mbit/s continuous idle download
→ change available IPv4/IPv6 protocols while Codex remains running
→ existing network connections are recreated
→ traffic immediately drops to approximately zero
→ restore IPv4 + IPv6
→ traffic remains normal
→ restart Codex
→ excessive traffic returns
Small correction / simplification of the workaround:
It is not necessary to toggle IPv4.
The following is sufficient and reproducible:
IPv4 remains enabled throughout the entire procedure.
So simply resetting IPv6 connectivity while the running Codex instance
is active is sufficient to clear the excessive traffic state.
For the current-build idle-download symptom, one reversible connection-reset workaround reported with an A/B check is:
This only forces the NetworkService connections to be recreated; it does not identify or fix the underlying cause. Changing IPv6 briefly affects other network connections, so do not use it during an important transfer or call, and restore the original setting afterward.