Prompt Input: Unexpected Text Loss on Up Arrow Key Press

This is poor UX, lost text numerous times due to this

Yes, it's incredibly annoying. I'm on macOS using iTerm and I'm regularly losing carefully crafted prompts to this behaviour. The lost prompt can be recovered by using Ctrl+_ but the behaviour is surprising.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is an incredibly annoying bug. Hoping this gets fixed soon.

+1, that issue is super annoying. I've just hit it after writing 10-15 minutes, so I have to rewrite everything from scratch ...

This should be a configurable behavior that is turned off, by default. Most users don't want to lose the text they have just entered.

+1 fix this un claude code vscode plugin, extremely annoying
Ubuntu Linux.

Took me lately also some hours of productivity. This is just bad UI. Tested with term, iterm, ghostly and inbuild vscode-inbuild term.

There are some possibilities how you can fall into this. For example by starting cc and using cursor up to see an old prompt -> Edit -> cursor up or down -> Edit is gone

Thanks to rob-smallshire for the tip with CTRL+_ ! (in the moment I got this bug I was not aware of being able to undo, that really makes no sense in this context)

My 2 cents: Claude needs an edit mode or so - which is automatically switched on, when I write more than X words - where it behaves like any "normal" editor. Or at least you should not be so simple able to use cursor up/down when you already edited a prompt, because it makes normally no sense. You want to read old prompts of course, and cursor up/down would be an intuitive solution, but not, when it looks like you lost all your input.

Yeah, this is brutal. Write a well-crafted prompt to steer Claude to do something pretty sophisticated, then press "up" too many times and poof its gone. This is a new way of losing one's work.

Commenting to prevent this from getting closed like #12664

Seems like this issue is cross-platform. I can attest that this occurs in VS Code on Windows 11 (and probably all VS Code platforms?) and also apparently in some of the CLI experiences, according to earlier comments.

This happens not just with 'up' key, it happens with Ctrl+L, Ctrl+U, Ctrl+K -- all the normal shell kb shortcuts.
When working with multiple agent sessions, it happens a lot that an agent may ask a question/wait for action, but the keyboard focus is in a different agent. So these accidents happen more as I use claude code more.
Would _REALLY_ love to see an undo / redo.

Bump?!

This is so infuriating, how come this has not been fixed for a year o_O. It should take Opus 30s to take care of it :P

@mikocot So, why don't you ask Opus to take care of it and create a PR …?

Same here. I lost a long prompt in VSCode Claude plugin. I suggest that up arrow does nothing when there is already text in the current prompt.

Btw: the Ctrl+_ workaround doesn't work for VSCode.

+1 in Cowork desktop on Windows 11 (Claude Code 2.1.111). Closed my own report #53107 as a duplicate of this -- same root behavior. Confirmed pattern across:

• TUI / macOS / Apple Terminal (this issue)
• VS Code extension (#51202 -- feature-framed; asks for a claudeCode.inputHistoryNavigation setting)
• Cowork desktop / Windows (my closed #53107)

Worth flagging an under-emphasized failure mode: while a recalled prior message is in the input, typing edits/sends to that prior message rather than the live draft. Users don't only lose their current draft -- they can also unintentionally edit and re-send a prior turn. There is no visible indicator that the input has been hijacked from current-draft mode.

I've faced this issue several times, please someone give attention to this. It could simply save your current message on the history list so when you press arrow down you will see the previous message again.

By the way, the tags are wrong, this also happens on Windows.

Super annoying! Using Claude Desktop for Claude Code and this has happened to me several times. Of course the times it bites you is when you have a long prompt that you are scrolling up and down to get perfect and then suddenly...POOF!

+1: This is extremely annoying. 30 min of thinking and typing lost, because of scrolling up to the top in Claude Code Desktop with the keyboard.

+1 this is maddening, and would be SO EASY TO FIX!! Just add a configuration option in prefs to disable history recall with the up/down arrows. Or make it require a key modifier like CMD+up. I truly hate this change to Claude Code.

Please fix this. This is super annoying!
Steps to reproduce:

1. Open the Claude Code chat input in the VS Code extension.
2. Type a long multi-line message (do not submit).
3. Press and hold the Up arrow key to scroll the cursor toward the top of the message.
4. Observe what happens when the cursor reaches the first line and Up is still being held.

The draft is silently overwritten with a history entry with no warning. Because the Up key is held down, this happens in the same continuous motion the user uses to navigate inside their own text.
I have lost several long, carefully-written messages this way. There is no way to recover the text, and no setting documented anywhere to disable the behavior in the VS Code extension. The CLI-level ~/.claude/keybindings.json (unbinding up/down in the Chat context) has no effect on the VS Code extension.

What should happen - one of the following:

• The cursor stops at the top of the input and Up does nothing further, OR
• The current draft is preserved (stashed) and pressing Down arrow restores it, OR
• A confirmation/warning is shown before the unsaved draft is replaced.

This has been open since August 2025 with steady reports across CLI, VS Code, Cowork desktop, and multiple OSes. It is one of the worst data-loss footguns in the product. Please prioritize.

Still unresolved on v2.1.153 (Windows 11 / PowerShell) — 4+ months and many releases later.

This is the single most disruptive UX regression in Claude Code for anyone who writes long, multi-line prompts. Per the now-locked #20328, the last working version was 2.1.14; it broke around 2.1.15 and is still broken today on 2.1.153.

Concrete symptom: I'm three lines into a paragraph, realize the first word needs a fix, press Up to move the cursor up one line — and instead it discards my draft and recalls the previous message. To get back to that word I have to hold Left and watch the cursor crawl character-by-character through the entire paragraph. It makes editing a long prompt in place effectively impossible.

The documented behavior (and the pre-2.1.15 behavior) is correct: in a multi-line draft, Up/Down should move the cursor between lines, and only fall through to command history once the cursor is already on the top/bottom line. Please restore that. At minimum, make "Up recalls history" a configurable toggle that defaults off, as others here have requested.

This isn't a minor annoyance — it costs real work every day. Would appreciate this being re-prioritized.

Still reproducing on v2.1.156 (macOS, Ghostty / TERM=xterm-ghostty).

Up/Down navigate prompt history even when the cursor is inside multi-line text — they should move the cursor within the text first and only recall history at the top/bottom boundary.

Note: trying to disable it via ~/.claude/keybindings.json does not work — unbinding up/down in the Chat context (setting them to null) has no effect after restart, so there's currently no config-level workaround:

{ "context": "Chat", "bindings": { "up": null, "down": null } }

Still happening on macOS (Apple Silicon), Claude Code v2.1.157, native install — in both Ghostty and Terminal.app. Pressing Up/Down in a multi-line prompt jumps to command history instead of moving the cursor between lines.

Confirmed it's not terminal-specific and not a keybindings issue: setting up/down to null in ~/.claude/keybindings.json (verified the file is loaded — /doctor flags a deliberately invalid context, so it's being read) does not suppress the behavior. That points to history navigation being handled at the input-widget layer, below the keybinding system.

Reportedly last working in 2.1.14. Same symptom as the auto-closed #20328 (closed for inactivity, not fixed). Commenting to keep this open issue active.

Follow-up with a more precise repro. The cursor up/down logic appears to key off the logical line, not the visual (wrapped) line:

• Multi-line input created with real newlines (Ctrl+J / Shift+Enter): Up/Down correctly move the cursor between lines and only fall through to command history at the true top/bottom edge. This works.
• A single logical line that wraps across multiple visual rows (a long prompt typed with no newline): Up/Down treat it as already at the edge — because it's one logical line — and jump to command history instead of moving the cursor between the wrapped rows.

So the regression is specifically the wrapped-single-line case: the edge check looks at logical lines and ignores visual wrapping. This matches the wrapped-string symptom described in #20328 ("if it's a multiline string that wraps… it just jumps to the previous prompt").

Repro: type one long line with no Enter so it wraps to 2+ visual rows, place the cursor on the second visual row, press Up → jumps to history instead of moving up one visual row. Insert a real newline with Ctrl+J and the same arrows navigate correctly between lines.

Env: macOS (Apple Silicon), Claude Code v2.1.157.

This is driving me crazy! please fix!

<p align="center">Anthropicsieeee!! Pweeeeaaaasee fixie wixie bugsy wugsy! 😭</p>

Also an issue on Ubuntu, VS Code 1.122.1, Claude Code for VS Code 2.1.165

Just lost 20min of careful prompt typing... :-(

bump, keep this alive as I am having this issue in vscode on Windows

PLEASE FIX THIS! I keep loosing 10s of minutes of writing a prompt WITHOUT ANY OPTION TO RECOVER IT. Incredibly annoying and stupid feature

Environment: VS Code extension, Windows 11

Confirming this reproduces, with two details I haven't seen mentioned in this thread yet:

1. There's an undocumented partial-recovery path. After the accidental Up-arrow overwrite (cursor at the top of the draft, one more Up replaces it with the last submitted prompt), pressing Down repeatedly to reach the end of that recalled text, then Down once more, brings the original draft back. So the draft isn't always gone — it seems to still be buffered somewhere, just hidden. (Note: myss reported Ctrl+_ doesn't recover it in VS Code — this Down-arrow path is a different, VS Code-specific mechanism, worth documenting since it's the only workaround that's worked for me.)

2. That recovery path isn't reliable. Sometimes, after the same accidental Up-arrow overwrite, the arrow keys stop responding inside the input box entirely — I can't navigate up, down, or otherwise move the cursor to trigger the Down-arrow recovery. In that state the draft appears to be permanently lost with no recovery path at all.

This suggests there may be two distinct issues layered together: (a) the known silent-overwrite-on-history-recall behavior, and (b) an intermittent secondary state where the input's arrow-key handling wedges after a recall, which is what actually causes unrecoverable data loss rather than just a startling overwrite. Happy to try to narrow down a reliable repro for (b) if useful — it's been inconsistent for me so far.

https://github.com/user-attachments/assets/87401a0b-5193-4f4f-8b55-688309941ff5