[Bug] Settings watcher on NixOS symlinks triggers CPU storms and multi-GB heap growth scanning /nix/store

Bug Description
Claude Code watches /nix/store when managed settings are NixOS symlinks → synchronized CPU storms and multi-GB heaps

Version: 2.1.280 and 2.1.283, Linux (NixOS), many sessions under a terminal multiplexer.

Setup: /etc/claude-code/managed-settings.json and managed-settings.d/*.json are created by NixOS environment.etc, so they are symlinks to top-level store files (/nix/store/<hash>-etc-claude-code-managed-settings.json).

Bug: the settings watcher resolves the symlink and watches the target's parent directory, so every Claude session holds an inotify watch on /nix/store itself (verified via /proc/<pid>/fdinfo). Any store change (nix build, nix develop, GC, .lock files) makes every session readdir + statx the entire store (~210k entries) at the same moment.

Impact:

• strace of an idle session: ~18k statx/s on /nix/store/* plus a matching 8-byte eventfd write per stat, ~40-150% CPU per idle session, all sessions in lockstep.
• Heap growth from the churn: sessions reached 4-7 GB RSS within hours (heapdump: 45M strings, 2.3M Promises). With ~12 sessions this exhausted 62 GB RAM + swap, and the OOM killer took down the desktop session.

Repro: on NixOS, set any environment.etc."claude-code/managed-settings.json".text, start claude, run nix store add-file <any file>, watch the claude process CPU and syscalls.

Workaround: environment.etc.<file>.mode = "0444" (NixOS copies the file instead of symlinking). After restarting, the same store change gives 0% CPU and ~1 write/s, versus ~22% CPU and ~28k writes/s for sessions still holding the watch.

Suggested fix: watch the directory containing the configured path (/etc/claude-code), not the symlink target's parent, or don't watch read-only/immutable locations such as /nix/store.

Environment Info

• Platform: linux
• Terminal: herdr
• Version: 2.1.283
• Feedback ID: 097c082a-8d2f-4048-9464-ef7cbe2a8d1d

Errors

[]