[BUG] Idle TUI CPU scales with the NUMBER of installed skills (~45 syscalls/s per skill; 40 skills ≈ 4–5 % of a core per idle session, Windows 2.1.276)

Summary

An idle Claude Code TUI (waiting at the prompt, no output, no tool running) burns CPU in proportion to the number of skill directories it has loaded — not to their size. With a bare config it idles at ~1 % of a core; with my normal config (40 user skills, 11 plugins, 23 commands/agents) it idles at 11–15 % and issues 3,000–4,600 "other" I/O syscalls per second (Windows IO_COUNTERS.OtherOperationCount: directory/attribute queries, not reads/writes). With seven persistent sessions open that is roughly one full core doing nothing.

I bisected the configuration with CLAUDE_CONFIG_DIR pointing at minimal config dirs containing exactly one ingredient each (junctions to the real directories). Numbers are 40-second idle averages, all sessions started hidden with --dangerously-skip-permissions in the same trusted cwd, measured in parallel with psutil:

| Config ingredient (alone) | idle CPU | other-I/O ops/s |
|---|---|---|
| bare (credentials only) | 1.0 % | 225 |
| + statusLine (bash → python, refreshInterval 10) | 1.0 % | 226 |
| + hooks (SessionStart/Stop/PreToolUse/PostToolUse) | 1.0 % | 226 |
| + 2 MCP servers (one stdio node, one HTTP) | 0.8 % | 70 |
| + 12 commands + 11 agents | 1.8 % | 500 |
| + 11 plugins (junction to plugins/, enabledPlugins copied) | 2.0 % | 243 |
| + 40 user skills (junction to skills/) | 4.9 % | 2,670 |
| full normal config | 11–15 % | 3,200–4,600 |

Second round, skills only, to separate count from size:

| skills dir contents | skills | files | idle CPU | ops/s |
|---|---|---|---|---|
| empty | 0 | 0 | 1.2 % | 196 |
| one skill with 594 files (4 MB) | 1 | 594 | 1.8 % | 486 |
| one synced-skills bucket | 1 | 207 | 1.3 % | 320 |
| all the other skills | 38 | 241 | 3.8 % | 1,965 |

→ ~45 syscalls/s and ~0.07–0.1 % of a core per skill directory, regardless of how many files are inside. It looks like a per-skill poll (stat/readdir at a fixed short interval) rather than an event-based fs.watch.

Environment

• Claude Code 2.1.276, native installer build (%USERPROFILE%\.local\bin\claude.exe), Windows 11 Pro 10.0.26200, Ryzen 9 3950X
• Sessions run inside ConPTY terminals (VS Code serve-web and Windows Terminal); same behaviour in a hidden CREATE_NEW_CONSOLE console
• Skills are ordinary directories under ~/.claude/skills, a few are symlinks into ~/.claude/.agents/skills

Things I checked

• The load is spread over ~50 threads, no single hot thread; per-thread sampling shows it as many short wake-ups.
• CLAUDE_CODE_PLUGIN_DIR_WATCH=0 / =false (found in the binary's env-var strings) changes nothing (11.0 % → 10.4 % / 9.7 %, within noise). I found no other env knob related to skill watching.
• When the terminal's pty backend was congested (unrelated VS Code server problem on my side), the same idle sessions rose to 20–40 % each and ~9,400 ops/s — so the idle loop also amplifies under back-pressure.
• Related but not the same mechanism: #94288 (idle CPU in parallel sessions, no root cause yet), #78969 (animated element). Here nothing is animated; the only variable that moves the number is the skill count.

Expected

An idle session with 40 skills should cost about what an idle session with 0 skills costs. Skill/command/agent directories rarely change; a native fs.watch (ReadDirectoryChangesW on Windows) or a much slower poll interval would remove essentially all of this load.

Repro

1. Put 30–40 small skill directories (each just a SKILL.md) under <CLAUDE_CONFIG_DIR>/skills.
2. Start claude, leave it at the prompt.
3. Compare process CPU and OtherOperationCount deltas over 40 s against a run with an empty skills/ dir.