Multiline input: arrow keys should navigate lines, not history

Confirming — but flagging that this is a regression, not a missing feature.

Up/down line navigation was working in my multiline prompts until ~2 days ago (broken since ~2026-05-26 for me, Linux). Worth noting it's broken-and-been-fixed before too: comments on the now-closed #20328 pinpoint v2.1.19 as the version it broke in back in January (last working v2.1.14). So this code path appears to regress periodically.

Suggest labeling bug and bisecting against the last 2-3 releases.

+1 on macOS — Claude Code 2.1.153, Darwin 25.5.0, cmux terminal. Broke this past week for me too.

Additional finding worth noting for triage: unbinding up/down in the Chat context via ~/.claude/keybindings.json (setting both to null) does not restore visual-row navigation across soft-wrapped lines. Hard newlines (Shift+Enter) navigate fine; soft-wrapped logical lines do not. So the fall-through behavior of the input widget itself treats a wrapped line as a single logical line — the regression isn't purely in the keybindings layer routing arrows to history.

Pre-regression, up/down moved between visual rows of a soft-wrapped prompt, which is the muscle-memory behavior users have lost.

FYI this is actually a regression, not a missing feature — multi-line cursor navigation worked correctly in 2.1.148 and broke in 2.1.149+. See #62736 (canonical) and #63191 (Windows bisect).

Probably worth retagging this from enhancement to bug/regression so it lands on the right triage queue.

This is broken for me, too. Seriously - how can you guys not have regression tests and at least one QA or Dev engineer using Windows Terminal Preview with PowerShell 7 on Windows 11? How is that a thing?

Agreed. It's now much more cumbersome to navigate long or multi-line prompts.

Looks fixed in v2.1.172 for me (not sure exactly when it was addressed).