[Windows][Networking][WSL] Codex activity correlates with repeated Ethernet loss / route failure; WSL NIC rebuilds observed; LAN port change restores full throughput

Sanitized technical bug report

Privacy note: This report is intentionally sanitized. It does not contain the Windows user name, computer name, public IP address, MAC addresses, Wi‑Fi SSID, ISP account details, local project paths, OpenAI account identifiers, or other personal identifiers.

Environment

• OS: Windows 10 Pro x64
• Physical Ethernet NIC: Intel(R) Ethernet Controller I226-V
• Intel driver: 1.1.4.45 (e2f.sys, INF oem140.inf)
• Physical Ethernet link reported by Windows: 1.0 Gb/s
• Router: TOTOLINK A3002RU, firmware V3.4.0 / B20201030.1754
• Internet service: approximately 300 Mb/s down / 35 Mb/s up
• Codex Desktop package observed after update: OpenAI.Codex_26.818.8289.0_x64
• WSL / Hyper-V / HNS components are installed and have been observed active during Codex work

Summary

During multiple Codex Desktop sessions involving broad/deep local system audits and tool activity, the Windows machine repeatedly experienced loss of usable Internet connectivity on the physical Intel I226-V Ethernet adapter.

The user repeatedly observed Codex entering reconnect loops (Reconnecting 1/5 through 5/5) at or around these incidents. WSL/Hyper-V virtual networking activity was also observed, including a WSL virtual NIC rebuild sequence.

The correlation is strong from repeated user observation, but this report does not claim that Codex or WSL is proven to be the root cause.

The most important current evidence is:

1. The Intel I226-V can maintain a 1 Gb/s local physical link and communicate with the router with zero loss and sub-millisecond latency.
2. During one failure state, Windows marked the Ethernet default route as dead, while the router itself returned Destination net unreachable for traffic forced through the Intel interface to public IP addresses.
3. During a separate working-but-degraded state, with the mobile hotspot disconnected and traffic using the Intel I226-V, measured throughput was approximately 94–95 Mb/s down / 36 Mb/s up, despite Windows reporting a 1 Gb/s Ethernet link.
4. Without changing Windows NIC settings, moving the same Ethernet cable from the affected router LAN port to another LAN port immediately restored approximately 302.8 Mb/s down / 35.6 Mb/s up, ping 1 ms.
5. This strongly suggests that the affected Ethernet path or router LAN-port state had become abnormal/stuck, even though the local PC-to-router link still appeared healthy.

A possible mechanism to investigate is whether Codex Desktop's use of WSL/HNS/Hyper-V, sandbox/tool runtimes, or repeated virtual NIC/routing changes can indirectly trigger a problematic host networking state, which in combination with some routers/NICs leaves the physical Ethernet path or router LAN port in a degraded or non-forwarding state.

Observed symptoms

A. Codex reconnect loops

During several heavier Codex tasks, the application displayed repeated reconnect attempts such as:

• Reconnecting 1/5
• Reconnecting 2/5
• ...
• Reconnecting 5/5

In some incidents Codex could not resume until an alternate Internet connection (phone hotspot) was enabled.

B. Ethernet loses Internet while local link remains healthy

During a captured failure state:

• Intel I226-V: Up
• Physical link: 1 Gb/s
• IPv4 address: private LAN address assigned normally
• Default gateway: router LAN address
• PC -> router ping: 20/20 replies, 0% packet loss, <1 ms
• Intel NIC error/discard counters: 0

However:

• Windows marked the default route through the Intel Ethernet adapter as Dead
• Traffic forced through the Intel interface to public IP addresses failed
• The router itself returned Destination net unreachable for public IP targets

This indicates that the failure was above the physical PC-to-router link.

C. DNS failures are real, but appear secondary

Windows DNS Client logs contain multiple Event ID 1014 timeouts across unrelated domains.

Windows troubleshooting also reported that the configured DNS server was not responding.

However, during the captured Ethernet failure, direct traffic to public IP addresses also failed. Therefore DNS failure appears to be a consequence of loss of the Internet path rather than an isolated Cloudflare DNS problem.

D. WSL virtual NIC rebuild observed during the broader incident

On 2026-08-24 at approximately 18:46:23–18:46:24 local time, Hyper-V / virtual switch logs showed a WSL NIC sequence equivalent to:

• disconnect
• initialize
• enable
• connect

and then another similar sequence within about one second.

Important limitation: DNS timeout events were already present roughly 14 minutes earlier, so this single logged WSL NIC rebuild does not prove that WSL initiated that specific incident.

The concern is broader: the user has observed the Ethernet failures repeatedly during Codex activity over a period of weeks, while Codex uses or touches WSL-related infrastructure.

E. Degraded throughput on Intel Ethernet

In one state where the mobile hotspot was disconnected and Internet traffic was confirmed to be using the Intel I226-V:

• Download: approximately 94–95 Mb/s
• Upload: approximately 36 Mb/s
• Intel physical link still reported: 1 Gb/s

This measurement must not be confused with a later audit state in which the Intel adapter was disabled and a phone USB Ethernet interface (100 Mb/s) was active. The 94–95 Mb/s measurement above was made on the Intel Ethernet path with the mobile Internet disconnected.

F. Moving the same cable to another router LAN port restored full speed

No Windows network settings were changed.

The same PC, same Intel I226-V, same driver, same Ethernet cable, same router, and same WAN connection were used.

Only the router LAN port was changed.

Immediately afterward:

• Download: 302.82 Mb/s
• Upload: 35.57 Mb/s
• Ping: 1 ms

This is the strongest A/B result currently available.

It shows that the current Intel configuration is capable of full service throughput and that the earlier ~95 Mb/s result was not a permanent CPU/TCP/driver throughput ceiling.

Windows / Intel configuration found during read-only audit

The NIC and TCP stack are customized.

Known intentional settings

Some settings were deliberately configured earlier during Ethernet troubleshooting and had previously been used with good connectivity:

• Speed & Duplex: 1.0 Gbps Full Duplex
• Energy Efficient Ethernet: Off
• Interrupt Moderation: Disabled
• Selective Suspend / power-saving behavior: Disabled

Therefore the mere fact that these values differ from Intel defaults is not proof that they caused the new failure.

Additional non-default settings found

• Global Task Offload: Disabled
• Registry: DisableTaskOffload=1
• Large Send Offload IPv4: Disabled
• Large Send Offload IPv6: Disabled
• Manual TCP tweaks:
• TcpAckFrequency=1
• TCPNoDelay=1
• TcpDelAckTicks=0
• Npcap filter bound to the Intel interface

The provenance and exact installation time of some of these settings is not established.

A controlled test temporarily disabling the Npcap binding did not improve the ~95 Mb/s result, so Npcap is not currently the leading throughput suspect.

No active Windows Policy-based QoS, system proxy, VPN/TAP/TUN/Wintun, active NetNat, or Hyper-V vms_pp binding on the physical Ethernet interface was found in the read-only audit.

Historical network reset

At an earlier unknown date, Windows Network Troubleshooter suggested a full Network Reset, and the user approved it.

No throughput benchmark was performed immediately after that historical reset, so it cannot currently be ruled in or out as a configuration turning point.

During the current incident Windows again suggested a Network Reset, but it was not executed.

What has been ruled out or weakened

• Physical Intel NIC failure: weakened by 1 Gb/s link, clean error counters, and immediate full-speed recovery after changing router LAN port
• Basic Ethernet cable failure: weakened because the same cable immediately delivered ~303 Mb/s on another LAN port
• Windows Policy-based QoS ~100 Mb/s: not found
• Router QoS rules: disabled / no active limiting rule observed
• Npcap as the direct ~95 Mb/s cause: test did not improve throughput
• Cloudflare DNS as sole cause: public IP traffic also failed during the captured outage
• Permanent Intel driver throughput ceiling: contradicted by ~303 Mb/s on the same current NIC configuration

Current hypotheses to investigate

These are hypotheses, not proven root causes.

1. Codex / WSL / HNS / Hyper-V activity triggers a host networking state change that interacts badly with the Intel I226-V and/or router LAN switching/forwarding state.
2. Router LAN-port state becomes stuck or degraded after some sequence of link/routing changes, causing either:

• loss of Internet forwarding, or
• an effective throughput ceiling near 100 Mb/s,

while Windows may still report a 1 Gb/s physical link.

1. A pre-existing customized Windows networking profile may make the host more sensitive to repeated WSL/HNS virtual network changes.
2. There may be two interacting issues:

• Windows/WSL route/interface instability during Codex activity
• router LAN-port/forwarding state that does not recover cleanly afterward.

Reproduction / observation pattern

A precise automated reproduction is not yet available, but the repeated user-observed pattern is:

1. Ethernet is working normally.
2. Codex Desktop begins a broad/deep local task using multiple tool calls.
3. Codex starts showing reconnect attempts and/or WSL-related virtual networking activity occurs.
4. Physical Ethernet Internet connectivity becomes unstable or disappears.
5. Local PC-to-router connectivity may remain healthy.
6. Windows may mark the Ethernet Internet route as dead.
7. Switching to a phone hotspot provides a working alternate route.
8. In one degraded state, Intel Ethernet delivered only ~95 Mb/s despite a 1 Gb/s reported link.
9. Moving the same cable to another LAN port restored ~303 Mb/s immediately.

Expected behavior

Codex Desktop should not alter, destabilize, or leave persistent side effects in the host's physical Ethernet connectivity, routing, virtual networking stack, or router-facing link state.

WSL/HNS/Hyper-V resources created or touched by Codex should be isolated and cleaned up after tool/runtime operations.

A native Windows Ethernet path that is healthy before Codex activity should remain healthy after Codex activity.

Actual behavior

Repeated Codex sessions correlate with:

• reconnect loops,
• WSL virtual NIC rebuild activity,
• host Ethernet Internet loss,
• dead default route states,
• DNS timeouts as a secondary effect,
• and at least one case of ~95 Mb/s throughput on a 1 Gb/s Intel link.

Changing only the router LAN port restored full ~303/35 Mb/s service.

Requested investigation by the Codex team

Please investigate whether Codex Desktop on Windows can:

• start or interact with WSL even in workflows that are primarily Windows-native,
• repeatedly create/rebuild HNS/Hyper-V networking resources during tool calls,
• alter route/interface state or metrics,
• leave stale virtual networking state,
• trigger physical NIC reset/rebind behavior,
• or indirectly cause host/router Ethernet state changes after repeated tool/runtime activity.

It would also be useful to confirm what Codex Desktop expects to create, modify, and clean up in:

• WSL
• HNS
• Hyper-V virtual switches
• virtual Ethernet adapters
• routing tables
• DNS/interface state
• Windows filtering/binding layers

Related public Codex reports

These reports are not identical to this issue, but show related Windows/WSL/connectivity behavior:

• #38957 — Windows Codex Desktop reconnects 1/5–5/5 on every prompt

https://github.com/openai/codex/issues/38957

• #37992 — Windows Codex Desktop repeatedly reconnects / stream disconnects while CLI works

https://github.com/openai/codex/issues/37992

• #30040 — recurring WSL instability correlated with Codex CLI activity

https://github.com/openai/codex/issues/30040

• #30048 — Codex Desktop starts WSL/Ubuntu even when Windows-native mode is selected

https://github.com/openai/codex/issues/30048

• #38079 — Codex Desktop tool calls accumulate WSL service resources even from native Windows workspaces

https://github.com/openai/codex/issues/38079

• #21693 — Codex Desktop Windows/WSL mode reconnecting despite app-server connection

https://github.com/openai/codex/issues/21693

Data available if maintainers request it

Sanitized extracts can be provided for:

• Hyper-V virtual switch event timestamps
• Windows DNS Client Event 1014 timestamps
• Intel I226-V configuration
• route state snapshots
• forced-routing test results
• Intel NIC error/discard counters
• before/after throughput measurements

Raw screenshots and raw logs are not attached to this initial report because they may contain local paths, device names, network identifiers, account/browser information, or other private data.

Privacy / redaction checklist

Removed from this report:

• Windows username
• computer hostname
• public IP address
• MAC addresses
• Wi-Fi SSID
• ISP login / PPPoE credentials
• router administrative password
• local project paths
• personal folder names
• OpenAI account identifiers
• request/thread IDs
• unrelated application data

No credentials are included.