[Windows] Desktop app re-downloads ~400MB from persistent.oaistatic.com on every cold launch, reproduced on 2 different app versions

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.8289.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On every cold launch of the Desktop app (ChatGPT.exe + codex.exe), the app downloads approximately 400MB of data from persistent.oaistatic.com in a ~15 second burst, peaking at ~54MB/s. This happens even when:

• All plugins, MCP servers, and "Codex dependencies" are disabled in settings
• The app is freshly updated to the latest available Store version
• Local Chromium cache for the domain is present and unchanged in size between launches
• Only a single MSIX package is installed (confirmed via Get-AppxPackage — no duplicate install)

Evidence

1. DNS correlation: captured DNS response for persistent.oaistatic.com returns two A records (104.18.32.47, 172.64.155.209). Packet capture (pktmon, deduplicated by PktGroupId+PktNumber) shows these two IPs account for 98.9% of all traffic (408.2MB of 412.8MB total) in a 63-second capture window around app launch.
2. Timing profile: burst duration ~15 seconds, peak throughput ~54MB/s, then drops to near-zero.
3. Reproduced on two different app versions (26.818.3698.0 → 26.818.8289.0 after forcing a Microsoft Store update specifically to test this). Second launch after update still showed ~495KB/s (codex.exe) + ~270KB/s (ChatGPT.exe) sustained for 1-2 minutes to the same persistent.oaistatic.com IPs, gradually tapering off.
4. Not explained by plugin/dependency sync: internal SQLite log (logs_2.sqlite) shows plugin catalog sync events (plugins.remote_catalog.list, bundle sync) totaling only ~250KB via the estimated_bytes column — three orders of magnitude smaller than the observed network transfer, and unaffected by disabling plugins in settings.
5. CLI comparison: running codex.exe standalone (no ChatGPT.exe/Electron shell) in idle shows near-zero background traffic (0-3 B/sec), but any launch that loads the web UI triggers the same burst.

codex doctor output was clean throughout testing: authentication configured, state database healthy, websocket connected, provider endpoints reachable, update configuration locally consistent.

Impact

On metered/roaming connections this makes the app essentially unusable — repeated launches consumed ~2GB/day even with the app closed most of the time between sessions.

Expected behavior

Static UI assets served from persistent.oaistatic.com should be cached locally after first download and reused on subsequent launches (standard HTTP cache validation / ETag), not re-fetched in full on every cold start.

Suggested diagnostic

Happy to provide the raw pktmon capture summary (deduplicated packet counts by IP) or SRUM network usage export if useful for reproduction.

What steps can reproduce the bug?

1. Open Resource Monitor → Network tab, no process filters applied.
2. Ensure the Desktop app is fully closed (system tray → Exit; verify with Get-Process ChatGPT,codex -ErrorAction SilentlyContinue returns nothing).
3. Launch the Desktop app via the normal shortcut (Start Menu / taskbar / tray icon — not CLI).
4. Watch the Network Activity table for ChatGPT.exe and codex.exe during the first 15–60 seconds after launch.
5. Observe sustained high Receive rate (400–800+ KB/s) to remote addresses in the 104.18.32.0/24 and 172.64.155.0/24 ranges.
6. (Optional, for full verification) Capture the launch window with pktmon start --etw -f launch.etl, convert with pktmon format ... -o launch.pcapng, and aggregate received bytes by remote IP, deduplicating on (PktGroupId, PktNumber) to avoid counting the same packet at multiple NDIS capture points. In my test, the top two IPs accounted for 98.9% of all traffic (408.2MB / 412.8MB) in a 63-second window.
7. Cross-reference via DNS: a captured A? query for persistent.oaistatic.com resolves to exactly those two IPs, confirming the source.

What is the expected behavior?

After the first launch (or as long as the local Chromium disk cache is present and unchanged in size), subsequent launches should not re-transfer ~400MB of static assets from persistent.oaistatic.com. Cached resources should be served from local disk or revalidated via a lightweight conditional request (HTTP 304), not fully re-downloaded on every cold start.

Additional information

• Reproduced across two consecutive app versions (26.818.3698.0 and 26.818.8289.0) after forcing a Microsoft Store update specifically to rule out a single-build issue — the burst persisted on both.
• Independently cross-checked via SRUM (System Resource Usage Monitor) network usage export to rule out double-counting or misattribution at the OS accounting level.
• Confirmed this is unrelated to the Codex/ChatGPT plugin catalog sync (plugins.remote_catalog.list), which the app's own SQLite log shows transferring only ~250KB via the estimated_bytes field — three orders of magnitude smaller than the measured network transfer.
• Happy to share the raw pktmon capture summary (deduplicated byte counts by IP) or the SRUM CSV export if useful for reproduction on your end.