FYI (likely not-a-bug): one CPU core pinned when the project directory is on an ImDisk RAM disk — settings watcher loops on uv_fs_realpath EISDIR

Note up front

This isn't really a bug report against Claude Code — the root cause is a
known limitation of ImDisk RAM disks, not Claude. I'm filing it purely for
discoverability: the symptom (a pegged CPU core) gives no hint of the cause,
and searching turns up nothing. Please feel free to label it not-a-bug, convert
to a Discussion, or close after it's indexed. There's one narrow, optional
robustness note at the end that you may or may not care about.

Symptom

Launching claude in a project whose directory lives on an ImDisk RAM disk
(e.g. R:\) pins one CPU core at ~100% for the entire session, even while
completely idle. Same Claude Code binary in any project on a normal NTFS volume
(C:\) idles at 0%. The process does ~60k directory/stat I/O ops per second
with zero bytes read — a watcher spinning, not doing real work.

Root cause

ImDisk creates "simple volumes" that don't integrate with the Windows Volume
Mount Manager, so GetFinalPathNameByHandleW fails on any path on the volume.
libuv's uv_fs_realpath (used by fs.realpath.native) relies on that call, so
it throws EISDIR for every path on the drive:

> node -e "console.log(require('fs').realpathSync.native('R:/'))"
EISDIR: illegal operation on a directory, realpath 'R:/'
# (the pure-JS require('fs').realpathSync('R:/') succeeds; only .native fails)

Claude Code's settings/config watcher walks the cwd's ancestor chain and
registers a persistent watch that hits the drive root. With --debug --debug-file,
~99% of the log is one line repeating thousands of times per second:

[WARN] [settings] watcher error: EISDIR: illegal operation on a directory, lstat 'R:/'

Environment

• Claude Code 2.1.206 (native install), Windows 11
• RAM disk: ImDisk Toolkit (latest, 20250206)
• Node/libuv (whatever Claude bundles) — confirmed the same on stock Node

Workarounds (for anyone who finds this)

1. Keep the source tree on NTFS; put only the build output on the RAM disk.

Move the repo to C:\... and junction the build dir to RAM:
mklink /J C:\path\to\repo\out R:\repo\out. Claude then only watches C:,
and builds still land in RAM. (Fixed it for me, zero config changes.)

1. Use a RAM disk that presents as a real SCSI disk (Storport miniport) so

GetFinalPathNameByHandleW works — e.g. Arsenal Image Mounter, WinSpd, or
SoftPerfect RAM Disk. Verify with the one-liner above: it should print a path,
not throw. (Same limitation also breaks some other realpath-reliant tools —
I've hit it with LunarVim Lua and some Chrome extensions.)

Optional robustness note (not asking for a realpath change)

Relying on uv_fs_realpath is completely reasonable — no complaint there. The
only thing that turns this from "one logged warning" into a pegged core is that
the watcher retries the failing path with no backoff and no error cap. A
persistent watcher error backing off (or giving up on that path after N tries)
would make this — and any future weird-filesystem case — a non-event. Entirely
your call whether that's worth it.