Claude text editor in terminal back space doesnt work sometimes

Is this in VS Code terminal? Do you have an exact repro?

For me when I'm using claude code in a terminal (via tmux and ssh) and I press backspace too quickly (or just hold it down) it'll stop working after a couple backspaces. The 'pipe' that forms the right side of the prompt box also starts moving (like I'm pressing delete instead of backspace). Though of course that pipe doesn't normally move, only when it gets into this stuck mode.

!Image

It's not just a visual artifact, when I press enter, the LLM gets prompted by all the 'a' that are shown. The ssh is on a relatively high latency (165ms), I think that may have something to do with it, though this behaviour doesn't happen with any of my other apps.

I find this _all_ the time when using via Blink -> mosh -> tmux on iOS.

Would love to be able to turn off the fancy little input box and just use regular readline until this is fixed.

!Image

Same bug on Visual Studio Code and when I'm using the terminal. If it helps, I'm using WSL2 on Windows. It has been like this since the public release.

I am encountering this as well. I am running Claude Code via docker-run, launched from a Gnome terminal. TERM is set to xterm-256color.

This is very annoying. Using Windows Terminal to ssh to Debian VM.

Some more interesting data: Often when this happens to me, I find that the first backspace causes the vertical line on the RHS of the input field to 'jump back' about N characters, and then I need to press backspace N times (moving the vertical line one character to the right each time) for backspace to work correctly.

Also impacts ^db in vim mode and ^W. Only half the word will be deleted.

I am also affected by this issue - It seems to affect WSL - but it happens no matter what terminal client i use; git bash, powershell, wsl.

This happens in every environment I use Claude Code in. Its annoying and flow-breaking for me. The less terminal/TUI fluent users in my group are really going to struggle with it.

Same here. I'm using it in the Windows Terminal running Bash via WSL2 and I thought it might be something that is lost in translation but it's reassuring to hear that this issue is independent from that.

So I have tried this via VMware guest OS (in to ubuntu guess), and am now using nomachine to a separate computer, as well as when I am natively on that computer in a terminal window. This happens. The only way around it is I use arrow keys to go up.. back.. then down, and then use DEL to delete. Then it starts to work a bit (backspace does) again.
I wonder if this is related to the weird long context entire window refresh issues I filed a bug for as well. Seems like some sort of similar GUI/text refresh issue. (this)

Just piling onto this - its quite a distracting bug that cuts into productivity and seems like it would be low hanging fruit for a fix.

I once experienced the same glitch. The glitch disappeared after I deleted ~/.claude and ~/.claude.json to resolve an unrelated issue. How strange.

Possibly related, sometimes after paste (of text less than the threshold to collapse the paste) the cursor is in the wrong position. It's in the middle of the pasted text instead of at the end.

My hunch is this issue is similar: the input text area thinks the cursor is in the wrong place. It thinks it is at the beginning, so you can't backspace.

I once experienced the same glitch. The glitch disappeared after I deleted ~/.claude and ~/.claude.json to resolve an unrelated issue. How strange.

As a data point this did not clear it up for me.

In the same boat

I can reproduce this reliably by using "swipe typing" on mobile. I cannot reproduce it in the Gemini CLI, though apparently the two both use React Ink for UI.

This happens to me when using mosh with tmux with iterm2. I can just never backspace.

Same issue. When this happens, the backspace sporadically works for me. For example I might hit backspace 6 times with no effect, then the 7th time I hit backspace it works. It seems almost random.

For me when I'm using claude code in a terminal (via tmux and ssh) and I press backspace too quickly (or just hold it down) it'll stop working after a couple backspaces. The 'pipe' that forms the right side of the prompt box also starts moving (like I'm pressing delete instead of backspace). Though of course that pipe doesn't normally move, only when it gets into this stuck mode. !Image It's not just a visual artifact, when I press enter, the LLM gets prompted by all the 'a' that are shown. The ssh is on a relatively high latency (165ms), I think that may have something to do with it, though this behaviour doesn't happen with any of my other apps.

Very well explained, I see the same with the vertical pipe from the input frame moving when I press backspace.

same problem - i running athena os (archlinux) using the claude extension in vscode in vmware

Workaround: Backspace Issues with Claude Code over SSH/tmux

Problem: When using Claude Code over SSH (especially high-latency connections), the backspace key stops working after a few presses. The cursor behavior becomes erratic and characters aren't properly deleted.

Root Cause: Terminal input handling conflicts between Claude Code, SSH, and tmux with high latency (165ms+).

Solution: Run Claude Code locally in WSL instead of over SSH.

Steps:

1. Install WSL on your Windows machine:

wsl --install Ubuntu

2. Set up Claude Code in WSL:

# Install Node.js 20+
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

# Install Claude Code
sudo npm install -g @anthropic-ai/claude-code

3. Access your projects locally:

• Store projects in WSL: ~/projects/
• Open terminal locally (no SSH needed)
• Run claude directly in WSL

4. VS Code Integration (if needed):

cd ~/projects/myproject
code .  # Opens VS Code connected to WSL

5. Windows File Access:

• Your files are at: \\wsl$\Ubuntu\home\<username>\projects\
• Can map as network drive for easier access

Benefits:

• ✅ Backspace works perfectly - no more stuck keys!
• ✅ Much faster response time (no network latency)
• ✅ No terminal input conflicts
• ✅ Git operations are blazing fast (5-10x faster than Windows mounts)
• ✅ Console/terminal works flawlessly
• ✅ Better overall Claude Code experience

Why This Works:

By running locally in WSL, you eliminate the SSH layer that was causing the input handling issues. The terminal input goes directly to Claude Code without any network delays or protocol translations.

---

Result: "oh I suffered a lot, and now when running from under WSL it's completely gone and it's much much faster" - exactly what we want to hear! 🎉

Hmmm. This happened to me through vscode extension so I think there is a larger underlying issue.

Sent with Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Pavel Zhur @.*>
Sent: Thursday, July 10, 2025 7:41:18 PM
To: anthropics/claude-code @.*>
Cc: ghost-ng @.>; Comment @.>
Subject: Re: [anthropics/claude-code] Claude text editor in terminal back space doesnt work sometimes (Issue #1853)

[https://avatars.githubusercontent.com/u/190321?s=20&v=4]pavel-zhur left a comment (anthropics/claude-code#1853)<https://github.com/anthropics/claude-code/issues/1853#issuecomment-3059547269>
Workaround: Backspace Issues with Claude Code over SSH/tmux

Problem: When using Claude Code over SSH (especially high-latency connections), the backspace key stops working after a few presses. The cursor behavior becomes erratic and characters aren't properly deleted.

Root Cause: Terminal input handling conflicts between Claude Code, SSH, and tmux with high latency (165ms+).

Solution: Run Claude Code locally in WSL instead of over SSH.

Steps:

1. Install WSL on your Windows machine:

wsl --install Ubuntu

1. Set up Claude Code in WSL:

Install Node.js 20+

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Install Claude Code

sudo npm install -g @anthropic-ai/claude-code

1. Access your projects locally:

• Store projects in WSL: ~/projects/
• Open terminal locally (no SSH needed)
• Run claude directly in WSL

1. VS Code Integration (if needed):

cd ~/projects/myproject
code . # Opens VS Code connected to WSL

1. Windows File Access:

• Your files are at: \\wsl$\Ubuntu\home\<username>\projects\
• Can map as network drive for easier access

Benefits:

• ✅ Backspace works perfectly - no more stuck keys!
• ✅ Much faster response time (no network latency)
• ✅ No terminal input conflicts
• ✅ Git operations are blazing fast (5-10x faster than Windows mounts)
• ✅ Console/terminal works flawlessly
• ✅ Better overall Claude Code experience

Why This Works:

By running locally in WSL, you eliminate the SSH layer that was causing the input handling issues. The terminal input goes directly to Claude Code without any network delays or protocol translations.

________________________________

Result: "oh I suffered a lot, and now when running from under WSL it's completely gone and it's much much faster" - exactly what we want to hear! 🎉

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/1853#issuecomment-3059547269>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFCJNL54ANHV2FNZY7575VD3H32Z5AVCNFSM6AAAAAB65MQ65OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANJZGU2DOMRWHE>.
You are receiving this because you commented.Message ID: @.***>

# Workaround: Backspace Issues with Claude Code over SSH/tmux A bunch of AI generated slop

I don't think "stop using tmux or running over ssh" is a particularly useful solution for the bug that Claude Code has poor performance over tmux.

No other common terminal applications seem to have this problem. Gemini CLI does not have this problem, nor does Aider.

I was annoyed enough by this non-answer that I had Gemini write a silly little Python script to work around the problem by throttling backspaces to 10 per second. What's that thing about "the best way to get the right answer on the internet" again?

It fixes the issue for me, YMMV.

FWIW I tried waiting only _between_ backspaces, and that didn't fix the problem for the last backspace. So it seems like if you press a key shortly _after_ a backspace, the backspace doesn't work.

https://gist.github.com/werdnum/0f4e8d0b806da91fafc8d4eabce40a1c

Try it with uv run https://gist.githubusercontent.com/werdnum/0f4e8d0b806da91fafc8d4eabce40a1c/raw/829a35f41886050c0860e49851c148f4738fd489/throttle_backspaces.py claude

i found this in the claude logs:
i want you to relook at these commands after a successful

<img width="764" height="30" alt="Image" src="https://github.com/user-attachments/assets/9dfbddf3-e5ef-4935-a783-a59e1b2e4f1a" />

I was able to get this with claude-conversation-extractor. I noticed that the arrow keys still work, so I can move the cursor and the delete instead of backspace

Same issue on Ubuntu 22.04 when using Claude Code within a VSCode terminal. As a paying user (Max plan) this is frustrating and slows down my productivity.

Any fix? Any response for devs? WTF!!!

So.. it seems to work for me now. I am able to hold it down and go back a few lines, and I am not seeing it get stuck any more. This is on Ubuntu though. Not sure about WSL or Mac.

@spirefyio I just tested on WSL, and it's not working. I am on version: 1.0.61. There have been slight improvements, but it is still happening if I hold the Backspace key for a while.

If you're on WSL this is easily explained - microsoft uses 9P for windows mounts, which slows shells down to a crawl whenever any windows directories are accessed, and this additional latency messes with Claude Code CLI updates.

You might say "I'm not accessing any windows directories", but microsoft doesn't care. Try this:
echo $PATH | tr ':' '\n' | grep /mnt

It's f...ing default behaviour for the windows path to be auto-prepended to your linux path. If you need it or not. Let that sink in.

Just run this command:

echo -e "\n[interop]\nappendWindowsPath = false" | sudo tee -a /etc/wsl.conf > /dev/null

and Claude Code will be snappy as it should be again (given nothing else is messing with your shell)

edit: don't forget to restart WSL after.

1.0.61 and PATH fix still do not work for me.

This has also been a major problem for me ever since I started using it. Typically I use it on WSL2 in windows running Ubuntu 22.04, and using the vscode integration, which seems to be just a terminal launched to the side in vscode. Often starting a new session temporarily fixes it (but not always), and by the time I have a fair bit of context window used, it becomes impossible to delete more than one or two letters of my current prompt again. The only way I can deal with it is by writing all prompts in a separate editor and pasting them into the command box. It is by far the single biggest frustration and hurdle to using Claude Code effectively.

Seeing the same thing. Claude Code on Mint Linux running inside VS Code. Periodically, the backspace key stops working and instead, a "shadow" cursor (like, a fragment of the cursor) instead moves one space to the right for each keypress. Eventually, that shadow cursor seems to start moving left again. The problem is sporadic, but started only fairly recently for me. The up arrow/down arrow on a multiline entry can help, sometimes evne restoring backspace for a while. Often, I end up ctrl-c'ing the whole line and retyping. Very frustrating indeed.

I have changed to a most-recent-gen macbook, and i still encounter this issue, but much less often. Something to do with slow terminals I think.

definitely an underlying issue, holding backspace for me via the vs plugin adds loads of ⌂ rather than deleting anything, annoying.

Just in case it might spur at least a response from anthropic (spoiler alert, it won't), this issue on it's own has made me cancel my max and moved to a different tool.

Ctrl+V doesn't work in this "mode" (I thought I had a problem with my voice typing software that sends text with that, but no). And in my case backspacing actually ADDS letters back. 😅 Windows terminal, VS Code. It is fine with remote workspaces into Ubuntu over SSH.

Piling on too, same issue. Didn't use to happen though, started a couple of weeks ago. It is particularly bad when just starting Claude, and it seems like it gets better, though not perfect, over time. So maybe its related to loading history/configuration or something? WSL in Ubuntu 24, Windows Terminal

i switched to windows vscode with claude extension and it works again. on linux, I had to use separate terminals (no through vscode - although it was still buggy)

Hey everyone!

This is also a bug that's really annoying for us internally, and we appreciate your patience on this. We want it fixed also. I _provisionally_ think I _might_ have chased down the root cause today, and I put in a fix. It didn't make today's release, but it should be in our next one. I'm going to leave the issue open for a little bit until we're confident that the fix is working on all platforms and in all of the scenarios that folks are facing here (it does fix the reproducers that we were able to create internally!), but 🤞 hopefully this is finally fixed!

I've had the same issue on macOS using the Wezterm emulator with ZSH since the beginning. Almost as annoying as the lying and the cheating that sonnet and opus do when they can't figure something out in a couple tries.

If you guys are still having this issue, here's how chatgpt5 helped me fix it

We’re fixing it by forcing Claude to run in a clean pseudo-TTY with script, setting a correct erase key (stty erase ^?), and disabling prompt_toolkit’s CPR feature (PROMPT_TOOLKIT_NO_CPR=1). This bypasses the bug in WSL/Windows Terminal that breaks Backspace handling.

Run which claude to find the full path to your Claude executable (for example /home/username/.npm-global/bin/claude).
Replace <PATH> in the script below with that path.

cat > ~/claude-safe <<'EOF'
#!/usr/bin/env bash
env -i HOME=$HOME PATH=$PATH TERM=xterm-256color \
  /usr/bin/script -q /dev/null -c "stty erase '^?'; PROMPT_TOOLKIT_NO_CPR=1 <PATH>"
EOF

chmod +x ~/claude-safe

Run it with:

~/claude-safe

If you want to run it simply by typing claude-safe, add this alias to your shell config:

echo "alias claude-safe='~/claude-safe'" >> ~/.zshrc
source ~/.zshrc

The fix for this went into 1.0.92 about half an hour ago. Please let us know if you're still seeing this in that release or later! Thanks for your patience!

Still getting a bit of stuttering when typing text or deleting (which isn't there with the safe wrapper above) but the core issue is not there anymore!

Hey all.. so reading some of the comments.. I have seen it mostly "fixed" in that it DOES seem to allow me to hold down BS sometimes and delete a few lines no problem. HOWEVER.. sometimes I see the strange right side issue where the cursor shows up on the far right side of the line if I hold the BS down. If I just tap it.. it seems to work so far. I haven't noticed it for a few weeks now not working that way. I'll try it out some more the next few days and respond back if I see anything jarring.
Thank you @dhollman Great work.

I'm still getting it. macos wezterm zsh

<img width="2576" height="168" alt="Image" src="https://github.com/user-attachments/assets/a4f4d3d9-67e6-47a3-a50f-78ba408ab999" />

The issue is better, but far from gone - the prompt editor still freezes quite often. VSCode on MacOS, with remote docker session running Claude 1.0.98 under Ubuntu Linux.

It looks like the issue now might be that when a bash command is running, then all keystrokes are getting lost - as opposed to just delayed, which is somewhat of a regression :(

Updating Claude Code wasn't enough in my case. Things only got better after I removed all the claude-related files in the home directory and started a new session. I'm guessing having some bad state (or too many conversations) in history somehow triggering this problem.

Facing same issue in VS code,The backspace seems to glitch out the whole text when trying to delete the previous text and most importantly it happens when the text is too long than the window.

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.

Confirming the backspace issue persists in v2.0.72. When holding backspace, it works for one character then inserts U+0008 control characters instead of continuing to delete. Currently working around it with Ctrl+G to cancel input and retry. This is a flow-breaking issue that affects productivity.

Confirm I have this same issue in Claude Code 2.1.7.

Occurs when running claude in VS Code terminal pane, Win 11, Git Bash.

Interestingly, I've never had it occur using Git Bash via Windows Terminal - only seen it in the VS Code terminal pane.

Same problem: pressing backspace often has no effect.
2.1.15 (Claude Code) in iTerm2 on MacOS 15.6

Suddenly became a problem for me v2.1.72. Very difficult to work when your backspace key stops working. I actually thought it was my keyboard for awhile.

issue for me too. very annoying, I noticed that space also stops working too. Not sure if anyone else has that issue too. Restarting vscode seems to fix it though.

This intermittent backspace issue is related to how the TUI input handler processes keyboard events — especially when there's rendering activity happening simultaneously.
Workaround 1 — Use Ctrl+H instead of Backspace:
Ctrl+H sends the same character code as Backspace (ASCII 8) but may be handled differently by your terminal. Some users report it's more reliable when Backspace stops responding.
Workaround 2 — Use Ctrl+W to delete words:
Instead of character-by-character deletion:

• Ctrl+W — delete the last word
• Ctrl+U — delete from cursor to beginning of line
• Ctrl+K — delete from cursor to end of line

These readline shortcuts are often more reliable than Backspace in Ink-based TUIs.
Workaround 3 — Terminal settings:
Check your terminal's key mapping for Backspace:

• iTerm2: Preferences → Profiles → Keys → check that Backspace sends ^? (ASCII 127), not ^H (ASCII 8)
• Ghostty: Should work out of the box
• Windows Terminal: Ensure "Backspace" key is mapped to \x7f

Workaround 4 — Wait for rendering to finish:
The bug often triggers during active rendering (streaming output, tool calls). Waiting a moment after output stops before pressing Backspace may avoid the issue.
Workaround 5 — Compose externally:
For longer prompts, type in your text editor, copy, and paste into Claude Code. This avoids the TUI input entirely.