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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #38510
• #38529
• #38518

Powered by Codex Action

Additional independent reproduction from another Windows 11 system on 2026-08-14.

• Microsoft Store MSIX updated from 26.803.10989.0 to 26.810.4967.0 earlier the same day.
• System-wide mouse cursor stutter began only after that update and recurred after a Windows reboot while Codex remained running.
• During an affected live sample, the Codex/ChatGPT main process peaked at about 15.2% of whole-machine CPU on a 16-logical-processor system; a subsequent 5-second sample averaged about 8%.
• The app process family was using roughly 4 GB working set. The GPU process briefly reached about 43% engine utilization.
• Disk queue/activity was effectively zero, interrupt/DPC CPU was zero in the sample, about 4.75 GB RAM remained available, and no corresponding display, disk, or application-hang event appeared at symptom onset.
• Other active local services were measured and were not the dominant CPU consumer.
• Codex was intentionally not fully quit because other active tasks were still running.

This corroborates the version boundary, user-visible stutter, and process-level resource pattern. It does not independently distinguish the repeated hashing mechanism described here from the native-host reconciliation loop in #38510, so I am not claiming a root-cause attribution from this sample alone. Raw logs are not attached because they contain local paths and task metadata.

Independent reproduction on Windows 11 after updating Codex from 26.803.10989.0 to 26.810.4967.0.

Hardware:

• AMD Ryzen 9 5900X, 24 logical processors
• 64 GB RAM
• NVIDIA RTX 4070 Ti SUPER
• Windows 11 Pro, build 26200

Observed during the stuttering:

• Codex Electron main process: approximately 131–155% of one logical CPU core
• Codex backend: approximately 20%
• All renderers combined: approximately 5%
• Codex GPU utilization: approximately 0%, maximum observed 0.22%
• No meaningful disk queue, DPC/interrupt load, memory pressure, GPU-driver reset or WHEA error

Controlled behavior:

• Codex fully closed: Windows, mouse, taskbar and browsers are smooth
• Codex running: system-wide input and scrolling stutter returns after some time
• Fully exiting Codex restores responsiveness

Feedback/session ID: 019fff71-b6c5-7b31-844c-e5a35d6b9204

It is really bad, please help.

I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop local plugin/runtime state.

This trace is useful because it gives a clean boundary for what a local recovery tool can and cannot address. WinBridge can compare the currently installed AppX resources with the user-side Chrome plugin/app-server cache, versioned directories, latest, Native Host state, and hashes. If those layers are stale or version-split, it can rebuild the user-owned state from the already installed official package with staging, verification and rollback.

But if the source and destination resources are already current and byte-identical and chrome-plugin-app-server-runtime still re-reads/hashes hundreds of MB in a tight loop, that is an upstream lifecycle/reconciliation bug rather than something WinBridge should try to "fix" by repeatedly rewriting files.

So for this issue I would mainly use WinBridge as a control: first rule out package/cache/version drift; if the state is healthy and the hashing loop persists, stop local repair and treat the 26.810 reconciliation loop as the actual bug. The project does not patch the app bundle or disable product security checks.

Independent reproduction on another Windows system with the same affected build.

Environment

• Codex Windows MSIX: OpenAI.Codex 26.810.4967.0
• Desktop executable version: ChatGPT.exe 151.0.7922.137
• Windows x64, build 26200.9168
• 12 logical processors
• Reproduced on 2026-08-14

User impact

• Mouse movement across Windows becomes visibly choppy.
• Typing inside Codex becomes severely delayed and at times nearly unusable.
• A full quit and relaunch reproduced the same symptoms and CPU load.
• Switching to a separate, unrelated idle task did not stop the load.

Controlled measurements

The high-CPU process was identified as the Electron main ChatGPT.exe process (the process launched by Explorer that owns the renderer, GPU, and utility children).

• 60-second sample while no tool or assistant work was executing:
• average: 121.1% of one logical CPU core
• minimum: 106.2%
• maximum: 139.1%
• all 60/60 one-second samples were at or above one full core
• Immediately after the full relaunch, an 8-second sample averaged 121.9%.
• After switching to an unrelated idle task, a 10-second sample averaged 118.3%.
• After returning to the original task, a 7-second sample averaged 118.5%.
• Main-process working set varied roughly between 550–690 MB during the longer captures.

During the same process-level capture:

• the bundled codex.exe backend was approximately idle
• the GPU child used about 10.2% of one core
• the busiest renderer used about 7.2% of one core
• WMI Provider Host, Microsoft Defender, and Git were near idle

This independently corroborates an app-global main-process busy loop in 26.810.4967.0, rather than load from one conversation, active tool execution, the Codex backend, or the GPU process.

I did not capture the built-in performance trace, so I cannot independently confirm the hashing/reconciliation root cause described in this issue. No raw logs, local paths, account details, process IDs, or conversation/task IDs are included here.

Two-machine confirmation with live cache-junction and file-I/O evidence

Adding an independent two-machine reproduction from August 14, 2026.

Version boundary

• Machine A was automatically updated from OpenAI.Codex 26.803.10989.0 to 26.810.4967.0. Its bundled chrome@openai-bundled plugin version is 26.810.41047.
• Machine B reports internal release 26.810.41047 and independently developed the same progressive, system-wide mouse lag.
• On Machine A, two different wired mice exhibited the same symptom. A Windows reboot temporarily cleared it, but the lag returned after Codex had been running for a while.

User impact

The pointer initially pauses and resumes, then progressively worsens until mouse clicks no longer register. The affected user is currently limited to keyboard control and has previously had to shut Windows down from the keyboard.

Machine A live measurements during the affected state

• Electron main ChatGPT.exe: 134.38% of one logical CPU core over 8 seconds.
• Hottest main-process thread: 91.02% of one core.
• Main-process logical reads over 5 seconds: 417.34 MiB/s and 875.4 read operations/s.
• Logical writes: only 0.08 MiB/s.
• The Chrome plugin latest junction pointed to the correct installed version for every sample, but its creation timestamp changed three times during a five-second watch. The target did not change.
• Processor queue length: 0.
• Average DPC time: 0.529%; average interrupt time: 0.265%.
• Average physical-disk queue: 0.004.
• Both mouse devices reported OK / CM_PROB_NONE.
• No corresponding USB/HID reset, display failure, WHEA error, or ChatGPT.exe application-hang event was present.
• Recent desktop logs contained only isolated Chrome native-host registration failures, so a high-frequency warning is not required for the read/hash and junction-replacement loop to be active.

Interpretation

This independently matches the hashing/reconciliation mechanism described here and the Windows path/junction findings in #38510:

1. the junction already targets the correct 26.810.41047 directory;
2. it is nevertheless repeatedly replaced;
3. the main process rereads hundreds of MiB/s while the physical disk remains effectively idle;
4. input across Windows becomes severely degraded.

The same symptom on two separate Windows machines running the same internal payload, plus two different mice on Machine A, strongly argues against mouse hardware or a single USB controller as the primary cause.

No raw logs, machine names, IP addresses, account details, local paths, or conversation/task identifiers are included.

Independent corroboration from another Windows 11 system running the exact build 26.810.4967.0.

My strongest symptoms appeared while a long Codex task was working rather than while Codex was completely idle, but the boundary is the same: Codex starts acceptably, then the machine and Codex surface become sluggish; fully closing Codex restores normal responsiveness, and restarting it helps temporarily.

At one sample, Windows Task Manager showed the ChatGPT/Codex process group at approximately 2.6 GB and 34.6% CPU while total system CPU was approximately 88%. Individual Codex children included codex.exe at approximately 929 MB and another Codex process at approximately 762 MB. I also saw unusually frequent automatic context compaction in tasks that appeared new in the UI.

Luna Max had been stable for me throughout August, and a separate OneDrive memory spike was reduced by restarting OneDrive; the slowdown returned specifically with Codex active. I have not attached private logs, paths, account details, or conversation data.

Please link this with #38551 as an independent report of the same 26.810.4967.0 regression, while keeping the trigger difference (active long task versus idle loop) in mind.

Confirmed independently on Windows with Codex package OpenAI.Codex 26.810.4967.0.

Symptoms: while Codex was running, the entire Windows desktop became less responsive and the system mouse cursor visibly stuttered/jerked. The issue was reproducible enough to make the machine feel generally sluggish during Codex use.

I rolled back exactly one release to 26.803.10989.0 (MSIX package) and the stutter disappeared completely. No other system changes were made between the affected and working state.

So for this machine:

• BAD: 26.810.4967.0
• GOOD: 26.803.10989.0
• Workaround: rollback to 26.803.10989.0

This strongly suggests a regression introduced in 26.810.4967.0 rather than a general Windows/driver issue.

Independent Windows reproduction with File I/O attribution and Chrome-extension A/B control

I reproduced the same regression independently on another Windows system.

Environment

• Codex MSIX: OpenAI.Codex 26.810.4967.0
• Internal desktop/plugin payload: 26.810.41047
• Desktop Chromium executable: 151.0.7922.137
• ChatGPT Chrome extension: 1.2.27259.19709
• Windows x64 build: 26200.9168
• 12 logical processors

Faulted state

The Electron main ChatGPT.exe process, rather than codex.exe, a renderer, or the GPU child, was responsible for the sustained load:

• about 137–145% of one logical CPU core (11.4–12.1% of the whole machine)
• typically 500–1000 MiB/s of logical reads, with a measured peak around 1.21 GB/s
• approximately 104,000 page faults/s
• negligible writes
• working set/private bytes oscillating by hundreds of MiB

DPC/interrupt load, physical-disk queue, available RAM, GPU load, mouse-device status, and relevant Windows hardware/driver event logs did not indicate a competing bottleneck.

A File I/O trace attributed the repeated reads to whole-file comparisons between the versioned Chrome/plugin app-server runtime under:

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

The packaged chrome-plugin-app-server-runtime path checks equal file sizes and then calculates SHA-256 by reading each entire file with fs.promises.readFile. In the faulted state, that source/destination equivalence check repeated continuously.

Chrome-extension control

Disabling the ChatGPT Chrome extension while the fault was already active removed extension-host.exe, but did not cancel the loop in the existing desktop main process. During the following 40.7-second observation:

• extension host remained absent
• main-process CPU averaged 124.4% of one core
• main-process reads averaged about 760 MiB/s (range approximately 328 MiB/s–1.21 GB/s)

After fully quitting Codex from the system tray—not merely closing its window—and relaunching it with the Chrome extension still disabled:

• main-process CPU averaged 4.2% of one core
• reads averaged 0.03 MiB/s and peaked at 0.24 MiB/s
• no extension host appeared
• the system-wide mouse stutter was gone

This suggests that disabling the extension prevents the integration from retriggering the faulty state, but does not stop a reconciliation/hash loop already latched in the running Electron main process.

Foreground-priority observation

While the loop continued unchanged, focusing System Informer made pointer motion appear smooth; switching back to the desktop or a normal-priority application made the stutter visible again. System Informer was running at High priority while ChatGPT.exe remained Normal priority. This only masked the symptom—the CPU/read loop continued—and may explain reports where Task Manager or other elevated/high-priority tools appear smooth.

No raw logs, trace files, usernames, task/conversation identifiers, account details, or unsanitized local paths are included.

Independent reproduction: ~333k page faults/s and working-set oscillation

Confirmed on another Windows system with the exact affected build.

Environment

• Codex Windows MSIX: OpenAI.Codex 26.810.4967.0
• Windows 11 Pro, build 28000
• AMD Ryzen 9 9900X, 12 cores / 24 logical processors
• 30.8 GB RAM
• Reproduced on 2026-08-14

30-second live sample while Codex was idle

The affected process was the Electron main ChatGPT.exe, not the bundled codex.exe app-server.

• Mean main-process page-fault rate: 333,005 faults/s
• Observed range: approximately 252k–508k faults/s, with one brief quiet sample at 24 faults/s before the loop resumed
• Mean system cache-fault rate: 308,355 faults/s
• Main-process CPU: approximately 1.1–2.2 logical cores
• Working set oscillated between approximately 613 MB and 1,018 MB on a roughly 10-second cycle
• Handles increased from 1,775 to 2,265 in 30 seconds
• Threads increased from 56 to 73 in 30 seconds

The next busiest processes were only around 1.5k–2k faults/s. The bundled codex.exe app-server measured about 102 faults/s and the busiest renderer about 56 faults/s in the same comparison.

System-level correlation

While the loop was active:

• System cache faults reached approximately 242k–460k/s
• Interrupts reached up to approximately 44.7k/s
• DPCs queued reached up to approximately 4.25k/s
• Available RAM moved by as much as approximately 526 MB per 2-second interval
• Mouse movement visibly stuttered

With Codex fully closed:

• System cache faults fell to 0–114/s (mean approximately 32/s)
• Interrupts returned to approximately 13.3k/s
• Available RAM movement fell to approximately 40 MB per 2-second interval

Closing and reopening Codex reproduced this A/B transition twice.

Controls

• Approximately 14 GB RAM remained available; commit was 47–49%
• Hard faults were approximately zero
• Physical disk queue was zero and disk time approximately 1%
• GPU was idle/downclocked
• The behavior reproduced with browsers and IDEs closed
• The storm persisted with no active Codex task

This independently corroborates the main-process repeated-read/hash and ArrayBuffer-GC mechanism described in this issue: the hundreds-of-MB working-set sawtooth and very high soft-fault rate match repeated whole-file reads much better than a monotonic memory leak.

The system counters establish correlation with the input stutter; they do not by themselves prove that TLB shootdowns are the direct cause.

Measurement method

Windows formatted performance counters queried through CIM:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory
Get-CimInstance Win32_PerfFormattedData_Counters_ProcessorInformation

No raw logs, local paths, account details, or conversation/task identifiers are included.

I can independently reproduce this on Windows 11 25H2 with Codex Desktop 26.810.4967.0. Chrome itself was not running.

During a 20-second affected-state sample, ChatGPT.exe averaged approximately 132% CPU, 1.20 GB/s of reads, and 257,000 page faults per second. A Process Monitor capture shows repeated full-file reads of both the main Codex runtime and the .plugin-appserver copies, including codex.exe and codex-code-mode-host.exe.

As a controlled workaround, I set:

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

After fully quitting and reopening Codex, the sustained activity and system-wide mouse stutter stopped during continued Codex use. Restarting by itself had previously provided only temporary relief.

I can provide sanitized Process Monitor PML/CSV files, the 20-second performance-counter capture, relevant desktop-log excerpts, or a built-in performance trace. I can also test a candidate build or diagnostic flag. Please let me know which artifact and upload method would be most useful.

I can reproduce the same system-wide stuttering on Windows 10 with Codex Desktop 26.810.4967.0.

I also tested the suggested workaround:

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

After fully restarting Codex, disabling the bundled Chrome integration does improve the situation: the stuttering takes longer to appear.

However, it does not fix the issue. After using Codex for some time, the system-wide stuttering still returns.

Fully exiting Codex restores normal Windows responsiveness.

This suggests that the Chrome native-host/cache reconciliation loop may be one contributor to the regression, but it does not appear to be the only cause.

Environment:

• Codex Desktop: 26.810.4967.0
• OS: Windows 10

I did not capture the exact CPU/I/O measurements or the precise time-to-reproduction, so I don't want to provide inaccurate numbers.

I encountered the same issue and independently came to the same conclusion before finding this thread.

Microsoft Windows NT 10.0.26200.0 x64, 26.810.50856.

"resources\codex.exe" (281.5MB) is getting hashed repeatedly at 300MB/s+ by the built-in electron browser, causes significant input lag in Windows due to the mouse events not getting pumped quick enough.

AI:

Relocation validation runs
        ↓
readFileSync loads all 281.5 MiB of codex.exe
        ↓
Hash.update synchronously computes SHA-256
        ↓
Browser main thread cannot pump Windows messages
        ↓
WM_MOUSEMOVE remains unserviced for 562–641 ms
        ↓
Hovering, dragging and clicking appear severely delayed

Local performance sampling found that the Browser main thread was repeatedly and synchronously SHA-256 hashing the complete bundled resources\codex.exe, which is 295,151,920 bytes (281.5 MiB). A Windows UI-delay capture recorded repeated WM_MOUSEMOVE delays of 562–641 ms on that same thread.

The packaged and relocated copies of codex.exe were already identical, including their SHA-256 hashes. Nevertheless, while otherwise idle, the Browser process recorded approximately 3.9 GiB of reads in 10 seconds and continued using about 1.2 CPU cores.

This appears related to the Windows bundled-executable relocation/validation path repeatedly executing the equivalent of:

createHash("sha256").update(readFileSync(file)).digest("hex")

Because this runs synchronously on Electron’s Browser main thread, Windows input messages cannot be serviced while the executable is being read and hashed.

Codex Desktop version: 26.810.6296.0, x64.

Uploaded performance trace: no-active-thread-01a00371-dbb2-79c3-b2ba-a595da76742f

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 trace match plus simultaneous MCP/helper-process accumulation

I can independently reproduce this on Windows with the affected 26.810 line. The problem began immediately after the 2026-08-14 update from 26.803.10989.0.

I recorded a built-in performance trace while the system-wide mouse/typing stutter was occurring. The active CPU-profile window was ~20.7 s. The hotspot was in the Electron Browser/main process: native crypto update accumulated ~13.1 s self time through node:internal/crypto/hash update -> XK in src-BlUt09P1.js. createUnsafeArrayBuffer accumulated ~1.36 s through allocUnsafeSlow -> readFileHandle, and RunMicrotasks repeatedly blocked the main process for roughly 650–673 ms at a time.

Inspection of the packaged bundle confirmed that XK is the SHA-256 whole-file hashing function used by the plugin/runtime file-equivalence comparison, so this independently matches the hashing/reconciliation mechanism already identified in this issue.

The renderer JS heap remained approximately flat during the trace (~140.8 MB -> ~142.2 MB after minor GC), and the Browser/main heap was ~38 MB and stable. This does not look like a conventional renderer JS heap leak.

At the same time, I found a second large resource problem that may compound the same user-visible slowdown:

• complete Codex process tree: ~205 descendants, ~9.65 GB combined working set
• Chrome DevTools MCP-related Node processes: 57 processes, ~5.2 GB
• Playwright MCP-related Node processes: 38 processes, ~3.0 GB
• node_repl contexts: 20
• 16 GB machine at ~92% memory use, with only ~1.3 GB available

Fully terminating ChatGPT.exe removed the process tree and immediately restored normal responsiveness.

This appears to be two simultaneous problems on this machine: (1) the Electron main-process hashing/reconciliation loop described here, and (2) MCP/helper processes being multiplied or retained instead of reclaimed, similar to #37672.

A further clean reproduction: after a fresh Windows reboot, the machine is responsive until Codex is launched. The mouse/typing latency begins almost immediately after opening the app, without opening a project, submitting a prompt, or starting any Codex work. Fully terminating the app again restores responsiveness.

Version clarification: a subsequent package check shows this machine is currently on OpenAI.Codex 26.810.6296.0. The earlier trace/process measurements were collected during the affected investigation where 26.810.4967.0 had been recorded, but the later fresh-reboot/immediate-launch reproduction may have occurred after the automatic update to 26.810.6296.0 and should not be interpreted as specific to 26.810.4967.0.

I am waiting for 26.810.7004.0 to become available so I can retest. The Codex updater currently reports “Update is becoming available, try checking again later”, so the new build has not yet been offered to this machine. The currently installed package is OpenAI.Codex 26.810.6296.0.

I am withholding the raw ~144.6 MB trace because it contains local paths and task metadata, but I can provide a sanitized trace if maintainers request a safe upload method.

Independent reproduction + reversible workaround: runtime read/hash loop drops ~500× after rebuilding .plugin-appserver

Adding an independent Windows reproduction on Codex Desktop 26.810.4967.0, plus results from a reversible A/B workaround test.

The original failure mode was a persistent Electron desktop-main loop with system/UI stutter and approximately 790–893 MB/s of logical File I/O reads. A 15-second WPR File I/O trace attributed the dominant reads to repeated full-file access of two identical Codex runtime sets: the versioned desktop runtime and the plugin app-server runtime. The Electron main process performed approximately 31,046.66 MB of reads in 15 seconds.

I have now completed the previously proposed reversible A/B test. The result was strongly positive.

Environment

• Windows 11 25H2, build 26200
• Intel Core Ultra 9 185H
• 22 logical processors
• Codex Desktop 26.810.4967.0

No chat/session data, SQLite databases, MCP configuration, skills, project files, tokens, or documents were deleted or edited.

---

Reversible A/B test

Procedure:

1. Fully quit Codex Desktop.
2. Do not delete chat/session data and do not modify SQLite.
3. Rename:

%USERPROFILE%\.codex\plugins\.plugin-appserver

to a dated backup directory, for example:

.plugin-appserver.backup-YYYYMMDD-HHMM

1. Start Codex Desktop again.
2. Confirm that Codex automatically recreates a fresh .plugin-appserver directory.
3. Allow the app to stabilize.
4. Repeat the same CPU and logical File I/O measurements.
5. Keep the backup directory available for rollback.

No automatic rollback was required in this test.

Important safety note

This is a rename, not delete procedure.

The backup should be retained until the user has had a reasonable period of stable operation. It should only be removed after stability is confirmed.

Do not delete unrelated files under .codex, and do not delete or modify chat/session stores, SQLite databases, project data, credentials, tokens, skills, or documents as part of this workaround.

Raw traces and unsanitized local paths should not be published.

---

What was inside the old and regenerated runtime directories

Both the dated backup and the newly recreated .plugin-appserver directory contained only four runtime files:

• codex.exe
• codex-code-mode-host.exe
• codex-windows-sandbox-setup.exe
• codex-command-runner.exe

The total size of each runtime set was approximately 347.75 MB.

For each corresponding old/new file pair:

• file size matched
• SHA-256 matched

So the positive result cannot be explained by Codex downloading or generating a different executable version.

The runtime binaries themselves were byte-identical before and after the workaround.

The inspected runtime directories did not contain user chats, conversation context, skills, projects, tokens, or working documents.

---

Before / after measurements

Before rebuilding .plugin-appserver

Affected-state measurements for the Electron desktop-main process:

• logical File I/O reads: approximately 790–893 MB/s
• sustained CPU sufficient to cause visible UI/input stutter
• 15-second WPR File I/O trace: approximately 31,046.66 MB of reads by the Electron main process
• physical SSD read activity did not correspond to the logical read rate, indicating that much of the traffic was being served through the Windows filesystem cache / memory path

The system remained usable in terms of total CPU capacity, but mouse movement, scrolling and UI responsiveness were visibly degraded.

After clean recreation of .plugin-appserver

First stabilized 10-second measurement after restart:

• Electron desktop-main: 0.43% total host CPU
• logical reads: 1.56 MB/s
• writes: 0.10 MB/s

Independent second 10-second measurement during an active conversation:

• Electron desktop-main: 0.11% total host CPU
• all ChatGPT.exe processes combined: 0.15% total host CPU

Compared with the affected-state logical read rate of 790–893 MB/s, the regenerated runtime state reduced logical reads by roughly 500×.

The user-visible result matched the counters:

• mouse movement returned to normal
• windows opened smoothly
• the machine stopped feeling generally sluggish
• responsiveness remained normal even with total system CPU around ~6%

---

What this A/B test establishes

Confirmed by measurement

The workaround produced a large and measurable change in the observed failure state:

close Codex → rename .plugin-appserver → restart → allow Codex to recreate it → remeasure

After that sequence:

• the runaway logical read rate disappeared
• Electron main-process CPU fell close to idle
• system/UI stutter disappeared

The newly generated runtime binaries were byte-identical to the old ones.

Therefore the improvement is not explained by replacing bad executables with different binaries.

Engineering interpretation — hypothesis, not proven source-level root cause

The result is consistent with the rename/recreation resetting some stale or latched state associated with plugin app-server runtime verification, registration, synchronization, watcher state, or related cache/lifecycle metadata.

That interpretation fits the earlier WPR evidence showing repeated full-file reads of identical source/destination runtime binaries.

However, this experiment does not identify the exact internal state variable or closed-source code path that was stuck.

So I would describe this as:

• a confirmed workaround for the observed incident
• strong evidence that the failure was tied to plugin-appserver runtime state/lifecycle
• not an official OpenAI fix
• not a proven source-level root cause

The plugin runtime was not permanently disabled. Codex recreated .plugin-appserver automatically and normal application/chat operation continued.

---

Practical workaround for users still affected on this build

For users who are still on an affected 26.810.4967.0 installation and see the same symptoms:

1. Fully quit Codex.
2. Rename, do not delete, %USERPROFILE%\.codex\plugins\.plugin-appserver.
3. Keep the renamed directory as a dated rollback backup.
4. Restart Codex.
5. Verify that .plugin-appserver is recreated automatically.
6. Confirm normal chat/task behavior.
7. Remeasure CPU and logical File I/O if possible.
8. Keep the backup until the app has remained stable for a reasonable period.
9. Delete the backup only after stability is confirmed and rollback is no longer needed.

This should not be interpreted as a reason to delete chat history, session databases, project data, skills, tokens, or other files under .codex.

---

Relationship to the reported fix build

A maintainer has noted in this issue that the regression is believed to be addressed in 26.810.7004.0.

All measurements and the workaround above were performed on the affected 26.810.4967.0 build.

I am not claiming that the same loop persists in 26.810.7004.0 or later.

For a clean follow-up, the most useful test would be to run the same CPU/File I/O counters and, if necessary, another short WPR trace on the newer build and compare it against the affected-state measurements above.

If the issue is gone in the newer build, that would provide a useful before/after confirmation.

If it persists, a fresh report should reference this issue and include the new-build measurements.

---

Privacy

No usernames, account details, conversation IDs, task IDs, project names, local personal paths, transcript content, credentials, or tokens are included here.

The raw ETL is intentionally not published because kernel File I/O traces contain local filesystem paths.

I can provide additional sanitized aggregates if useful.

Additional reproduction on Windows x64 with Codex Desktop 26.810.6296.0 and bundled Chrome plugin 26.810.50856. I have not tested the reported fix build 26.810.7004.0 yet.

Important workaround nuance: disabled is still watched

I first used the commonly suggested configuration workaround and fully restarted the app:

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

The loop stopped immediately after restart, but returned after the app had remained open for roughly one day. At that point codex plugin list reported:

chrome@openai-bundled  installed, disabled

A live breakpoint in the Electron main process at the chrome-native-host-cache-watcher reconcile call repeatedly captured:

{
  "pluginName": "chrome",
  "activePlugins": ["chrome"]
}

So the native-host cache watcher still considered Chrome active for reconciliation based on installed state even though the plugin was disabled.

Runtime evidence during the recurrence

A 10-second CPU profile again showed native crypto.Hash.update() as the dominant main-process hotspot. The captured async chain was:

XK -> JK -> GK -> zK -> AJ -> eJ

XK in the packaged bundle performs the equivalent of:

createHash("sha256").update(await fs.promises.readFile(path)).digest("hex")

Breakpoint arguments showed repeated hashing of paired runtime files under the versioned Codex runtime and .codex/plugins/.plugin-appserver, including codex.exe, codex-code-mode-host.exe, codex-command-runner.exe, and codex-windows-sandbox-setup.exe.

A 20-second affected-state sample measured:

• Electron main process: 121.15% average CPU, 142% peak
• All ChatGPT processes: 127.05% average CPU
• Logical reads: 365.26 MiB/s average, 1,037 MiB/s peak
• Visible system-wide mouse stutter

A Chrome extension-host.exe process had also survived the Codex app restart and kept the installed Chrome cache directory open. The official removal command initially failed with Windows Access denied until that stale extension host was terminated.

After codex plugin remove chrome@openai-bundled succeeded, the plugin state became not installed, the Chrome cache directory disappeared, and the hashing loop stopped immediately without restarting Codex. A 20-second post-removal sample measured:

• Electron main process: 4.55% average CPU, 27% peak
• Logical reads: 3.68 MiB/s average
• No recurring 500-1,000 MiB/s read bursts
• Mouse responsiveness returned to normal

This suggests that on 26.810.6296.0, disabling the plugin is not a durable mitigation because native-host cache reconciliation follows installation state rather than enabled state. Fully removing the Chrome plugin is the durable workaround observed here.

Privacy: no usernames, account data, conversation/task IDs, absolute personal paths, IP addresses, raw logs, screenshots, credentials, or process dumps are included.