[BUG] Agents view opened by bare `claude --resume` / `-r` / `--continue` ignores all keyboard input (v2.1.203–204)

i have this issue on the Linux build version 2.1.204

Confirming this on a second macOS setup, same 2.1.204, Apple Terminal, Apple Silicon, zsh. The agents dashboard renders fine but arrow keys, Enter, Esc, and typing all do nothing, and it started right after the in-session auto-update to 2.1.204. Plain claude works normally in the same terminal, and claude --resume <session-id> with an explicit ID works too, so it is specifically the picker/dashboard reached through claude -r / --resume / --continue that is frozen.

Two things to add that we ran into and have not seen mentioned yet:

1. A second symptom involving /rename that makes this look far worse than it is. If you use /rename on a session, it writes the new name onto a completed background-job record under ~/.claude/jobs/<short-session-id>/. Because that jobs folder is global rather than per-project, the "completed" card gets resurrected and pinned to the top of the picker in every directory, so every claude -r shows a stale "DONE" entry sitting on top of the already-frozen picker. Deleting just that one folder removes the phantom card:

rm -rf ~/.claude/jobs/<short-session-id>

Worth stressing for anyone who lands here in a panic: /rename did not corrupt your sessions. The full conversation history is untouched and still lives in ~/.claude/projects/.... It is only this stale job card plus the frozen agents view layered on top of it.

2. A workaround that keeps background agents enabled. As the original post notes, CLAUDE_CODE_DISABLE_AGENT_VIEW=1 also disables background agents, --bg, /background, and the daemon, which a lot of us do not want to give up. It turns out you do not have to give those up. Passing any non-empty search argument to -r opens the older classic picker instead of the frozen agents view, and that classic picker takes keyboard input normally (type to search, arrow keys, Enter to resume, Space to preview, Ctrl+R to rename, Ctrl+A for all projects). A single space works as a catch-all that just shows the full list:

claude -r " "

Background agents stay fully enabled with this. We wrapped it in a shell function so it is muscle memory:

cr() { claude -r "${1:- }"; }

Now cr opens the working picker in any directory, and cr <word> searches by name. It has been a clean daily driver while the agents view is broken.

Hope this helps get it escalated. Happy to pull logs or test a patched build if that would be useful.

I'm facing the same issue (on v2.1.204) on macos. claude --resume does not goto the resume session screen.

dups: #75497 #75496 #75513 #75521 #75560 #75579

Same on v2.1.204 — macOS 26.5.2 (Apple Silicon / arm64), iTerm2, zsh. The agent-view / FleetView renders fine but swallows all keyboard + mouse input (typing, arrows, Enter, Esc, even Ctrl+C do nothing); the process sits near-idle CPU, so it looks blocked waiting on input that never dispatches rather than busy-looping.

Datapoint for localizing it: only the view is dead, not resume itself. claude --resume <session-id> with an explicit id, and claude -c, both launch and accept input normally — it's the no-arg picker / agent-view input loop that's broken. Reports here line up on it starting right after the in-session auto-update to 2.1.204, so 2.1.203 looks like the last good build.

same here:

omer@Omer-Ratsaby-NLP:~$ uname -a
Linux 6.6.87.2-microsoft-standard-WSL2  Thu Jun  5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
omer@Omer-Ratsaby-NLP:~$ claude --version
2.1.204 (Claude Code)
omer@Omer-Ratsaby-NLP:~$

Confirming on Linux (VS Code devcontainer, x86_64), v2.1.204, Node v24.16.0, TERM=xterm-256color.

Some pty-level datapoints that may help localize it — I drove claude --resume under a raw pseudo-tty and captured the byte stream:

1. The dashboard renders fine (session list loads and displays), but every keypress — letters, arrows, Tab, ? — produces zero repaint output. The only bytes emitted after each keystroke are a re-emission of the mouse-tracking enable sequences: ESC[?1000h ESC[?1002h ESC[?1003h ESC[?1006h. So the view appears to re-initialize terminal modes on input instead of dispatching the key.
2. Control test: plain claude REPL in the identical pty harness echoes typed characters normally (each char repaints). So it's not the terminal/environment — it's specifically the agent-view input path.
3. The in-app /resume picker (run claude, then type /resume) works perfectly — arrows, search, space-preview all respond. Consistent with the daemon-backed-picker finding in #75635.
4. Not a data issue: all session .jsonl files parse cleanly line-by-line; claude --continue and claude --resume <uuid> both work.

Workaround for anyone landing here: start claude normally, then use /resume to get the classic (working) session picker; or claude --continue / claude --resume <session-uuid> directly.

Thanks everyone for the reports — this is a real issue on our side, and I'm sorry for the disruption.

To get going again: quit claude and start it again — no update is needed. claude --resume / -r / --continue will return to the normal session picker. If you still land on the unresponsive screen, give it one more restart — it can take an extra launch to clear.

If you need to get back into a session right now, any of these work:

• claude --continue — most recent session
• claude --resume <session-id> — a specific session
• /resume from inside claude
• claude -r " " — opens the classic picker (any non-empty argument works)

I'm consolidating the duplicate reports here so there's one place to follow: #75496 #75497 #75513 #75560 #75562 #75579 #75584 #75596 #75634 #75635 #75649 #75660 #75716 #75724 #75726

Still reproduces on v2.1.205 — macOS 26.5.2 (Apple Silicon / arm64), iTerm2, zsh.

2.1.205 is the current latest and shipped after this was closed as completed, but it hasn't actually resolved it here. After I updated this morning the bare -r picker behaved for a short while, then the input-dead agent-view came back. Restarting clears it temporarily, but it keeps recurring — so on my machine at least it's mitigated, not fixed. Flagging since this is currently closed as completed.