[BUG] Paste misplacement: re-pasting text identical to the last collapsed paste expands that old placeholder and moves the cursor there, instead of pasting at the cursor

Status Open
Reported on v2.1.258
Maintainer reply None cached
Activity 0 comments · opened Sep 2, 2026

Summary

If the clipboard still holds the same text as the most recent collapsed [Pasted text #N +M lines] paste, pressing Cmd+V anywhere later in the prompt does not paste at the cursor. It jumps back to the old placeholder, expands it inline, and leaves the cursor there. The "paste again to expand" hint is only shown for 8 seconds, but the behavior itself never times out, so this fires minutes later with no visible hint.

Environment

  • Claude Code 2.1.258, native install, macOS (Darwin 23.6.0)
  • VS Code integrated terminal 1.135.0 (TERM_PROGRAM=vscode), zsh. Not iTerm2.

Steps to reproduce

  1. Paste a multi-line block (more than 3 lines or 800 chars). It collapses to [Pasted text #1 +N lines].
  2. Press Ctrl+J a few times and type several lines of new text. Cursor is now at the end of the prompt.
  3. Wait 10+ seconds so the hint is gone.
  4. Press Cmd+V again with the same clipboard content.

Expected: text is inserted at the cursor (or a second placeholder is minted there).
Actual: cursor jumps back to [Pasted text #1], the placeholder is replaced by the full text inline, and the new text is not inserted where the cursor was.

Why this is confusing

  • The expansion is keyed on content equality with the last minted paste only, not on cursor position or on the hint being visible.
  • The hint disappears after 8 seconds, so the user has no indication the next Cmd+V will be treated as "expand" rather than "paste".
  • If a copy silently fails, the clipboard still holds the previous block and the user has no way to know the paste will teleport. Real-world trigger for this report: Cmd+C in a laggy Chrome tab that has not updated the clipboard yet, then Cmd+V in Claude Code. The user believes they are pasting new content; Claude Code sees the previous block and expands the old placeholder instead.

Ask

One of:

  • Only treat a re-paste as "expand" while the hint is visible (same 8 second window), or while the cursor is adjacent to the placeholder.
  • Otherwise mint a new placeholder at the cursor like the agents view did before 2.1.207.
  • Or expose a setting to disable the re-paste-to-expand gesture (related: #23134).

Not a duplicate of

Please do not auto-close against these. Each was checked and describes a different thing:

  • #15634 / #15636: reports the same symptom ("paste misplacement") but attributes it to iTerm2 escape-sequence handling and was closed stale with no diagnosis. This report is on VS Code's terminal, not iTerm2, and identifies the actual code path in the paste handler, so it is terminal-independent.
  • #15538: Ctrl+O display corruption in iTerm2. Rendering only, never mentions paste.
  • #23134: feature request to disable paste collapsing. Related but different ask. This is a bug in the re-paste-to-expand gesture, which would still exist with collapsing on.
  • #75928: agents-view parity for the same gesture, already fixed. Not this.

Related

  • #23134 (open) option to disable paste collapsing
  • #75928 (closed, fixed 2.1.207) added this same gesture to the agents view
  • #15634 / #15636 (closed as dup, stale) "paste misplacement" in iTerm2, 2025-12-29. Same symptom, blamed on iTerm2, never diagnosed. Likely this mechanism.

View original on GitHub ↗