[BUG] Windows: 100% CPU forever inside an AppContainer sandbox (bundled chokidar re-adds the drive root in a loop when realpath fails)

Status Open
Reported on v2.1.286
Maintainer reply None cached
Activity 0 comments · opened Oct 9, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Hello, I'm reporting this issue found by Claude Opus 5.5.

------------

Run inside a Windows AppContainer (a standard Windows sandbox), claude.exe burns one or two full CPU cores from the moment its first screen appears, and never stops, even while idle. Started the same way without the AppContainer, it sits at 0%.

Full reproduction (a ~60-line AppContainer launcher, no admin rights needed) and trace script: https://github.com/electrotype/issue-claude-code-appcontainer-cpu-loop

Cause: the chokidar copy bundled in Claude Code re-adds C:/ about 6,000 times per second:

  1. Inside an AppContainer, realpath fails with EPERM for every path. Bun's native realpath uses GetFinalPathNameByHandleW with DOS names, which needs the volume mount manager, and no AppContainer may open it. The drive root C:\ isn't readable either.
  2. chokidar's add() → _addToNodeFs() swallows that error (ignorePermissionErrors / ENOENT) and returns the path. add() then re-adds dirname(path) with no check that dirname(path) !== path.
  3. Every parent fails the same way, so each directory watcher (settings, keybindings, the project folder, skills...) climbs to C:/. There dirname("C:/") === "C:/", and add("C:/") repeats forever.

Trace (trace-root.js from the repo, loaded with BUN_OPTIONS=--preload):

fs.promises.stat("C:/") :: at _addToNodeFs (B:/~BUN/root/chunk-6np1zevt.js:11:11473) | ... | at add (B:/~BUN/root/chunk-6np1zevt.js:11:16758)
drive-root calls so far: 126839
drive-root calls so far: 132992
drive-root calls so far: 138951

The same loop was reported for ImDisk RAM disks in #76608 (closed by the stale bot). There too, GetFinalPathNameByHandleW fails on every path of the volume.

Suggested fix: in the bundled chokidar's add(), stop climbing when dirname(n) === n. chokidar 5.0.0, the latest on npm, still has this code; chokidar's main branch has a rewritten add() without that retry.

What Should Happen?

Idle CPU near 0%, as without the AppContainer.

Error Messages/Logs

Steps to Reproduce

The "Steps to reproduce" section of the repo README.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.286 (also 2.1.285)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

https://github.com/electrotype/issue-claude-code-appcontainer-cpu-loop

View original on GitHub ↗