[Windows desktop] CrBrowserMain consumes one CPU core while watching a delete-pending directory; restart clears it #44960

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Sep 12, 2026
2. 84dnnvbdvp-debug commented on Sep 12, 2026

   

   84dnnvbdvp-debug

   on Sep 12, 2026 – with ChatGPT Codex Connector

   More actions

   Fresh public-source review suggests a useful process-boundary discriminator here rather than assuming this is the same loop as #38109.

   Current codex-rs/file-watcher is built on notify::RecommendedWatcher, tracks requested vs. actual watched paths, and can move the OS watch to the nearest existing ancestor when path existence changes. app-server/src/fs_watch.rs also owns those watches explicitly by connection/watch ID and removes them on fs/unwatch or connection close. So there is public watcher lifecycle machinery for missing paths; I would not infer from #38109 alone that the Rust/app-server live-query path is the exact source of this incident.

   The measured process split in this report is the stronger clue: CrBrowserMain in the main ChatGPT.exe process was ~one core while codex.exe app-server was ~0.4%. That differs materially from #38109's app-server/Git churn signature. A high-value next discriminator would be to reproduce the delete-pending-handle state while simultaneously checking whether app-server fs/watch / live-query activity is quiet. If it is quiet while CrBrowserMain continues issuing ReadDirectoryChanges* / file-information calls on the same delete-pending handle, this points to a Desktop/Chromium-side watcher lifecycle rather than the public Rust watcher.

   For regression coverage I would keep the process boundary explicit: create a watched directory, unlink/delete it while the app remains open, verify the main-process watcher releases or rebinds the old handle and returns to idle CPU, and separately assert no app-server subscription keeps polling the removed path. That should also help avoid fixing the already-visible #38109 retry class while leaving the main-process handle loop intact.

   Source checked on current main (c4017a87):

   • codex-rs/file-watcher/src/lib.rs
   • codex-rs/app-server/src/fs_watch.rs

   This does not identify the private Desktop/Chromium call site; it only narrows where the observed process-level evidence says to look.
3. natqe commented on Oct 14, 2026

   

   natqe

   on Oct 14, 2026

   More actions

   Same hot loop, with a concrete trigger, the root cause, and a deterministic repro (Windows 11 Pro 25H2, build 26200; Codex desktop 26.1007.2314.0)

   Trigger: archiving a thread that owns a managed worktree. Archive cleanup removed the worktree directory while the desktop app still had fs.watch directory handles open on it and on its .git\worktrees\<name> admin directory.

   What I measured:

   • In the main ChatGPT.exe process, a Node worker thread named git (from GetThreadDescription) ran at about 100% of one core for about 11 hours (about 40,000 CPU-seconds).
   • About 37% of that was kernel time, with about 51,000 non-read/write I/O operations per second.
   • The process held three directory handles (access 0x100081, which is the libuv fs_event signature) that resolved to \\?\C:\$Extend\$Deleted\..., with DeletePending=True.
   • Only a full app restart stopped it.
   • Side effect: git status calls on the deleted worktree failed about 1.75 times per second. The watcher events probably re-triggered them; compare Review live query keeps polling deleted managed worktrees until app restart #38109.

   Root cause (libuv bundled with Node/Electron):

   • In libuv 1.52.x and earlier, src/win/fs-event.c → uv__process_fs_event_req handles a watched directory that is pending deletion like this: ReadDirectoryChangesW fails with ERROR_ACCESS_DENIED, libuv emits rename for the watched root, and then immediately queues ReadDirectoryChangesW again.
   • The new request fails at once, so this repeats until the application closes the watcher.

   Minimal repro (Node v24.5.0 / libuv 1.51.0, the same Windows machine):

   const fs = require('fs'), os = require('os'), path = require('path');
   const dir = fs.mkdtempSync(path.join(os.tmpdir(), 'watch-repro-'));
   let n = 0;
   const w = fs.watch(dir, () => n++);
   setTimeout(() => {
     fs.rmdirSync(dir);
     const t = process.cpuUsage(), s = Date.now(), n0 = n;
     setTimeout(() => {
       const c = process.cpuUsage(t), ms = Date.now() - s;
       console.log({ eventsPerSec: Math.round((n - n0) * 1000 / ms), cores: ((c.user + c.system) / 1000 / ms).toFixed(2) });
       w.close();
     }, 2000);
   }, 300);

   Output: { eventsPerSec: 155398, cores: '0.97' }, mostly kernel time. Every event is a rename that carries the full \\?\C:\... path of the deleted root.

   Upstream status:

   • libuv 1.53.0 fixes this: win: fix watch loop logic libuv/libuv#5013, "win: fix watch loop logic". It stops re-queuing once the handle resolves under \$Extend\$Deleted\ and reports ENOENT instead.
   • Node.js does not include it yet: deps: update libuv to 1.53.0 nodejs/node#66282 is open, and fs.watch: endless file events reported nodejs/node#61398 tracks the issue.

   Suggested fixes in the app (these do not depend on the libuv update):

   1. Close the fs.watch handles on a worktree root and on its .git\worktrees\<name> before archive cleanup or git worktree remove.
   2. Close a watcher when it receives rename for its own root, or an error. Even with libuv 1.53.0, the watcher stays open until the app closes it.
   3. Move to libuv 1.53.0 or later through Electron/Node when that becomes available.

   Related: #38109 (same trigger: live-query polling of deleted managed worktrees), #33401 (handles left on archived worktree directories).