Repository navigation
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
When pressing arrow keys to recall previous prompts (history navigation), Claude Code enters a tight polling loop checking ~/.claude/.config.json approximately 15,000 times per second. This causes 100% CPU usage on one core.
The config file is checked via access() + statx() syscalls on every UI render frame without any caching. This happens regardless of whether the file exists or not.
Key finding: This is NOT caused by a missing file (as suggested in #11170). The polling continues at the same rate even after creating the file.
What Should Happen?
Configuration files should be:
- Read once at startup and cached
- Optionally watched via inotify for changes
- NOT re-read on every render frame
Error Messages/Logs
strace output showing the polling pattern (excerpt from ~10ms window):
read(20, "\33[A", 262144) = 3 ← Arrow Up key press
access("/home/user/.claude/history.jsonl", F_OK) = 0
clone3({flags=CLONE_THREAD...}) = 695753 ← Thread spawned
access("/home/user/.claude/.config.json", F_OK) = 0
statx(AT_FDCWD, "/home/user/.claude/.config.json", ...) = 0
access("/home/user/.claude/.config.json", F_OK) = 0
statx(AT_FDCWD, "/home/user/.claude/.config.json", ...) = 0
madvise(0x..., 16384, MADV_DODUMP) = 0
access("/home/user/.claude/.config.json", F_OK) = 0
statx(AT_FDCWD, "/home/user/.claude/.config.json", ...) = 0
[... repeats ~150 times in 10ms ...]
write(12, "\33[?2026h\33[2K\33[1A...", 2212) = 2212 ← Terminal redraw
The madvise(MADV_DODUMP) calls interleaved with config checks indicate this is tied to the render/memory allocation cycle.Steps to Reproduce
- Start Claude Code in terminal
- Run strace -f -e trace=access,statx -p $(pgrep -f "claude") in another terminal
- Press Up Arrow to recall previous prompt
- Observe thousands of access("/home/user/.claude/.config.json") calls
Alternative verification:
strace -c -p $(pgrep -f "claude")
Run for a few seconds while pressing arrow keys, observe access and statx dominating syscall counts.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
2.0.69
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Xterm
Additional Information
Relationship to other issues
- Issue [BUG] Claude Code process enters infinite loop and becomes completely unresponsive during long-running API calls. #11170 reported similar symptoms but misdiagnosed the cause as "non-existent config file". Creating the file does NOT fix the problem - the polling frequency remains the same.
- Issue [BUG] Excessive settings.json file I/O (1000x/sec) after tool calls causes performance degradation in WSL #2906 (fixed in v1.0.53) addressed similar excessive I/O for settings.json, but .config.json polling was not fixed.
Evidence that file existence doesn't matter
Before creating file (polled ~15,000/sec):
access("/home/user/.claude/.config.json", F_OK) = -1 ENOENT
statx(AT_FDCWD, "/home/user/.claude.json", ...) = 0
[repeats thousands of times]
Note: Falls back from ~/.claude/.config.json to ~/.claude.json
After creating file (STILL polled ~15,000/sec):
access("/home/user/.claude/.config.json", F_OK) = 0
statx(AT_FDCWD, "/home/user/.claude/.config.json", ...) = 0
[repeats thousands of times]
Note: No fallback needed, checks same file
The polling frequency is identical in both cases. Creating the file only changes which file gets statx'd, not how often.
Root cause analysis
The config loading appears to be called synchronously within the UI render loop without caching:
Render cycle:
└─ For each component
└─ loadConfig() ← Called every frame, no cache
└─ render()
Activity
github-actions commentedon Dec 15, 2025
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
github-actions commentedon Jan 16, 2026
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
duncanmcl commentedon Jan 17, 2026
The issue is still occurring.
github-actions commentedon Feb 27, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 7, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.