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

What version of the Codex App are you using (From “About Codex” dialog)?

Windows package version: 26.908.4834.0 (OpenAI.Codex, x64; observed from the installed package, not the About dialog).
The unified desktop app executable is ChatGPT.exe. Bundled Chromium version observed: 152.0.7977.83.

What subscription do you have?

Not disclosed for privacy.

What platform is your computer?

Windows x64, NTFS.

What issue are you seeing?

The ChatGPT/Codex desktop app recurrently consumes approximately one full CPU core even when no question or task is running.

One affected instance was investigated before restarting. The CPU hotspot was the main process's CrBrowserMain thread. Repeated execution-position samples landed in directory-change notification and file-information calls, with the relevant call contexts repeatedly containing the same handle to a delete-pending directory.

After restarting the app, I confirmed that the high CPU symptom was resolved. No numerical post-restart CPU benchmark was captured.

CPU measurements before restart

All percentages below use one logical CPU = 100%, not whole-machine percentages.

Component	Observed CPU
Main ChatGPT.exe process	Approximately 102.1% initially; 101.5% on a later check
CrBrowserMain thread, 10-second sample	99.3% total: 27.0% user time + 72.4% kernel time
GPU child process, later check	8.4%
Primary renderer child process, later check	6.2%
codex.exe app-server, later check	0.4%

The symptom existed before diagnosis. Measurements were collected during the diagnostic session, not a controlled benchmark with all diagnostic activity stopped.

Sampled execution locations

In one recorded batch of 400 short thread-context samples:

Execution location	Samples
ntdll!ZwNotifyChangeDirectoryFileEx+0x14	191
ntdll!ZwQueryInformationFile+0x14	76

Together these accounted for 267/400 (66.75%) samples. An earlier independent batch gave 281/400 (70.25%) for the same two locations. These are execution-position sample fractions, not precise per-function CPU-time percentages.

Stack-top return addresses mapped into KERNELBASE's ReadDirectoryChangesExW and GetFileInformationByHandleEx. Additional stack code pointers included ReadDirectoryChangesW and chrome.dll. This was not a fully symbolicated stack unwind.

Directory-handle evidence

Further targeted sampling repeatedly resolved the same directory handle in both hot call contexts. Its normalized path was under the NTFS $Extend$Deleted namespace; the volume, unique entry name, handle value, and original local paths are intentionally omitted.

Independent metadata queries on a duplicate of that handle returned:

DeletePending=True
Directory=True
NumberOfLinks=0

This establishes that the application still held a handle to an unlinked, delete-pending directory during the high CPU episode.

What steps can reproduce the bug?

A deterministic minimal reproduction has not been established. The observed sequence was:

1. Use the Windows desktop app normally and leave it running.
2. The app enters a sustained high CPU state that continues during periods without active questions/tasks.
3. During one occurrence, inspect CPU by process and thread: CrBrowserMain consumes approximately one full core.
4. Sample that thread and inspect the directory handles in the hot call contexts: repeated directory notification/information calls refer to the same delete-pending directory.
5. Restart the desktop app.
6. The high CPU symptom disappears.

The original directory path and the process or operation that deleted it were not identified. Directory deletion was observed through handle metadata; it was not deliberately triggered as a reproduction test.

What is the expected behavior?

The desktop app should return to low CPU when idle. If a watched directory is deleted or unlinked, its watcher should be retired, rebuilt, or handled with bounded retry/backoff, without a persistent full-core loop in the main thread. Recovery should not require restarting the application.

Additional information

Working hypothesis: a directory-watcher lifecycle or repeated-processing problem involving a directory that became delete-pending. The hotspot and directory state are measured evidence; the exact faulty code path and causal trigger remain unproven.

Diagnostic limits:

• No application private symbols or full symbolicated call stack were available.
• System-call boundary register snapshots were not treated as completed-call return codes; no particular failure code is asserted.
• The current instance's desktop log files were empty when inspected, so they did not establish the trigger.
• Windows Performance Recorder could not start because profiling privileges were unavailable. The alternative used brief thread-context sampling with immediate resume, plus directory-handle metadata queries.
• Restart recovery is confirmed for this occurrence. It does not establish that every historical occurrence has the same cause or that the problem is permanently fixed.

Related reports: #37372 (Windows main-process idle CPU) and #38109 (continued activity against deleted worktrees). This report adds native directory-notification hotspots and independently verified delete-pending handle state. Whether these reports share a cause is unknown.

Privacy: This issue contains only a sanitized technical summary. No raw logs, memory dumps, screenshots, local files, usernames, machine names, account details, workspace paths, conversation content, session IDs, process/thread IDs, handle values, unique filesystem entry identifiers, absolute memory addresses, or precise local timestamps are included.

No source file, test, or entry point is identified. Start by establishing a deterministic reproduction for the delete-pending directory watcher and tracing the CrBrowserMain directory-notification path. Done means an idle app avoids a persistent full-core loop and recovers without requiring a restart.