[Windows desktop] Chrome native host retry loop consumes a CPU core and causes input lag

I maintain WinBridge Recovery, an independent Windows recovery tool for Codex Desktop plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

This report is a high-confidence match for one of the local layers WinBridge is intended to diagnose: the bundled Chrome plugin / native-host reconciliation path after a Desktop update. In particular, it can check whether the locally installed official package, the openai-bundled/chrome cache/version/latest state, Chrome Native Host manifest/registry/v2 state, and related runtime paths have drifted or were only partially staged, then rebuild the user-side state from the official package when that is possible.

The important limitation here is the exact log message: Missing bundled Electron runtime required to sync Chrome native host resources. If the current MSIX package itself genuinely does not contain (or no longer exposes) the runtime that the new Desktop code expects, that is an upstream packaging/runtime lookup bug. WinBridge does not patch or take ownership of C:\Program Files\WindowsApps, does not redistribute official runtime files, and cannot guarantee a permanent fix for a package-level omission. What it can do is distinguish that case from stale local cache/latest/Native Host state and recover the latter without modifying WindowsApps.

The repeated 0.3–0.5s reconcile loop is also an upstream behavior issue even if the local state is repairable; a bounded backoff/fail-closed path still needs to be fixed in Codex itself.

Independent ETW reproduction confirms the same retry loop on another Windows system and adds process-level evidence.

Environment

• Codex Windows MSIX: OpenAI.Codex 26.810.4967.0
• Windows 11 Pro Insider Preview, Dev build 29639, x64
• 12 cores / 24 logical processors
• The stutter is continuous while Codex is running.
• Computer Use was not invoked, and codex-computer-use.exe was not present during the capture.

WPR / ETW evidence

A requested 75-second WPR GeneralProfile capture was recorded while the system-wide stutter was visible. The resulting ETW timeline, including recorder startup/stop overhead, covered approximately 87.9 seconds.

During that interval, the Codex main process ChatGPT.exe created 143 instances of reg.exe. Every instance used the same command:

reg add HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension /ve /t REG_SZ /d %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json /f

Verified properties:

• Parent of all 143 reg.exe instances: the Codex main ChatGPT.exe process.
• First launch: trace time 0.343 s.
• Last launch: trace time 87.924 s.
• Median interval: 0.599 s.
• Mean interval: 0.617 s.
• Minimum / maximum interval: 0.484 / 0.799 s.
• The same capture recorded 149 newly created conhost.exe processes.
• ETW reported lost events, so these process counts should be treated as lower bounds.

Main-process CPU

The hot main-process thread was CrBrowserMain:

• 68.97 CPU seconds during the trace.
• 54.01 CPU seconds attributed to chrome.dll.
• Approximately 78% of one logical processor both while Codex was focused and while Explorer / Task Manager had focus.
• All ChatGPT.exe processes accumulated 132.77 CPU seconds during the trace.
• A separate 5-second sample after WPR completed still measured the affected main process at 128.29% of one logical processor (5.35% of total 24-thread capacity).

The machine was not globally CPU-saturated.

Negative evidence

• No codex-computer-use.exe process was present.
• Interrupt/DPC activity did not show a classic latency storm: average interrupt-handling activity was 9.35 microseconds and the maximum was 1.302 milliseconds.
• dwm.exe used 7.23 CPU seconds across the trace and was not the dominant CPU consumer.
• No matching recent Display, NVIDIA, WHEA, or Kernel-Power error was found in the Windows System event log.

Conclusion

This independently confirms that the user-visible system-wide stutter coincides with a sub-second Chrome native-host registration/reconciliation loop in the Codex main process. The loop repeatedly launches reg.exe and conhost.exe and keeps CrBrowserMain hot even when Codex is not focused.

This is distinct from the earlier Computer Use helper trigger reported in #36091, although the external symptom is similar. Please investigate the native-host cache watcher lifecycle, the packaged Electron-runtime lookup, and add bounded exponential backoff or a fail-closed path.

The raw ETL is being withheld because it contains local paths, command lines, process metadata, and other private workstation information. It can be provided through a private secure upload channel if requested.

Independent reproduction on Windows confirms the same Chrome native-host/cache reconcile loop on Codex Desktop 26.810.4967.0.

Environment

• Windows 11 x64
• Codex Desktop MSIX: 26.810.4967.0
• Bundled Chrome plugin: chrome@openai-bundled
• Plugin version: 26.810.41047

WPR / ETW file-I/O evidence

A 29.775-second kernel File I/O trace of the Electron main process recorded:

• 79,914 file-read operations
• 39,617.92 MiB of logical reads
• 1,330.58 MiB/s average logical read rate
• 78,946 reads were exactly 512 KiB
• Four main-process threads each read approximately 9.9 GiB

The dominant targets were repeated reads of matching Codex runtime binaries from:

• %LOCALAPPDATA%\OpenAI\Codex\bin\<build>\
• %USERPROFILE%\.codex\plugins\.plugin-appserver\

The paired runtime files had identical sizes and SHA-256 hashes, so this was not caused by corrupted or mismatched binaries.

During the same 29.775-second trace, the Chrome plugin cache junction:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest

was deleted/replaced 56 times.

Observed interval:

• average: 0.5255 seconds
• median: 0.5171 seconds
• minimum: 0.4645 seconds
• maximum: 0.6664 seconds

The junction pointed to the correct installed plugin version whenever sampled. This appears to be a self-triggering reconciliation/idempotence problem rather than a genuinely missing or corrupt plugin version.

Live measurements before mitigation

A separate five-second sample of the Electron main process showed:

• 1,498.97 MiB/s logical reads
• 3,052.9 read operations/second
• 136.5% of one logical CPU core
• approximately 1.35 GiB private memory

The system was not under general CPU, DPC, interrupt, paging, or physical-memory pressure. The backend, Docker, Defender, indexing, and GPU processes were not the dominant consumers.

Controlled mitigation and retest

Only this configuration was changed:

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

A full Codex Desktop restart was required for the change to take effect.

An 11.17-second post-restart sample showed:

• 0.033 MiB/s logical reads
• 3.4% of one logical CPU core
• approximately 255 MiB private memory
• one stable junction state across 100 consecutive samples
• zero samples where the junction was missing

The in-app Browser plugin remained enabled. Only the external Chrome/native-host integration was disabled.

Conclusion

The system-wide mouse/input stutter coincides with a sub-second self-triggering Chrome cache/native-host reconciliation loop. The loop repeatedly replaces the latest junction and rereads hundreds of megabytes of paired runtime binaries.

Please investigate:

1. Windows path canonicalization and junction-target comparison around latest.
2. Whether cache changes produced by reconciliation are feeding back into the same watcher.
3. Debouncing or coalescing watcher events.
4. Avoiding repeated full-file verification when runtime files are unchanged.
5. Bounded backoff or fail-closed behavior.

This may also explain the persistent main-process read loop reported in #38518, although that issue initially appeared to be triggered by conversation navigation.

No raw ETL, account data, conversation data, credentials, or identifying local paths are included.

I isolated a deterministic root cause for this loop on the same Windows build. This is not a missing runtime or a corrupt plugin cache.

Root cause

In the packaged Desktop app.asar, the bundled-plugin cache builder first converts the Codex home to forward slashes, then constructs the version directory with path.posix.join. On Windows this leaves the expected version path in this form:

C:/Users/<user>/.codex/plugins/cache/openai-bundled/chrome/26.810.41047

The latest verifier resolves the junction target with the platform path.resolve(path.dirname(latestRoot), readlink(latestRoot)), which produces:

C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.810.41047

It then compares the two strings with strict equality. They identify the same Windows path, but the comparison is false solely because one uses / and the other uses \.

In build 26.810.4967.0, the relevant minified cache-builder occurrence is unique in app.asar (around byte offset 6,443,210). The effective logic is:

versionRoot = path.posix.join(forwardSlashCodexHome, "plugins", "cache", ...)
resolvedTarget = path.resolve(path.dirname(latestRoot), readlink(latestRoot))
isCurrent = resolvedTarget === versionRoot

Because isCurrent never becomes true on Windows, every reconcile pass treats the already-correct latest junction as stale, replaces it, triggers the watcher again, and repeats full runtime verification.

Controlled A/B evidence

With the unmodified behavior, a 5-second ETW File I/O capture recorded approximately 21.6 GB of logical reads while the physical disk was idle, plus 210 create, 210 filesystem-control, and 210 delete events involving the Chrome latest junction. The Electron main process used about 1.66 logical CPU cores and the desktop mouse visibly hitched.

I then applied a narrow process-local diagnostic shim that changes only this plugin-cache join from POSIX to Win32 semantics. It made the two paths compare equal. With the Chrome plugin still enabled after restart:

• latest completed its one startup initialization and then retained the same creation identity for at least 109.7 seconds;
• the repeated runtime reads stopped;
• the system-wide input stutter disappeared.

No plugin cache contents, bundled binaries, Chrome registration, or WindowsApps files were changed for this A/B test.

Suggested fix

Use the platform path implementation for local filesystem paths and canonicalize both operands before comparison. For example, build the cache path with path.join, then compare path.resolve(resolvedTarget) with path.resolve(versionRoot) (with the normal Windows case-insensitive treatment if required). Avoid serializing a local Windows cache path through path.posix.join and later comparing it byte-for-byte with a Win32-resolved path.

It would also be useful to retain bounded backoff, but path canonicalization fixes the deterministic trigger rather than merely throttling it.

Additional side-by-side regression evidence: the official Microsoft Store Beta package does not reproduce this issue on the same Windows machine.

Tested configuration

• Stable package exhibiting the bug: OpenAI.Codex 26.810.4967.0
• Side-by-side Beta package: OpenAI.CodexBeta 26.727.4816.0
• External Chrome integration remained installed and enabled.
• The shared Chrome plugin/native-host state was retained, including plugin version 26.810.41047; the Chrome extension was not removed or disabled.

In a simultaneous sampling window with both applications running:

• affected Stable main process: approximately 114.5% of one logical core and 1,180.87 MiB/s logical reads;
• Beta main process: approximately 2.3% of one logical core and 0.01 MiB/s logical reads.

I then closed Stable and exercised the Beta build through the real external Chrome extension/native host: create a temporary tab, navigate, read the DOM, follow a link, go back, reload, and close the tab. All operations completed successfully.

During a 16.6-second sample covering Chrome activity, the entire Beta process tree averaged 2.39 MiB/s logical reads with a 4.36 MiB/s peak. A later post-operation 15-second sample averaged 4.52 MiB/s, with a 19.08 MiB/s peak. The native host settled at 0% CPU / 0 MiB/s after the operation.

Across all three Beta desktop logs created during the test:

• chrome_native_host_cache_reconcile_failed: 0 occurrences
• chrome-native-host-cache-watcher: 0 occurrences

The system-wide mouse/input stutter was not observed while using the Beta build.

Because 26.727.4816.0 is an older Beta-channel package, this is not evidence that a newer release already contains a fix. It does provide a useful regression boundary and a side-by-side workaround that preserves external Chrome integration. The result is also consistent with the Windows path-normalization/string-comparison root cause described in the latest comment.

Was able to reproduce this.

• Codex MSIX: 26.810.4967.0
• Bundled Chrome plugin: 26.810.41047
• OS: Windows 11 x64

Codex repeatedly thinks its bundled Chrome integration needs refreshing, each refresh reading hundreds of MB from disk. Disabling Chrome integration manually didn't disable the background cache-maintenance code.

The src-BlUt09P1.js function responsible for maintaining the Chrome plugin’s latest junction constructs versionRoot using slash/posix normalisation, it calls readlink(latestRoot) and path.resolve(), which produce a Windows backslash path, and then compares the two strings using strict equality.

So they identify the same directory but differ textually. E.g.:

• C:/.../chrome/26.810.41047
• C:\...\chrome\26.810.41047

So the comparison fails every time. Codex the deletes and recreates the unchanged latest junction whose target was already correct.

Before reaching that comparison reconciliation recursively verifies the Chrome app-server runtime using full SHA-256 reads (zK → GK → JK → XK), including codex-resources. The junction mutation then retriggers the cache watcher.

Affected state:

• Main-process CPU: approximately 127–165%
• Logical reads: approximately 396–529 MiB/s
• latest deleted/recreated approximately every 1.8s
• Defender, WMI, GPU and the backend codex.exe were not dominant

Causal A/B:

• Temporarily denying only Delete on the latest junction stopped reconciliation.
• Junction events: 0
• Main-process CPU: 0.39% mean
• Logical reads: 0.03 MiB/s mean
• Removing the deny rule restarted the loop; reapplying it stopped the loop again.
• No package or cache files were altered.

The ACL test is diagnostic/session mitigation, not a proposed product workaround: it intentionally causes one EPERM during reconciliation.

Suggested fix

• Canonicalise both paths before comparison—preferably realpath() plus Windows-aware normalisation/case handling.
• Do not perform whole-runtime hashing when stable metadata already proves that reconciliation is unnecessary.
• Add bounded backoff/coalescing so a failed reconciliation cannot become a tight watcher loop.
• Ensure disabling the Chrome plugin also disables this native-host cache reconciliation path.

This appears to provide the missing concrete explanation for the path-canonicalisation hypothesis already raised here and for the hashing mechanism reported in #38547.

Additional independent reproduction with a completed pre/post mitigation A/B on Windows.

Environment

• Windows 11 x64
• Codex Desktop MSIX: OpenAI.Codex 26.810.4967.0
• Bundled Chrome plugin: chrome@openai-bundled 26.810.41047

User-visible impact

The entire desktop developed severe mouse and keyboard stutter while Codex remained open. Task Manager showed the main ChatGPT/Codex process at Very high power usage. Fully exiting the app immediately restored responsiveness, but relaunching without changing configuration only made the problem disappear temporarily.

Measurements while affected

A 10-second live delta on the Electron main ChatGPT.exe process showed:

• 1,029.4 MB/s logical reads
• 2,268 read operations/s
• 136.4% of one logical CPU core
• Other ChatGPT/Codex processes combined: <1 MB/s
• GPU process: approximately 2–4% CPU

At the same time, the junction

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest

was not merely receiving timestamp updates: its creation identity/FileId changed repeatedly while its target remained the same 26.810.41047 directory. In a per-second sample, the junction was deleted and recreated every second. The target contained only 378 files / 8.62 MB, while the main process produced approximately 10.4 GB of logical reads in 10 seconds, consistent with repeated verification/hashing of the same small tree.

No corresponding GPU reset/TDR, DPC/interrupt storm, or system-wide CPU saturation was present.

Controlled mitigation and restart behavior

Only this setting was changed:

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

The running process did not hot-reload the setting: before a full exit, it continued at approximately 1,010–1,030 MB/s and the junction kept cycling.

After a full exit and relaunch:

• New main-process 15-second sample: 0.030 MB/s, 2.4% of one logical core
• Later 15-second sample: 0.012 MB/s, 1.0% of one logical core
• Junction state: stable, zero creation-time changes
• Task Manager power usage returned to normal
• System-wide mouse/keyboard stutter disappeared

browser@openai-bundled remained enabled; only the external Chrome/native-host integration was disabled.

This is a strong local causal A/B match for the Windows path-normalization/cache-reconciliation findings already reported here. Please prioritize a Windows-aware canonical path comparison and ensure the watcher has bounded backoff/fail-closed behavior so this loop cannot degrade system-wide input.

Raw local logs are not attached because they contain workstation paths and task metadata, but the summarized measurements above were taken live before and after the single configuration change.

Independent reproduction on a newer Windows stable package confirms that this issue is still present in 26.810.6296.0.

Environment

• Windows 11 Pro x64, build 26200
• Codex Desktop MSIX: OpenAI.Codex 26.810.6296.0
• Bundled Chrome plugin target: chrome@openai-bundled 26.810.50856

Measurements while affected

A five-second live sample of the Electron main ChatGPT.exe process showed:

• 1,042.9 MiB/s logical reads
• 156.8% of one logical CPU core
• approximately 1,012 MiB private memory
• writes were only about 57.5 KiB/s

A Process Monitor trace showed the main process repeatedly reading:

%LOCALAPPDATA%\OpenAI\Codex\bin\<build>\codex.exe

The file was 281.48 MiB. During a 4.17-second capture, the process issued 2,522 reads totaling 1,260.92 MiB, with five separate reads starting at offset zero. The same trace showed the parent ChatGPT.exe repeatedly launching:

reg add HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension /ve /t REG_SZ /d %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json /f

The registry command occurred roughly once per second. Physical disk throughput was much lower than the logical-read counter, consistent with repeated hashing/verification of cached runtime bytes.

This matches the path-normalization/cache-reconciliation loop already identified in this issue.

Controlled mitigation

Only the external Chrome integration was disabled:

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

After a full Codex Desktop exit and restart, a new five-second sample showed:

• 0 MiB/s logical reads
• 1.4% of one logical CPU core
• approximately 262 MiB private memory

The in-app browser@openai-bundled plugin remained enabled. No registry, junction, package, or WindowsApps files were modified.

This confirms both that the regression persists in 26.810.6296.0 and that disabling only chrome@openai-bundled plus a full restart is an effective workaround on this machine.

Independent confirmation on the current Windows package installed on this machine.

Environment

• Windows 11 x64
• OpenAI.Codex MSIX: 26.810.6296.0
• 20 logical processors
• Bundled Chrome plugin target: chrome@openai-bundled 26.810.50856
• External Chrome integration was enabled in config at capture time

Live process sample

An 8-second read-only sample while the fault was active showed:

• Electron main ChatGPT.exe: 7.27% of whole-machine CPU, equivalent to approximately 145% of one logical core
• Main-process logical reads: 1,068,365 KiB/s, approximately 1,043 MiB/s
• Main-process logical writes: 22.5 KiB/s
• Main-process working set: approximately 674 MiB
• The renderer, GPU child, and bundled codex.exe were substantially lower
• Task Manager showed only about 0.2 MiB/s physical disk activity

This rules out continuous log writing as the main cause. The high read rate is logical/cache-backed I/O rather than physical disk saturation.

Reconciliation-loop evidence

A read-only watch of the Chrome plugin latest junction observed 10 distinct creation timestamps in approximately six seconds. The junction target remained unchanged and correct for every sample:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.810.50856

The compared runtime files existed on both sides with identical sizes:

• codex.exe: 281.48 MiB
• codex-code-mode-host.exe: 56.60 MiB

The Chrome plugin was configured as enabled. No application, plugin, registry, junction, or cache files were modified during this diagnostic capture.

User impact and interpretation

While this loop is active, the mouse visibly stutters across Windows and input feels delayed. Fully exiting the ChatGPT/Codex process tree restores responsiveness.

The CPU, logical-read rate, low physical-disk rate, and repeated recreation of an unchanged junction independently match the hashing/cache-reconciliation loop described in this issue and #38547, as well as the input-lag symptoms in #38551.

The suggested chrome@openai-bundled disable-and-restart mitigation had not yet been applied at the time of capture, so the figures above are clean pre-mitigation evidence. No account identifiers, task contents, session IDs, complete user paths, logs, or transcripts are included.

Follow-up A/B result from the same machine after applying only the suggested mitigation:

• plugins."chrome@openai-bundled".enabled = false
• plugins."browser@openai-bundled".enabled remained true
• The desktop app was then fully exited and restarted
• No cache, junction, registry, package, runtime, or log files were manually modified

Post-restart sample 1

An 8-second sample showed:

• Electron main ChatGPT.exe: 0.31% whole-machine CPU, approximately 6.2% of one logical core
• Logical reads: 0.06 MiB/s
• Main-process working set: approximately 435 MiB
• Main-process private memory: approximately 349 MiB

Post-restart confirmation sample

A second 8-second sample showed:

• Electron main ChatGPT.exe: 0.078% whole-machine CPU, approximately 1.6% of one logical core
• Logical reads: 0.045 MiB/s
• Logical writes: approximately 125 KiB/s
• Main-process working set: approximately 430 MiB
• Main-process private memory: approximately 343 MiB

During the same confirmation window, the Chrome plugin latest junction was checked 24 times over approximately six seconds:

• Distinct creation timestamps: 1
• Observed replacements: 0
• Distinct targets: 1

Before versus after

Before disabling the external Chrome integration:

• Main-process CPU: 7.27% whole-machine, approximately 145% of one logical core
• Logical reads: approximately 1,043 MiB/s
• The unchanged latest junction produced 10 distinct creation timestamps in approximately six seconds

After disabling it and fully restarting:

• Main-process CPU settled to 0.078% whole-machine
• Logical reads settled to 0.045 MiB/s
• The junction remained stable with zero replacements

This is a clean same-machine A/B confirmation that disabling only chrome@openai-bundled stops the repeated runtime hashing/junction-reconciliation loop on OpenAI.Codex 26.810.6296.0. The in-app Browser plugin remains enabled and functional.

thank you for your reports, we believe we've addressed this in 26.810.7004.0. try that version and send a fresh feedback if it persists!

Independent same-process A/B confirmation from another affected Windows system.

Environment

• Windows 11 x64
• OpenAI Codex Desktop: 26.810.4967.0
• External Chrome integration was installed when the fault occurred

User-visible symptom

After Codex had been running for approximately 60 minutes, mouse and touchpad movement became visibly discontinuous across both displays. Dragged windows followed the same stuttering motion.

Video playback and normal animations remained smooth, and the pointer was smooth on the Ctrl+Alt+Delete secure desktop. Restarting Codex temporarily cleared the symptom, but it returned after continued use.

Captured measurements

During the affected period, the same Electron main ChatGPT.exe process showed:

• Average CPU: 133.808% of one logical core
• Peak CPU: 326.851%
• Average logical read rate: 1128.597 MB/s
• Peak logical read rate: 3169.104 MB/s

Writes remained low, and logs_2.sqlite was not undergoing sustained high-frequency growth. The observed reads were therefore consistent with cache-backed runtime verification rather than physical disk saturation.

Controlled mitigation without restarting Codex

The external Chrome integration plugin was uninstalled while Codex remained running.

The same process then dropped to:

• 10-second average CPU: 4.653%
• 10-second average logical reads: 0.506 MB/s
• 10-second peak CPU: 28.020%
• 10-second peak logical reads: 4.163 MB/s

Mouse responsiveness returned immediately. There was no Codex restart between the affected and recovered measurements.

This provides an independent same-process causal A/B match for the repeated Chrome runtime hashing/cache-reconciliation loop described in this issue and #38547.

The built-in Browser remains usable and is not implicated. I rely on the external Chrome integration for authenticated Chrome sessions and would like to reinstall it once the fixed build is available.

I am currently on 26.810.4967.0. Please confirm whether upgrading to 26.810.7004.0 or later is sufficient before reinstalling chrome@openai-bundled. If the issue persists after upgrading and reinstalling, I can provide a fresh sanitized feedback/session ID and new post-fix measurements.

No raw logs, local paths, account identifiers, conversation contents, or session transcripts are included in this report.

@chess-oai I confirm that 26.810.7004.0 fixes it, thx :)

@EDM115 where can I download the newest version?

@derekhe Fully quit the ChatGPT app, including from the system tray (and make sure no ChatGPT processes remain in Task Manager), wait a few seconds, then launch it again. It should download and install the update automatically. After reopening, check that the version is 26.810.7004.0 or newer.