Codex prompt submission can trigger local network latency spikes and packet loss on macOS

What version of Codex is running?

Codex App: 26.519.22136 (3003)<br>VS Code Extension: 26.513.21555<br>Codex CLI: 0.133.0

Which model were you using?

gpt-5.5 medium

What platform is your computer?

macOS 26.5 on a laptop<br>Connection: Wi-Fi<br>Local router/gateway: private LAN IP, redacted as <local-router-ip>

What issue are you seeing?

When submitting prompts to Codex, especially in longer conversations, my local network appears to experience a latency spike / packet loss event.

This affects other real-time traffic on the same network at the same time:

• A game client's latency jumps from normal low double-digit milliseconds to 2000+ ms.
• Streaming video on another device buffers.
• A local monitoring script shows packet loss / severe latency to both public internet targets and my local router gateway.

The issue is a recent regression in my environment and appears to reproduce across Codex clients:

• Codex macOS app
• VS Code integration
• Codex CLI

It also occurs regardless of whether a VPN is enabled, so the VPN does not appear to be the root cause.

Evidence from local network monitor

I ran a local network monitor that pings public targets and the local router gateway every \~2 seconds while also logging DNS timing and process network snapshots.

During a Codex prompt submission, the monitor captured this:

[2026-05-21 19:29:18] PACKET_LOSS target=8.8.8.8 status=fail
[2026-05-21 19:29:28] LATENCY_SPIKE target=1.1.1.1 status=ok latency_ms=212.500
[2026-05-21 19:29:28] PACKET_LOSS target=8.8.8.8 status=fail ... round-trip ... 1649.964 ms
[2026-05-21 19:29:28] PACKET_LOSS target=<local-router-ip> status=fail ... round-trip ... 1942.024 ms
[2026-05-21 19:29:49] PACKET_LOSS target=1.1.1.1 status=fail
[2026-05-21 19:29:49] PACKET_LOSS target=8.8.8.8 status=fail
[2026-05-21 19:29:49] PACKET_LOSS target=<local-router-ip> status=fail
[2026-05-21 19:30:15] ping target=<local-router-ip> status=ok latency_ms=4.460

Before the event, baseline latency was roughly:

1.1.1.1             ~17-26 ms
8.8.8.8             ~100-125 ms
<local-router-ip>   ~4-8 ms

The important detail is that the local router gateway spikes/losses too, so this appears to be a local network disruption triggered around Codex prompt submission, not just a remote service response delay.

Process/network snapshot around the spike

At the same time, the local process network snapshot showed Codex outbound traffic increasing during the event:

19:29:21 codex ... bytes_out=3623840
19:29:35 codex ... bytes_out=9098429
19:29:42 codex ... bytes_out=13801601
19:29:51 codex ... bytes_out=21807722
19:30:08 codex ... bytes_out=29932453

This suggests a relatively large or bursty upload during prompt submission.

Steps to reproduce

1. Use Codex on macOS over Wi-Fi.
2. Work in a longer Codex conversation.
3. Keep latency-sensitive traffic running, such as a game or streaming video.
4. Run a local monitor pinging both public targets and the local router gateway.
5. Submit a prompt to Codex, especially after the conversation has grown.
6. Observe:

• Codex prompt submission occurs.
• Other network traffic stalls or buffers.
• Router gateway ping can spike from \~5 ms to \~1900 ms or packet loss.
• Public pings also spike/loss.
• Network recovers afterward.

Expected behaviour

Submitting a Codex prompt should not create a network burst large enough to disrupt local network latency, packet delivery to the router, games, or streaming traffic.

Actual behaviour

Codex prompt submission appears to create a burst of outbound traffic during longer sessions, causing local network latency spikes and packet loss that affect the whole network.

Additional notes

I searched existing issues and found related performance reports around long sessions / submit path / large local session history, but did not find one specifically about local network latency spikes:

• openai/codex#18495
• openai/codex#22283
• openai/codex#12709
• openai/codex#21326
• openai/codex#19278

This may be related to longer session context, large local session history, or prompt submission batching. A client-side upload throttle, compression change, or less bursty submit behaviour may help.