Many concurrent Claude Code processes refresh policy-limits / remote-settings in the same minute, causing hourly filesystem stalls in `~/.claude`

Title: Many concurrent Claude Code processes refresh policy-limits / remote-settings in the same minute, causing hourly filesystem stalls in ~/.claude

Environment: Linux 6.8, ext4 on NVMe, one user, about 200 concurrent interactive Claude Code processes (2.1.280–2.1.287) sharing one ~/.claude, several team/enterprise seats.

What happens

• Once an hour, at the same minute, about 85–150 processes rewrite ~/.claude/policy-limits.json, policy-limits.json.stamp.json (temp file plus rename) and remote-settings.json within about 50 seconds. Measured at 18:39:30–18:40:20: 648 inotify events in ~/.claude, against 7 in the 50 s before and 81 in the 50 s after (148 stamp renames, about 85 rewrites of each JSON file).
• During that minute about 4,000–6,600 threads (Bun Pool) sit in uninterruptible sleep in getdents on ~/.claude for about 60–80 s. Kernel stacks at onset show the ext4 journal (jbd2) waiting on I/O, Claude Code threads in unlink/O_TRUNC open holding the directory lock, and a kworker in fsnotify_connector_destroy → synchronize_srcu. Each rename replaces an inode that many processes watch.
• Other processes refresh the same files at their own fixed hourly second (each rewrite second repeats exactly one hour later), so outside the clustered minute the load is spread out. The cluster is the problem.

Why it matters: on a busy disk, one clustered refresh stalls every Claude Code process on the host for over a minute every hour.

Requests

1. Add random jitter to the hourly policy-limits / remote-settings refresh, so processes that share a phase spread out.
2. Skip rewriting files whose contents did not change (a 304 / unchanged ETag should not rewrite the stamp or the JSON).
3. Optionally, a documented setting to lengthen or disable the refresh for managed fleets. (CLAUDE_CODE_REMOTE_SETTINGS_POLL_MS appears in the binary but is undocumented; we have not verified what it does.)

Evidence (available on request): a 30-second log of file mtimes and D-state thread counts over two hours, a timestamped inotify capture of the clustered minute, and kernel stacks of the blocking threads.