Codex Windows 26.810.4967 idle main-process CPU busy loop in Chrome plugin app-server hashing #38547

Summary

Codex for Windows 26.810.4967.0 enters a persistent Electron main-process CPU busy loop while completely idle. The regression started immediately after the app updated from 26.803.10989.0 to 26.810.4967.0 on 2026-08-14.

This does not require opening or using the in-app Browser. Closing Codex restores normal system responsiveness, but quitting is not an acceptable recovery while local tasks are running.

Symptoms

• Mouse movement becomes visibly discontinuous.
• Typing in Codex has noticeable input latency.
• The Electron main process continuously uses about 140–150% of one CPU core while the app is idle.
• The background codex.exe task service remains near idle (about 0.6%), and GPU use is only about 0.3–1%.
• Toggling the pet visible and hidden can temporarily improve mouse motion, but does not stop the CPU loop or typing lag.

Reproduction

1. Start Codex for Windows 26.810.4967.0.
2. Do not open the in-app Browser and do not start any new work.
3. Leave the app idle.
4. Observe sustained main-process CPU around 140–150% and system/input stutter.
5. Fully quit Codex; responsiveness immediately returns.

Built-in performance trace evidence

A roughly 15-second trace recorded with Codex's Help → Start performance tracing contained 3,971,851 events.

• Electron CrBrowserMain (Chromium's term for the main/browser process, not the in-app Browser feature):
  • ThreadControllerImpl::RunTask: 68,122 events, about 13.00 s thread CPU.
  • RunMicrotasks: 59,220 events, about 11.74 s thread CPU.
• V8 CPU-profile hotspots:
  • update -> update [hash] -> XK [src-BlUt09P1.js]: about 7.55 s.
  • createUnsafeArrayBuffer -> createUnsafeBuffer -> allocUnsafeSlow -> readFileHandle [promises]: about 6.44 s.
• Three V8 workers spent about 7.77 s of thread CPU in V8.GC_BACKGROUND_FULL_ARRAY_BUFFER_SWEEP.

Trace metadata (raw trace is not attached because it is 701,105,313 bytes):

• SHA-256: 82C2B7A19C3DB9537E834ADA7AF1D2285B70E3C362998339C7A426E7489EDA79

Suspected root cause in the packaged bundle

The packaged src-BlUt09P1.js identifies the hot function as the file-equivalence check in chrome-plugin-app-server-runtime:

async function XK(path) {
  return createHash("sha256")
    .update(await fs.promises.readFile(path))
    .digest("hex");
}

The caller recursively compares the source and destination copies of the plugin app-server runtime. The compared set includes approximately:

• codex.exe: 295 MB
• codex-code-mode-host.exe: 59 MB
• two Windows helpers: 10 MB combined

Reading and hashing both sides creates roughly 729 MB of transient buffers per full comparison. In the affected build, this check appears to repeat or overlap continuously while idle, producing the microtask storm, ArrayBuffer GC, CPU use, and input stutter.

The module name refers to Codex's background Chrome/plugin native-host runtime. It does not mean the in-app Browser page is required to trigger the bug.

Other checks

• Recreating the main chat renderer does not stop the loop.
• Ending Browser renderer/helper processes does not stop it.
• Lowering the main-process priority does not produce a perceptible improvement.
• A clean restart without using the in-app Browser still reproduces the issue.

Expected behavior

The Electron main process should remain near idle when Codex is idle. Resource synchronization should not repeatedly read and SHA-256 hash hundreds of megabytes, and recovery should not require quitting Codex while tasks are running.