[BUG] Terminal Paste Corruption from Bracketed Paste Mode

Same here

Dup of #3007 ? FWIW you can temporarily fix this by typing this into the shell

printf '\e[?2004l'

Might want to add that as an alias...

Same here!
Here's how to use @jscalo's workaround automatically.
In your .bashrc put:

claude() {
    command claude "$@"
    printf '\e[?2004l'
}

@thomasnormal This little function is awesome, thanks! Totally fixed it on my end.

I'm experiencing similar bracketed paste mode issues in v2.0.59 when using voice-to-text accessibility software (Handy).

The terminal scrollback clearly shows [201~ (the paste END marker) appearing raw in the input prompt, indicating the bracketed paste sequence isn't being properly consumed. After several paste attempts, the CLI hangs permanently and requires kill -9.

Documented with timestamps and process diagnostics in #13183.

This also affects PowerShell Core in Ghostty. It has a slightly different effect than the original report above. It prefixes the pasted text with 200~ (instead of 00~) and suffixes it with 201~ (instead of 01~).

i.e. pasting in the URL to this issue after exiting Claude Code:

200~https://github.com/anthropics/claude-code/issues/3134201~

Version info:

• Claude Code 2.0.64
• PowerShell Core 7.5.4
• macOS 26.1
• Ghostty 1.2.3

Issues in iTerm too. This is extremely annoying. The alias fixes it, but sheesh this needs to be fixed.

After modifying .bashrc didn't work, I turned on cursor's settings: Integrated: Ignore Bracketed Paste Mode，successfully solved the problem!

This issue is still happening with Claude Code v2.0.76.

The fix should be straightforward:

1. When starting Claude Code, query the current bracketed paste state (before setting it).
2. When exiting Claude Code, restore the bracketed paste to the original state.

This issue is still happening with Claude Code v2.0.76. The fix should be straightforward: 1. When starting Claude Code, query the current bracketed paste state (before setting it). 2. When exiting Claude Code, restore the bracketed paste to the original state.

@archer-eric I was able to resolve the issue by using the suggested alias here. You might as well save yourself the headache of waiting for this issue to get resolved.

@archer-eric I was able to resolve the issue by using the suggested alias here. You might as well save yourself the headache of waiting for this issue to get resolved.

I had my own bash function that did something similar, but it keeps getting in the way of Claude Code itself believing that it should be an alias instead of a function. I think it sometimes interferes with automatic upgrades (which seems to keep changing in approach).

It would be fantastic if Anthropic could simply restore the setting that Claude Code is currently changing while it runs.

Heads up for anyone else finding this before it’s fixed: this hook will clear bracketed paste mode on exit:

"SessionEnd": [
    {
      "matcher": "",
      "hooks": [
        {
          "type": "command",
          "command": "printf '\\033[?2004l' > /dev/tty"
        }
      ]
    }
  ]

As far as I can tell, this appears to have been fixed in or before Claude Code 2.1.4 (running Ubuntu 24.04.3 LTS).

Can anybody else confirm?

I don't see anything related in recent /release-notes.

version 2.1.14 - has no issues (using till the fix rollout), 2.1.16 introduced this issue (could be 2.1.15 - didn't had 2.1.15, can't confirm).

@benjaminjackson fix didn't seem to work on my setup: WSL 2 Linux Debian.

For me, the problem exists only in the terminal in the Cursor code editor. For the native Mac terminal, pasting even long texts works fine.

Cross-posting: Paste truncation is STILL broken — 24 issues, 8 months, zero staff responses

This bracketed paste bug is part of a family of 5 distinct paste-handling failures in the Ink TUI, all unfixed after 8 months. I've documented the full scope on #5017 including:

• Silent percentage-based truncation — not a fixed buffer, content loss is proportional (~22% dropped on my latest test)
• Node.js v24.14.0 does NOT fix it (tested today, Mar 3 2026, v2.1.62)
• 24 related issues across this bug family, zero Anthropic staff responses on any of them
• Mid-text corruption (#24431), paste race conditions (#28137), complete hangs (#22226), and this bracketed paste cleanup failure

The bracketed paste mode corruption you reported in July 2025 — 8 months ago — is still happening. The \e[?2004h / \e[?2004l lifecycle management in the Ink TUI has never been fixed.

Every user's terminal is left in a corrupted state after Claude Code exits, and every paste operation silently loses content. This is a data integrity crisis that Anthropic has completely ignored.

See #5017 for the full analysis.

Cursor 2.6.19 integrated terminal: paste freeze persists despite all known workarounds

Adding data from extensive debugging on Cursor's integrated terminal.

Environment

• macOS 26.3.1 (Darwin arm64 25.3.0), Apple Silicon
• Cursor 2.6.19 (Electron 39.4.0, Chromium 142.0.7444.265, Node 22.22.0)
• Bundled node-pty: 1.1.0-beta42, @xterm/xterm: 5.6.0-beta.99
• Claude Code: 2.1.76
• Shell: zsh

What I tried (all failed to fix the freeze)

1. ignoreBracketedPasteMode: false (confirmed)
2. printf '\e[?2004l' wrapper in .zshrc + SessionEnd hook
3. GPU acceleration off, smooth scrolling off, tab animation off
4. terminal.integrated.enablePersistentSessions: false + persistentSessionScrollback: 0
5. terminal.integrated.scrollback: 500
6. ENABLE_IDE_INTEGRATION=false, unsetting CLAUDE_CODE_SSE_PORT and VSCODE_INJECTION
7. Claude Code settings: terminalProgressBarEnabled: false, prefersReducedMotion: true, spinnerTipsEnabled: false

Key finding: Claude Code process is NOT frozen

Stack sampling (sample <pid> 3) during freeze shows:

• 98% of samples in kevent64 — the Claude Code Node.js process is idle, waiting for events
• 2% in StreamBase::Write — occasional write attempts
• The process is responsive; the Cursor terminal renderer/PTY layer is what's blocked

stty -a on the frozen terminal's tty shows raw mode is active (-icanon -isig -iexten -echo), which is expected for an Ink TUI app.

ptyhost.log before persistent sessions were disabled

Persistent process "1": Replaying 1018 chars and 1 size events

After disabling persistent sessions, this log entry disappeared but the freeze remained.

Conclusion

This is not a bracketed paste mode restoration issue in the Cursor case. The freeze happens during paste, not after exit. The Claude Code process itself stays responsive — the bottleneck is Cursor's PTY/xterm.js layer choking on the paste input volume.

Cursor's repo has issues disabled, so this can only be tracked here. Likely related to their bundled node-pty 1.1.0-beta42 and xterm 5.6.0-beta.99.

Same terminal, same paste content works fine in VS Code, iTerm2, and Terminal.app.

If you're still hitting this, VoiceInput-Patch can help as a workaround. It's a macOS menu bar app that intercepts Cmd+V in terminals and re-types clipboard content char-by-char via CGEvent Unicode key events — the terminal receives keyboard input instead of a paste, so bracket paste mode is never triggered.

Reproducing on SSH + tmux + voice-to-text (OpenWhispr)

Environment:

• Windows Terminal → SSH → Debian 13 LXC → tmux 3.4 → Claude Code 2.1.97
• tmux extended-keys on (CSI u protocol)
• OpenWhispr (voice-to-text tool, uses Ctrl+Win hotkey, pastes via clipboard)

Symptoms:

• Input prompt blocks completely — no keystrokes accepted. Happens on ~80% of prompts
• ESC ESC unblocks input but leaves 201~ residue (bracketed paste end-marker)
• Ctrl+V also unblocks (readline lnext resets parser state)
• Happens with both voice-to-text paste AND pure keyboard input
• [?2004l leaks into prompt text when disable-code is sent externally

Analysis:
The TUI enables bracketed paste (ESC[?2004h) but the parser gets stuck waiting for the end-marker, especially when:

1. extended-keys on is active (CSI u sequences compete with bracketed paste CSI sequences in the same buffer)
2. Title update OSC sequences interleave with paste sequences (set-titles on)

Disabling xterm-keys on (which conflicts with extended-keys on) reduced frequency but did not eliminate the issue. External printf '\e[?2004l' is ineffective because the TUI re-enables bracketed paste mode.

Workaround: ESC ESC to break the stuck parser. The previously entered/dictated text is preserved in the prompt — it does not need to be re-entered. The only cleanup needed is removing the trailing 201~ residue (bracketed paste end-marker) before submitting.

Related: #13183 (voice-to-text accessibility tools), #43169 (tmux extended-keys + paste)

New data point: OSC 10 foreground color query response leaking into input buffer

Observing a related symptom: the string 10;rgb:cccc/cccc/cccc occasionally appears as literal text in the Claude Code input buffer.

This is an OSC 10 response — the terminal reporting its current foreground color in reply to a \e]10;?\a query. The TUI parser does not consume this escape sequence response, so it leaks into the text input as visible characters.

This appears to be the same root cause family as the Bracketed Paste Mode 201~ residue previously reported in this issue — terminal escape sequence responses that arrive asynchronously and are not recognized/consumed by the TUI input parser.

Environment:

• Claude Code in tmux over SSH
• Host: Debian 13 (Trixie) LXC container
• Terminal: various (issue reproduces across terminal emulators)

Frequency: Occasional. Reduced after adding automatic-rename off and xterm-keys off to tmux.conf (which reduces the number of terminal queries tmux issues), but not eliminated. The underlying issue is that the TUI parser doesn't handle OSC responses arriving in the input stream.

01~ and more hex characters appear

upvote

Environment:

• Claude Code 2.1.210
• tmux 3.5a,
• foot 1.27.0 (Wayland)
• Arch Linux
• TERM=xterm-256color.

Symptom: pasting multi-line text into Claude Code inside tmux (extended-keys on) doesn't just drop newlines, each one is replaced with a literal j. Pasting in Claude Code outside of tmux, there is no issue.

For example when pasting some python code:

• Expected:

number = 15
if number > 0:
  print("The number is positive")

• Actual:

 number = 15jif number > 0:j  print("The number is positive")

Isolating it:

• wl-paste shows the clipboard itself has correct \n bytes.
• Feeding that same content via tmux paste-buffer -p straight into a fresh claude instance comes through clean, so the corruption happens in Claude Code's own paste handling, not the terminal/clipboard.
• Pasting into plain zsh in the same tmux pane is unaffected, only Claude Code corrupts it.
• extended-keys off (+ tmux kill-server, since a live set-option doesn't clear tmux's cached capability negotiation) fixes it.
• But it's not csi-u-specific: extended-keys on with extended-keys-format xterm reproduces the same corruption. So the trigger is extended-keys being on at all, not the wire format.

The catch: extended-keys on is also required for tmux to relay the CSI-u sequence my terminal sends for Shift+Enter. This means I either set extended-keys on to make Shift+Enter work, or I remove it to make user text is pasted properly.