Skip to content

[BUG] Excessive config file polling during UI render causes full CPU usage when arrow key is pressed to recall previous prompt #14054

Closed as not planned

Description

@duncanmcl

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:

  1. Read once at startup and cached
  2. Optionally watched via inotify for changes
  3. 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

  1. Start Claude Code in terminal
  2. Run strace -f -e trace=access,statx -p $(pgrep -f "claude") in another terminal
  3. Press Up Arrow to recall previous prompt
  4. 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

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

  1. github-actions commented on Dec 15, 2025

    @github-actions

    Found 1 possible duplicate issue:

    1. [BUG] Claude Code process enters infinite loop and becomes completely unresponsive during long-running API calls. #11170

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. github-actions commented on Jan 16, 2026

    @github-actions

    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.

  3. duncanmcl commented on Jan 17, 2026

    @duncanmcl
    Author

    The issue is still occurring.

  4. github-actions commented on Feb 27, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  5. github-actions commented on Mar 7, 2026

    @github-actions

    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.

  6. locked as resolved and limited conversation to collaborators on Mar 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions