[BUG] Fullscreen renderer corrupts the SYSTEM-WIDE macOS clipboard (copy/paste breaks in ALL apps), Terminal.app

[treebird7]

⚠️ Severity: system-wide, not app-local

The fullscreen renderer doesn't just break copy/paste inside Claude Code — while CC is running in fullscreen, copy/paste stops working across the entire macOS system, in other applications too (browser, editors, Finder, etc.). The system clipboard is effectively broken for as long as CC is in fullscreen mode.

This is why it's so hard to diagnose: the symptom shows up in unrelated apps, so users spend weeks blaming their OS/terminal/hardware before realizing a backgrounded Claude Code fullscreen session is the cause.

What happens

• Cmd+C (copy) and Cmd+V (paste) fail — both directions — and not only in Claude Code but in all applications while CC runs in the fullscreen renderer.
• Switching to the default renderer with /tui default immediately restores normal system-wide copy/paste.
• Switching back to /tui fullscreen breaks it again.

So the fullscreen renderer is the cause, and the blast radius is the whole OS clipboard, not just CC's UI.

Steps to reproduce

1. macOS, Apple Terminal.app.
2. Run Claude Code in the fullscreen renderer (confirm with /tui → "fullscreen"; it's the default — no CLAUDE_CODE_NO_FLICKER env var needed).
3. With CC running, switch to another app (browser, text editor) and try Cmd+C / Cmd+V there.
4. Clipboard copy/paste is broken system-wide.
5. Back in CC, run /tui default → system clipboard works again everywhere. /tui fullscreen → breaks again.

Expected

Claude Code's renderer must not interfere with the OS-native system clipboard for other applications. Cmd+C/Cmd+V should work everywhere (and inside CC), as they do in the default renderer.

Actual

While CC is in fullscreen, the macOS system clipboard is broken in all apps. Only /tui default restores it.

Workaround

/tui default (gives up fullscreen's flicker-free rendering to get the system clipboard back).

Environment

• Claude Code: 2.1.196
• Terminal: Apple_Terminal 470.2 (Terminal.app)
• OS: macOS 26.5.1 (arm64)
• TERM: xterm-256color
• CLAUDE_CODE_NO_FLICKER: unset (fullscreen is the default renderer in this version)

Notes

Existing related issues are WSL-specific (#64642 docs, #50605 closed WSL2 clipboard mojibake). This is macOS Terminal.app, both-directions, system-wide, and not previously reported for this platform. Given the system-wide impact, this seems higher severity than an in-app rendering quirk.

[treebird7]

Possible root cause (from inspecting the shipped binary)

strings on the 2.1.196 macOS binary surfaces native pasteboard usage:

readClipboard      (×7)
writeClipboard     (×5)
generalPasteboard  (×2)
NSPasteboard       (×2)
changeCount        (×1)

changeCount on [NSPasteboard generalPasteboard] is the canonical property you poll to detect clipboard changes. Hypothesis: the fullscreen renderer polls generalPasteboard.changeCount in a loop (to drive copy-on-select / paste detection). On macOS, frequent generalPasteboard access contends with the system pasteboard daemon (pasteboardd), which degrades copy/paste system-wide across all apps — not just inside Claude Code.

This fits the observed behavior precisely:

• breaks copy/paste in all apps while CC runs in fullscreen,
• instantly fixed by /tui default (the default renderer presumably doesn't run that poll loop),
• re-breaks on /tui fullscreen.

Suggested directions: throttle/debounce the changeCount poll, only read generalPasteboard on an explicit copy/paste action rather than on a timer, or gate the poll behind the copyOnSelect setting so disabling it stops the loop.

(Can't confirm the loop frequency from a compiled binary — offered as a lead, not a certainty.)

[treebird7]

Update: it's intermittent, and toggling the renderer clears it

Follow-up after more testing — this is not a constant "fullscreen always breaks the clipboard" fault. It's intermittent:

• The system-wide clipboard breakage appears after some time/usage in the fullscreen renderer.
• Toggling the renderer — /tui default then back to /tui fullscreen — clears it, and copy/paste works again system-wide (including back in fullscreen).
• So you don't necessarily have to abandon fullscreen; a renderer round-trip recovers it.

This suggests a recoverable state wedge rather than a continuous problem — something gets the macOS pasteboard (generalPasteboard / pasteboardd) into a stuck state, and restarting the renderer releases it. That fits the earlier hypothesis (native NSPasteboard.changeCount access) but points more at a lifecycle/state bug than a tight always-on poll: it wedges occasionally and a renderer restart resets whatever's held.

Still watching for the pattern of recurrence (how long / what triggers the wedge). Will add more if a reliable trigger emerges.

Environment unchanged: macOS Tahoe 26.5.1 (Apple Silicon), Terminal.app, Claude Code 2.1.196.

[treebird7]

Negative result: disabling copy-on-select does NOT fix it

Tested two would-be mitigations to keep fullscreen without the clipboard breakage:

1. copyOnSelect:false in user settings — rejected by settings validation; it is not a settings field in 2.1.196 (schema Unrecognized field). So there is no settings-file lever.
2. Toggling "Copy on select" OFF via /config — applied, but the system-wide clipboard breakage persists in the fullscreen renderer.

So copy-on-select is not the trigger. This narrows the cause: it's the fullscreen renderer's pasteboard handling itself (the generalPasteboard / changeCount access noted earlier), independent of the copy-on-select feature.

Net for macOS users right now: the only reliable workaround remains /tui default (give up the flicker-free renderer to keep a working system clipboard). The renderer-toggle recovery (/tui default then /tui fullscreen) still clears a wedge temporarily, but nothing keeps fullscreen clipboard-safe.

[ronny-rentner]

Confirming this is cross-platform, not a Terminal.app quirk — hit a related breakage on Linux/Wayland.

Environment: Debian 13 (Wayland), GNOME Terminal, Claude Code v2.1.199, TERM=xterm-256color.

Since the fullscreen renderer became the default (v2.1.187), mouse capture overrides the terminal's native click-and-drag selection, which broke my copy/paste workflow. The suggested escape hatches make it worse, not better:

• CLAUDE_CODE_DISABLE_MOUSE=1 restores native selection but breaks the scroll wheel entirely — in the alternate screen there's no native scrollback to fall back on, so with mouse events disabled nothing scrolls.
• The in-app auto-copy-on-select didn't reliably reach my clipboard despite wl-copy being installed and working.

So on Linux the choice under the fullscreen default is: broken selection or broken scrolling. The only real fix was /tui default, same as reported above for the macOS clipboard corruption.

Given that selection/clipboard/scroll regressions are now confirmed on macOS (system-wide clipboard, this issue), Linux/Wayland, and WSL, could the fullscreen default be reverted to opt-in until the platform matrix is clean? Basic terminal interactions breaking by default is a hard trade for flicker-free rendering, and manual smoke-testing copy/paste across the common emulators would have caught all of these before the default flip.

[web3dev1337]

Bumping, yes been getting this I think, sometimes when I copy paste, it has other claude conversation stuff in it.