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.

No source file, test, or entry point is identified in the report. First reproduce the idle traffic on Windows with native IPv6 enabled, using the described IPv4/IPv6 comparisons and a sanitized PktMon capture; done means Codex remains functional without sustained idle TCP/443 downloads over IPv6.