`--resume` picker renders but ignores ALL keyboard input — strace proves keys ARE read by the process (v2.1.204, Linux)

Summary

Running claude --resume in a project with multiple sessions renders the session picker correctly, but the picker ignores all keyboard input (arrows, Enter, ?, Ctrl+X, even Ctrl+C) indefinitely (>1 hour). The process must be killed from another terminal.

We traced the live frozen process with strace and proved the keystrokes are delivered to and read by the process — the bug is in the application layer (input events read from the TTY but never dispatched to the UI), NOT in the terminal/SSH/TTY stack.

Environment

• Claude Code v2.1.204 (latest at time of report)
• Linux (RHEL 9 family, kernel 5.14), x86_64, bash, TERM=xterm-256color, plain SSH session (no tmux)
• Project folder with 9 sessions (~115 MB of .jsonl history; largest 35 MB)
• Picker header showed: 2 awaiting input · 0 working · 7 completed

Reproduction (as observed)

1. cd into a project directory with several past sessions, some with pending "awaiting input" background tasks
2. claude --resume
3. Picker renders fine (list + "describe a task for a new session" field)
4. No key has any effect. Ctrl+C does nothing (raw-mode byte, never handled). kill <pid> from outside works.

Two independent claude --resume processes in different projects froze the same way simultaneously.

Evidence from the live frozen process

1. Keystrokes ARE read by the process — strace -f -p <pid> -e trace=read while pressing arrow keys in the frozen terminal:

read(12, "\33[I", 262144) = 3          # focus-in event received
read(12, "\33[B\33[A", 262144) = 6     # Down + Up arrows — READ OK
read(12, "\33[A", 262144) = 3          # repeated for every keypress
read(12, "\33[B", 262144) = 3
... (every keypress read successfully, then EAGAIN as expected)

So: SSH delivers ✓, pty delivers ✓, epoll wakes ✓, fd is read ✓ — and the UI still never reacts. The input dies between the terminal reader and the picker component.

2. Event loop is alive, not busy-looping: main thread parked in epoll_pwait2 (wchan ep_poll), ~5% CPU, state S. The TTY fd is registered in the epoll set with EPOLLIN armed (/proc/<pid>/fdinfo: events: 40000019).

3. Possible culprit — cross-session IPC: during the freeze the picker was reading session-state JSON about the OTHER frozen --resume process over an internal pipe ({"pid":<other-pid>,"sessionId":"..."}). This suggests the picker blocks its input handling on a background-session/task state sync that never completes — consistent with the "N awaiting input" counter in the header.

What this rules out

• Not SSH/PTY allocation (keys reach the process — see strace)
• Not TERM/raw mode (raw-mode bytes like Ctrl+C are read as data, as expected)
• Not tmux (plain ssh + bash)
• Not slow-loading large history alone (frozen >1h; the reads above happen long after render)

Workarounds confirmed working

• claude --continue
• claude --resume <session-id> (bypasses the picker)

Possibly related

#11618, #23954, #13504 (same symptom class; this report adds syscall-level evidence that input reaches the app).