Up/Down arrows jump to history instead of moving cursor through wrapped multi-line prompt input (all platforms; regressed ~2.1.15)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20328
2. https://github.com/anthropics/claude-code/issues/63191
3. https://github.com/anthropics/claude-code/issues/63427

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

+1, confirming this still reproduces on 2.1.158 (native installer) on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2).

Same symptom: a long pasted line with no embedded newlines soft-wraps across several visual rows; cursor on the bottom row + Up arrow immediately recalls a prior history entry instead of moving up one visual row. Left/Right move by character normally, so it's specifically the Up/Down cursor-vs-history routing.

Was a meaningful loss of editing ergonomics for me — used to use Up to fix typos a few rows back in long prompts.

Reproducing the same bug on Windows Server 2025 Standard (10.0.26100), which contradicts the "Windows unaffected" finding in this report.

Environment:

• Claude Code v2.1.158, native CLI (not VS Code extension)
• Windows Terminal + PowerShell (right-click "Open in Terminal")
• Windows Server 2025 Standard

Symptoms: Identical to what's described. Typing a multi-line prompt and pressing Up arrow immediately jumps to history instead of moving the cursor up one visual row. This is a confirmed regression; the previous behavior correctly moved the cursor within the prompt first and only navigated history when already on the first line.

This is a significant usability regression for anyone writing longer prompts. Editing multi-line input is now impractical without mouse or word-by-word navigation.

OP here. update: the "Windows unaffected" finding no longer holds. my own box - the one i filed from, where Up/Down walked the wrapped rows correctly at 2.1.156 - now reproduces the regression on 2.1.159. same setup as the original report: Windows 11 (10.0.26200), Windows Terminal + PowerShell, native CLI not the VS Code extension. soft-wrapped line, cursor on the bottom visual row, Up jumps straight to history instead of moving up one row.

this lines up with @zwowbrands's Windows Server 2025 confirmation at 2.1.158 - so Windows fell somewhere in the 2.1.157-2.1.158 window. it's now all three platforms, not a macOS/Linux-only split.

updated the title to drop the "Windows unaffected" qualifier. can't add labels myself - could a maintainer add platform:windows, since the regression is universal now.

Adding a data point from macOS (Apple Silicon, native install) that may help bisection.

I hit this exact symptom — Up/Down jumps to history instead of moving between soft-wrapped rows of a single line; newline-separated multiline navigation (Option+Enter / Shift+Enter) works fine. Confirmed in both the VS Code integrated terminal and standalone Terminal.app, so it isn't a VS Code-layer issue.

Possible second/re-introduced regression boundary at 2.1.160: I ran a clean single-variable A/B by repointing the native install between locally-cached binaries:

• 2.1.159 → works (Up moves up a wrapped row, text intact)
• 2.1.160 → broken (Up jumps to history)

Same machine, same terminal, same prompt — only the binary changed. This is in tension with the "broken ~2.1.15 through 2.1.156" bisection above: either there's a separate re-introduction at 2.1.160, or 2.1.159 simply doesn't reproduce on my setup. Flagging in case the 2.1.159→2.1.160 boundary helps narrow it. Note that 2.1.160 reworked the prompt-input renderer (the workflow→ultracode trigger keyword is now violet-highlighted in the input box), which touches the same visual-layout code that decides wrapped-row vs. history.

Two more notes:

• The in-progress draft is not destroyed — pressing Up shows history, but Down/Esc restores the typed text (annoyance, not data loss, on my setup).
• The mouse-click workaround does not work for me — clicking doesn't reposition the cursor in either terminal. Ctrl+A/Ctrl+E + Option+arrow word-jumps are the only reliable workaround here.

Environment: macOS (Darwin 25.5, arm64), native install (~/.local/bin/claude), reproduced on 2.1.160 in Terminal.app and the VS Code integrated terminal.

Still reproduces on 2.1.161 (macOS, native CLI) — one release past the 2.1.160 boundary @chrisblattman bisected, so it's not fixed in the latest.

Confirming on WSL2, still broken in v2.1.162.

Platform: Windows 11 + WSL2 (Ubuntu)
Terminal: Windows Terminal
Version: 2.1.162

Same behavior as described: in a long, soft-wrapping multi-line prompt, Up/Down navigate command history instead of moving the cursor between wrapped rows. Left/Right move the cursor by character normally, so key delivery is fine — only the Up/Down cursor-vs-history routing is wrong. This worked until a recent update.
Downgrading to 2.1.150 restores correct behavior, consistent with #62736. No custom keybindings.json, no key bindings in settings.json.

Confirming this on macOS 15 (Sequoia), Claude Code 2.1.162, VS Code integrated terminal. Up/Down navigate history instead of moving the cursor through a soft-wrapped multi-line draft. Ctrl+A/Ctrl+E still position the cursor fine, so it's the Up/Down routing specifically.

It looks like it is fixed in v2.1.165.

Platform: Windows 11 + WSL2 (Ubuntu)
Terminal: Windows Terminal
Version: 2.1.165

Now I can navigate up and down again ... Thank you!

It looks like it is fixed in v2.1.165. Platform: Windows 11 + WSL2 (Ubuntu) Terminal: Windows Terminal Version: 2.1.165 Now I can navigate up and down again ... Thank you!

Issue persists for me on v2.1.165 macOS (tui fullscreen / Terminal.app). Up arrow key takes me to my last prompt when the cursor is on the 2nd+ line of a prompt, instead of the original behavior of going up a line, and then to the start of the first line if there are no higher lines, and THEN back a prompt.

yeah still persistent on mac ghostty, pc wezterm, wsl wezterm - might be fixed in WT.exe according to @mariolorenz ?? am currently on 2.1.165

+1, same issue.

• Claude Code: 2.1.165
• OS: Windows 11 Pro 25H2 (build 26200)
• Terminal: VS Code integrated terminal (PowerShell 5.1 default profile)

The UX I expect (and that earlier versions provided, matching macOS Terminal/iTerm behavior with most modern shells):

• ↑ in multi-line input → move cursor up one row inside the prompt
• ↑ when already on the first row → go to previous history entry
• ↓ mirror

Current 2.1.165 behavior: ↑/↓ always jumps to history immediately, even when the cursor is on row 2+ of a wrapped or explicitly multi-line prompt. Forces using Home/End or Ctrl+A/E plus Ctrl+J to navigate, which is painful for any prompt longer than a screen line.

Confirming this is platform-agnostic — same broken behavior on Windows as the OP reports for other platforms.

same behavior on latest CC, on win11 powershell. really sucks

@bogini thank you for your attention to this matter

+1, confirming this still reproduces on 2.1.158 (native installer) on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2). Same symptom: a long pasted line with no embedded newlines soft-wraps across several visual rows; cursor on the bottom row + Up arrow immediately recalls a prior history entry instead of moving up one visual row. Left/Right move by character normally, so it's specifically the Up/Down cursor-vs-history routing. Was a meaningful loss of editing ergonomics for me — used to use Up to fix typos a few rows back in long prompts.

It applies to me.

/tui fullscreen then /tui default fixed it for me.

/tui fullscreen then /tui default fixed it for me.

tried this on wezterm on pc, not wsl yet, and it crashed the tui -
was already in fullscreen before running /tui fullscreen through maybe the old env?

i'll investigate and update.

update: partially fixed on 2.1.77 but the down arrow still doesn't reset to the front of the text on wezterm pc / wsl. previous function would allow you to press down once you're on the bottom line and it will then send you to the end of the cursor for typing