claude doctor command freezes with no response to Enter key

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/6757
2. https://github.com/anthropics/claude-code/issues/6705
3. https://github.com/anthropics/claude-code/issues/7604

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

I see the same issue:

claude doctor

 Diagnostics
 └ Currently running: npm-global (2.1.17)
 └ Path: /Users/.../.nvm/versions/node/v20.19.5/bin/node
 └ Invoked: /Users/.../.nvm/versions/node/v20.19.5/bin/claude
 └ Config install method: global
 └ Search: OK (vendor)

 Updates
 └ Auto-updates: enabled
 └ Update permissions: Yes
 └ Auto-update channel: latest
 └ Stable version: 2.1.7
 └ Latest version: 2.1.17

 Version Locks
 └ No active version locks

 Press Enter to continue…

The other issues linked above are all closed. Claude's diagnosis:

Process State

The process is idle, waiting in the Node.js event loop:

PID   %CPU  STAT  TIME
67693  0.0   S+   0:01.29

Stack trace shows it's blocked in kevent (I/O poll):
uv_run → uv__io_poll → kevent

Root Cause: Terminal Raw Mode

The terminal is left in raw mode with signals disabled:

$ stty -a < /dev/ttys005
lflags: -icanon -isig -iexten -echo

Key flags:
- -icanon: Non-canonical mode (no line buffering)
- -isig: Signals disabled - Ctrl+C doesn't send SIGINT
- -echo: Input not echoed

This means:
1. claude doctor enters raw mode for its interactive prompt
2. Something hangs before the prompt can read input
3. Terminal is stuck in raw mode, making it impossible to interrupt or provide input

Also affects claude -r (resume) - see #20374 for additional reproduction scenario:

When running claude -r in a directory with no previous conversations, the prompt "Press Ctrl+C to exit and start a new conversation" also freezes with the same symptoms (keyboard input ignored, must forcibly kill process).

Tested in both Warp and Mac Terminal - same behavior in both.

Same root cause (terminal raw mode) likely applies to both entry points.

I actually need to kill -9 it kill doesn't stop it

Occurs under Linux as well. Ubuntu 24.04.3 LTS, gnome-terminal.

This issue is also occurring on Windows since claude code version 2.1.16

Same issue here on macOS 15.x and 26.x.

Additional Investigation Findings for Issue #20303

These findings may help narrow down the root cause of the claude doctor input hang.

1. Minimal Ink Test Works Correctly

I created a standalone Ink app with useInput and confirmed it correctly receives and processes Enter keypresses when run via Bun:

import { useInput } from 'ink';

useInput((input, key) => {
  console.error(`Got input: ${JSON.stringify({input, key})}`);
  if (key.return) {
    // This fires correctly with key.return: true
  }
});

Conclusion: The bug is not in Bun or Ink core libraries - it's specific to how claude doctor's pagination component sets up input handling.

2. Unusual Multiple TTY File Descriptors

The doctor process has 6 file descriptors pointing to the same TTY:

2.1.19  PID user    0u      CHR    /dev/ttys009  (stdin)
2.1.19  PID user    1u      CHR    /dev/ttys009  (stdout)
2.1.19  PID user    2u      CHR    /dev/ttys009  (stderr)
2.1.19  PID user    7u      CHR    /dev/ttys009
2.1.19  PID user    8u      CHR    /dev/ttys009
2.1.19  PID user   14r      CHR    /dev/ttys009  (read-only)

The separate read-only FD 14 is unusual. This might indicate:

• stdin is being duplicated incorrectly
• The process is polling the wrong file descriptor for input
• Some initialization is creating extra handles that aren't being used

3. Screen Updates But No Input Processing

When sending Enter via PTY (using expect or Python pty module), the screen does update after input is sent:

• The "Stable version" and "Latest version" lines render after the initial prompt
• The prompt refreshes/redraws

This suggests:

• The event loop IS running (kevent64 returns)
• Some events ARE being processed (screen updates)
• But keypress events specifically are not reaching the input handler

4. Version 2.1.19 Also Affected

The issue currently mentions versions 2.1.16 and 2.1.17. Confirmed that 2.1.19 (latest) is also affected.

5. claude -p Works Fine

Running claude -p "test" works correctly and processes input/output properly. This confirms the main stdin handling in Claude Code works - the bug is isolated to the interactive pagination component used by doctor and resume commands.

6. Stack Sample Confirms kevent64 Wait

Process sample shows main thread blocked in:

kevent64 (in libsystem_kernel.dylib)

This is the correct system call for waiting on I/O events - the process is properly waiting, but the stdin read events aren't being dispatched to the Ink input handler.

---

Suggested Investigation: Check how the pagination/prompt component registers stdin for reading in the event loop. The multiple TTY FDs and the fact that minimal Ink works suggests the pagination component may be:

1. Not registering stdin correctly with the kqueue
2. Reading from the wrong file descriptor
3. Missing a stdin.resume() or equivalent call

Also experiencing this issue on WSL2 environment:

• OS: Linux 6.6.87.2-microsoft-standard-WSL2 (Ubuntu)
• Claude Code version: 2.1.20 (native installation)
• Terminal: Windows Terminal / WSL2

Same symptoms - claude doctor displays diagnostics correctly but "Press Enter to continue…" prompt doesn't respond to Enter key. Only way to exit is Ctrl+C.

On Windows 11, this appears to be resolved as of claude code 2.1.21

Fixed on Mac in 2.1.29.

Yes, this should have been fixed in 2.1.21.

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.