Codex degrades system-wide input latency on Windows 11 (measured ~50x increase in input-delivery stalls)

Related issues. This overlaps #38750, #38711, #38716, #38663, and #38745, which
report the same system-wide stutter on Windows. I'm filing separately because I have
quantified before/after instrumentation of the input pipeline that I couldn't find in
those threads, and it localizes the symptom to input delivery rather than to CPU,
GPU, or driver-level contention. Happy for this to be closed as a duplicate and the
measurements folded into whichever issue is canonical.

What issue are you seeing?

Running Codex degrades mouse and keyboard input across the entire Windows desktop, not
just inside Codex. Killing the Codex process resolves it immediately. Observed three times;
measured once with before/after instrumentation.

The cursor skips and teleports instead of moving smoothly, window drags stutter, and
keyboard input occasionally lags. It affects every application on both monitors.

Measurement. I polled GetCursorPos in a tight loop at highest thread priority,
recording the gap between cursor position updates and the pixel delta of each update. Same
machine, same session, ~3 minutes apart, with Codex the only variable:

Normalized, the stall rate went from 2.80% of movements to 0.055% (~50x) while I was
moving the mouse more in the healthy sample.

The last row is the significant one. The probe's own loop never stalled, and total
system CPU was low throughout (nothing above ~8% of a single core on a 16-thread machine).
The scheduler is healthy while input reports fail to arrive on time, which locates the
problem in input delivery rather than in resource contention.

What steps can reproduce the bug?

Environment

Codex CLI:      0.142.5
Codex desktop:  OpenAI.Codex 26.810.7004.0  (26.810.4967.0 when first observed)
OS:             Windows 11 Home 25H2, build 26200
CPU:            AMD Ryzen 7 7800X3D, 32 GB RAM
Board:          ASRock X870E Nova WiFi, BIOS 4.10
GPU:            NVIDIA RTX 5070 Ti, driver 32.0.16.1088
Displays:       3840x2160 @ 239 Hz + 2560x1440 @ 143 Hz
Input:          Logitech PRO WIRELESS via LIGHTSPEED USB receiver

Steps

1. Start Codex and use it normally.
2. After some period of use, system-wide input choppiness appears.
3. Kill the Codex process — the symptom stops immediately.

I could not find a deterministic trigger. Launching Codex is not sufficient; Codex ran
during symptom-free periods too. The trigger appears to be activity rather than presence,
which is what made this hard to isolate — "it's running now and everything is fine" is
misleading here.

To measure it, poll GetCursorPos in a tight loop while moving the mouse continuously and
record the intervals at which the reported position changes. On a healthy system,
essentially every update lands within 8 ms. While the bug is active, tens of updates per
twelve-second sample exceed 64 ms, and the cursor then jumps to catch up.

What is the expected behavior?

Codex should not affect input latency in other applications. Nothing about its normal
operation should stall the system-wide Win32 input pipeline.

Additional information

Ruled out. Each of these was tested and did not change the behaviour:

• GPU driver — updated 610.62 → 610.88; symptom persisted. No Dxgkrnl/nvlddmkm
  errors in three months.
• AMD chipset drivers — updated I2C, GPIO, PSP; symptom persisted.
• Kernel/DPC latency — DPC time 0.37% avg, interrupt time 0.53%, processor queue
  length 0 while the symptom was active. (This matches the independent finding in #38711.)
• Virtualization software — VirtualBox and VMware fully removed and verified gone
  (drivers, services, registry); symptom recurred afterward.
• Wireless interference — reproduced with a separate wired HID pointing device, so it
  is not 2.4 GHz interference with the Logitech receiver.
• Hardware — no bugchecks, no unexpected shutdowns, healthy SSD.

extension-host.exe orphans itself. When Codex is killed, extension-host.exe from
~/.codex/plugins/cache/openai-bundled/chrome/latest/ survives, along with a cmd.exe
wrapper whose parent is gone. Observed three times. The orphans sit at ~0% CPU, so they
don't appear to be the cause themselves — but they shouldn't outlive their parent.

Disabling the chrome plugin does not stop its host from launching. With

[plugins."chrome@openai-bundled"]
enabled = false

in config.toml, extension-host.exe still spawned ~30 seconds after the session started.
Aside from being a bug on its own, this blocks users from testing whether that plugin is
involved. (#37672 reports the same enabled = false behaviour.)

Happy to run further instrumentation, capture an ETW trace, or test a build.

Start by reproducing the Windows input-delivery stalls with the supplied GetCursorPos probe and compare results while Codex is active and after it is killed. Inspect the extension-host.exe process under ~/.codex/plugins/cache/openai-bundled/chrome/latest/ and the enabled setting in config.toml, then use an ETW trace if available. Done means the responsible Codex activity is identified and system-wide input latency no longer degrades.