claude -r / --resume opens agent-view (FleetView) home that accepts no keyboard input — total input hang (iTerm2, v2.1.204)

Environment

• Claude Code v2.1.204
• macOS (Darwin 25.5.0), Apple Silicon
• Terminal: iTerm2 3.5.14, TERM=xterm-256color

What happens

Running claude -r (or claude --resume) with no session ID no longer opens the classic numbered "Resume session" picker. Instead it opens the new agent-view / FleetView home screen ("N awaiting input · N working · N completed", "describe a task for a new session", enter to open · space to reply · ctrl+x to delete).

On that screen the keyboard is completely dead — no arrow keys, no typing, no Enter, nothing registers. The process is not CPU-spinning (renders once, then sits idle/sleeping), it simply never accepts input. Only way out is to kill the process.

This is specific to the FleetView home, not the resume flow itself

Setting CLAUDE_CODE_DISABLE_AGENT_VIEW=1 makes claude -r fall back to the classic numbered picker, and that picker is fully responsive — search, arrows, Enter all work. So the input-hang is isolated to the new agent-view home renderer, not to resume/session-loading.

Root cause of the routing (from the 2.1.204 bundle)

Bare --resume is intentionally routed to FleetView by this branch:

else if (a.resume===true && !a.forkSession && ... && a.name===void 0 && ... && <agentViewEnabled>) {
    N("tengu_fleetview", { viaResume:true }),
    ... // mount FleetView + startBackgroundHousekeeping
}

It's gated by agent-view / past-sessions-experiment flags (isPastSessionsExperimentEnabled, etc.), so it seems to only affect users enrolled in that experiment. The routing is by design; the bug is that the resulting FleetView home takes no keyboard input in iTerm2.

Repro

1. On v2.1.204 in iTerm2, in a project dir with existing sessions, run claude -r.
2. Observe the agent-view/FleetView home renders.
3. Try any key (↑/↓, typing, Enter) → nothing happens; screen is frozen to input.

Workarounds (confirmed)

• CLAUDE_CODE_DISABLE_AGENT_VIEW=1 → classic picker returns and is responsive.
• claude -c (continue most recent) or claude -r <session-id> bypass the FleetView branch entirely.

Note

The FleetView home and the classic picker both emit the same keyboard-protocol negotiation on entry (CSI > 1 u kitty keyboard protocol, CSI > 4;2 m modifyOtherKeys). The classic picker works despite emitting these, so the difference appears to be in how the FleetView home sets up / reads input, not the protocol sequences themselves.