## Description Claude Code's TUI writes selected text to the system clipboard on every re-render during streaming, flooding clipboard managers (e.g. CopyClip, Maccy, Paste) with hundreds of partial text fragments. ## Reproduction 1. Open Claude Code CLI in a terminal (tested in Warp on macOS) 2. Have a clipboard history manager running (e.g. CopyClip) 3. Select some text in the Claude Code TUI (mouse click-drag) 4. Ask Claude something that produces a streaming text response 5. Check clipboar

TUI selection spams clipboard on every render during streaming

Status Open

Maintainer reply None cached

Activity 5 comments · opened Apr 1, 2026

Description

Claude Code's TUI writes selected text to the system clipboard on every re-render during streaming, flooding clipboard managers (e.g. CopyClip, Maccy, Paste) with hundreds of partial text fragments.

Reproduction

Open Claude Code CLI in a terminal (tested in Warp on macOS)
Have a clipboard history manager running (e.g. CopyClip)
Select some text in the Claude Code TUI (mouse click-drag)
Ask Claude something that produces a streaming text response
Check clipboard history — it will contain dozens/hundreds of entries with partial text fragments, space-padded to terminal width

Root cause (from binary analysis)

The clipboard write function (BM in the minified bundle) fires during TUI re-renders when a text selection is active. Each streaming chunk triggers a re-render, which re-syncs the selection to clipboard.

Additionally, the function writes to clipboard via two mechanisms simultaneously:

OSC 52 escape sequence (terminal clipboard protocol)
pbcopy subprocess (macOS) / xclip/xsel (Linux)

This means each re-render may produce 2 clipboard writes.

Evidence

Pasteboard monitoring with a Swift script showed:

Zero clipboard writes at idle (no Claude streaming)
Zero clipboard writes during tool calls (no visible text output)
5+ writes per 20 seconds during text streaming, containing fragments of the streamed response
Zero clipboard writes during non-Claude terminal output in the same terminal (Warp)

The macOS pasteboard change count reached 4996+ during a single session.

Expected behavior

Clipboard should only be written on explicit user action: /copy command, Cmd+C, or equivalent
TUI re-renders should not re-sync selection to clipboard
If selection-to-clipboard is intentional, it should be debounced during streaming (e.g. only write on selection end, not on every frame)
Consider not using both OSC 52 and pbcopy simultaneously (double-writes)

Environment

Claude Code CLI (Bun binary, installed via ~/.local/bin/claude)
macOS (Darwin 25.3.0, arm64)
Terminal: Warp
Clipboard manager: CopyClip

🤖 Generated with Claude Code

View original on GitHub ↗

5 Comments

ThatDragonOverThere · 4 months ago

Confirmed on v2.1.92 (Windows 11, Windows Terminal). The OSC 52 clipboard operation is leaking visibly into terminal output as: 'sent 2269 chars via OSC 52 · check terminal clipboard settings if paste fails'. Appears inline in the conversation output during streaming. Not a background event — it's printing to the visible terminal mid-response.

MAlshehri · 4 months ago

hitting a variant of this. cmd+c on text in claude code leaves the clipboard completely empty — zero bytes, not garbled. cmd+v in other apps does nothing. reproduces on iterm2 and wezterm, so it's not a terminal thing.

right after cmd+c:

$ pbpaste | wc -c
0
$ osascript -e 'clipboard info'
«class utf8», 0, «class ut16», 2, string, 0, Unicode text, 0

all text flavors registered, all empty (the 2 bytes on utf16 is just a BOM).

feels like the same BM re-render sync described above, but firing right after the selection clears — OSC 52 + pbcopy both emit empty and wipe the bytes the terminal just wrote. copy into claude code from other apps still works fine; only copy out is broken.

workaround: alt+drag (block select) then cmd+c works (supported in maccy with paste without formatting option selected).

env: claude code 2.1.118, macOS 26.4.1, wezterm 20240203 (also repros on iterm2).

udisun · 3 months ago

Confirming this issue is still active as of May 2026.

Claude Code: 2.1.148
macOS: 26.5 (Build 25F5042g)
Hardware: MacBook Pro (Mac16,7), Apple M4 Pro, 48GB, arm64

The macOS TCC dialog "2.1.148" would like to access data from other apps spams on every streaming response. Clicking Allow does not persist — a new dialog immediately appears from a different --bg-spare daemon instance. The permission dialog shows the version number as the app name (e.g. "2.1.148") rather than "Claude" because the binary is a bare Mach-O at ~/.local/share/claude/versions/2.1.148 without an app bundle/Info.plist.

The multi-instance spawning of --bg-spare daemons compounds the issue — each pre-warmed spare process independently triggers the TCC prompt, making it impossible to resolve with a single Allow click.

rollingferret · 2 months ago

Confirming this on Linux + Kitty terminal. Selecting any text causes Ctrl+V to paste accumulated session history instead of the selection. The race between Ink's re-render writes and paste timing causes intermittent behavior — sometimes correct content, sometimes hundreds of lines. Middle-click (PRIMARY buffer) is also broken due to mouse reporting mode intercepting the event. Workaround that works for me: CopyQ clipboard manager — its history lets you retrieve the actual selection even after Claude Code overwrites CLIPBOARD.

mhaslinsky · 1 month ago

Still a thing in July, and no option to disable..