Windows: host process spins at ~200% of one core when a session's skill root is deleted (skill-filesystem rewatch has no backoff)

[wkea]

Summary

On Windows, the DSH desktop host process (dsh-desktop-host, the Node side-agent process) can sustain ~200% of one core indefinitely while completely idle ??no model call, no network egress, no disk I/O. Traced to @deepseek-ai/dsh-skill-filesystem: when a project/skill root path disappears (workspace directory deleted or renamed while the session still references it), the rewatch path has no backoff and no attempt cap, so it re-opens a watcher, fails, and re-scans the directory in a tight loop. The process also leaks native FSWatcher handles that keep receiving events after being logically closed.

This is adjacent to but distinct from #6099 (rename-event storm on a custom Codex skills root) and #11479 (per-session 100ms skill watcher). #6099 needs a high event rate on an existing root; this one needs only a root that no longer exists and reproduces with zero filesystem activity.

Environment

• DeepSeek Harness desktop 0.2.1-rc.5, dshBuildCommit d4db512a969fccf0c5cc7ec8fe38e9c1d27af916
• Windows 10.0.19045, x64
• Chokidar 5.0.0 (bundled)
• Chokidar watcher owner: packages/skill/skill-filesystem

Reproduction (observed, not yet minimized)

1. Start a session whose working directory / project root is an existing directory, e.g. G:\zimg, and let the skill provider observe the roots.
2. Delete or rename that directory (G:\ still exists, G:\zimg no longer does).
3. Leave the app idle.

Result: the host process climbs to ~200% of one core and stays there. In my case it had accumulated 2824 CPU-seconds in ~25 minutes of idling, and the session's last model request had completed 24 minutes earlier.

Evidence

Process state while spinning

• 198% of one core sustained over 6s samples, flat (not bursts).
• Handle count 352 -> 351, thread count fixed at 15 ??nothing is being created or torn down.
• IO counters (Win32_PerfRawData_PerfProc_Process): IOReadBytes / IOWriteBytes / IOOtherBytes deltas all 0 over 4s.
• TCP: loopback only, no egress. Last API call 2026-11-01T21:30:16Z; session file session.v4.jsonl.zstd last written 21:30:42Z; spin continued past 21:45.
• One thread (Id 99968) accounts for ~1010s of the process's 2824s, state Running.

CPU profile (3s, Profiler.setSamplingInterval 200, 3953 samples, taken over the app's own inspector on 127.0.0.1:9230, which is the dsh-experimental-inspector target for the host realm):

 6.0%  readdir                  node:internal/fs
 5.2%  copyObject               node:internal/fs/utils:213
 4.0%  join                     node:path:506
 2.9%  handleErrorFromBinding   node:internal/fs/promises:179
 2.3%  _handleRead              chokidar/handler.js:449
 2.1%  _throttle                chokidar/index.js:569
 1.7%  join                     node:path:506
 1.5%  handleEvent              chokidar/handler.js:116
 1.2%  isWindowsReservedName    node:path:81
 1.1%  readdir                  node:internal/fs/promises:1651
 1.1%  isWindowsReservedName    node:path:81
 1.0%  nextTick                 node:internal/process/task_queues:113
 1.0%  nextTick                 node:internal/process/task_queues:113
 0.8%  normalize / normalizeString  node:path:350 / :92
 0.7%  FSWatcher._emitRaw       chokidar/index.js:308

Everything hot is chokidar's readdir + PathNormalize path. _handleRead re-scanning a directory that does not exist is the direct cost.

Paused stack (Debugger.pause):

normalizeString      node:path:98
normalize            node:path:447
join                 node:path:598
handleEvent          chokidar/handler.js:122
emit                 chokidar/index.js:514
FSWatcher._handle.onchange  chokidar/index.js:281

Leaked native watchers

process._getActiveHandles().filter(h => h.constructor.name === 'FSWatcher').length  // 15

Each of the 15 exposes keys ['_events','_eventsCount','_maxListeners','_handle','_ignoreMatcher'] and no _watched / _watchedDirs ??i.e. chokidar considers them logically empty/closed, but the libuv _handle is still alive and still delivering onchange events. So 15 zombie native watchers keep feeding the loop while the owning state has already been replaced.

Suspected source

packages/skill/skill-filesystem/src/index.ts (master):

• scheduleRewatch() (~:583) awaits the current opening then calls ensureWatcher() immediately; failure is swallowed:

  try { await this.ensureWatcher(state) } catch {
    // Watch startup logged the retry failure; the next incomplete discovery retries it again.
    return
  }

  There is no delay, no attempt counter, no maxRewatch, and no backoff anywhere in the file.
• handleWatcherError() (:575), handleAncestorWatchEvent() (:493), and the unlinkDir branch of handleWatchEvent() (~:570) each set state.unhealthy = true and call scheduleRewatch() ??so any error or disappearing-anchor event immediately re-enters the open path.
• openStableWatcher() (~:446) loops while (!this.closing && state.owners.size > 0) between two resolveRootWatchMode() probes, closing and re-opening the watcher whenever the mode differs. When the root is permanently absent, the ancestor/root mode resolution and the chokidar open both race the deletion, so the loop can keep re-opening.
• openRootWatcher() (~:488) still calls chokidar.watch(mode.anchor, { depth: 1, atomic: true, awaitWriteFinish: {...} }) with no ignored matcher, which is the same surface [Bug][Windows] skill-filesystem watcher can hit a high-CPU rename-event storm on a custom Codex skills root #6099 reported.

Suggested direction (not prescriptive): add exponential backoff + a cap to scheduleRewatch, skip/close cleanly when the anchor is absent instead of re-opening, and verify that closing the handle actually closes the libuv handle (the 15 stale FSWatchers suggest close() resolves before the native handle is gone).

Expected behavior

Idle host process should sit near 0% CPU with an absent session root, and should log one warning rather than re-opening a watcher in a loop.

Additional observation

Killing the host process dropped total machine CPU from 184% (one core) to 0.9% immediately, and the main Electron process did not respawn it ??the inspector endpoint on 9230 stayed down while the window and renderer lived on, so the UI kept accepting input with a dead agent backend. If that is not intended, it may deserve its own item.

Workarounds

• Kill the stuck host process and restart the desktop app.
• Do not leave sessions pointed at deleted/renamed working directories.
• Setting CHOKIDAR_USEPOLLING=0 / lowering pollIntervalMs does not help, because the loop is driven by open failures, not by polling.