GNOME Terminal: output is uncopyable (mouse capture + alternate screen), and OSC 52 copy reports success when the terminal discards it

What happened

Copying text out of an interactive Claude Code session is effectively impossible in GNOME Terminal, especially over SSH. Three separate behaviors combine, and one of them reports success while silently doing nothing.

1. Mouse reporting captures the drag. Claude enables ?1000h / ?1006h. A normal click-drag is delivered to Claude rather than creating a terminal selection. On mouse-up the highlight disappears and Claude reports copying via OSC 52. Holding Shift bypasses this and produces a real VTE selection, but VTE does not autoscroll on a Shift-modified drag, so the selection is capped at the visible screen.

2. OSC 52 copy reports success even when the terminal discards it. Claude prints e.g. sent 2088 chars via OSC 52. GNOME Terminal / VTE does not implement OSC 52, so nothing reaches the clipboard. The user is told the copy worked. This is the single most time-wasting part — it looks like a clipboard problem on the user's machine, and no amount of clipboard configuration can fix it.

3. The alternate screen keeps output out of scrollback. Claude uses ?1049h, so earlier output is not in the terminal's scrollback at all. Even with a working selection, you cannot select or scroll back past one visible screen.

Net effect: a user who wants to highlight some of Claude's output and paste it into a browser cannot do it beyond a single screen, and the one mechanism that would work (OSC 52) fails silently.

Verification

I confirmed the OSC 52 behavior directly rather than inferring it — writing a valid sequence to the terminal's pty with the clipboard verified empty beforehand:

| Terminal | Clipboard after \033]52;c;<base64>\a written to its pty |
|---|---|
| gnome-terminal (VTE 0.80.1) | unchanged — discarded |
| kitty 0.41.1 | set correctly |

Escape sequences confirmed present in the 2.1.266 binary: ?1000h, ?1006h, ?1049h.

Reproduce

1. GNOME Terminal on Linux (mine: 3.56.2 / VTE 0.80.1, Wayland, Debian 13)
2. ssh to a remote host and run claude
3. Try to select more than one screen of Claude's output with the mouse and paste it into another application

Expected

Selecting Claude's output with the mouse and pasting it elsewhere should work the way it does for ordinary terminal output. Failing that, a copy that cannot reach the clipboard should not report success.

Workaround

CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

This restores normal scrollback and terminal-owned mouse selection, and makes copy/paste behave like any other terminal program. It costs the TUI presentation.

These two environment variables are not documented anywhere I could find and are discoverable only by running strings on the binary.

Suggestions

• Do not report an OSC 52 copy as successful without evidence the terminal accepted it, or detect terminals known not to support it (VTE) and say so.
• Consider detecting VTE-based terminals and adjusting defaults, or surfacing these env vars in /config and the docs.
• At minimum, document CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN and CLAUDE_CODE_DISABLE_MOUSE.

Environment

• Claude Code 2.1.266
• GNOME Terminal 3.56.2, VTE 0.80.1
• Debian 13 (trixie), GNOME on Wayland
• Also reproduces against a remote host over SSH