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

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.)

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.

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.

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.

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