Linux/X11: one copy writes the clipboard twice (OSC 52 and xclip), and the two race for selection ownership

Summary

On Linux/X11, a single copy from the Claude Code TUI writes the system clipboard twice,
by two mechanisms that then race each other for ownership of the X selection:

1. an OSC 52 escape sequence, which the terminal acts on by taking the CLIPBOARD selection;
2. a pair of xclip processes, xclip -selection clipboard and xclip -selection primary,

spawned roughly 0.2 to 0.9 seconds later, which take both selections.

On X11 only one client can own a selection, so the later write takes it from the earlier
one. The terminal then reports that its write failed, and the text ends up wherever the
winner of the race put it.

With Alacritty the failure is visible as a warning that takes over the message bar:

[WARN ] [alacritty] Unable to store text in clipboard: Failed to set new owner of XCB selection

Evidence

I logged every change of X selection ownership together with every xclip process spawn,
resolving each owner to its process while it still held the selection.

A single drag-copy produces, in order:

CLIPBOARD -> <terminal pid>        (the OSC 52 write)
SPAWN      xclip -selection primary
CLIPBOARD -> <a new xclip>         (the xclip write, 0.7s later)
SPAWN      xclip -selection clipboard
SPAWN      xclip -selection primary
ALACRITTY  Unable to store text in clipboard: Failed to set new owner of XCB selection

The xclip processes belong to the Claude Code process group, so both writes come from
Claude Code itself. The terminal is only carrying out the OSC 52 request.

Setting osc52 = "Disabled" in the terminal removes one of the two writers. Counted over
comparable periods of copying, with nothing else changed:

| | xclip copies | times the terminal took the clipboard | warnings |
|---|---|---|---|
| before | 46 | 10 | 4 |
| after | 50 | 0 | 0 |

So the terminal's involvement came entirely from OSC 52, and the race disappears when only
one writer is left.

Impact

• A copy can silently end up holding the wrong text, since which writer wins is a race.
• The terminal's message bar fills with clipboard errors that look like a terminal fault.
• Each copy leaves two more xclip processes serving the selections.

Environment

Claude Code 2.1.280, Linux, X11, Alacritty 0.13.2, tmux 3.7c, a clipboard manager running.

Expected

One copy should produce one clipboard write. Either use OSC 52 or use the external helper,
not both; if both are wanted as a fallback, the second should run only when the first is
known to have failed, rather than concurrently.

Workaround

Disable OSC 52 clipboard writes in the terminal, which leaves xclip as the only writer.
The cost is that programs which can only copy through OSC 52, ssh sessions above all, lose
the clipboard in that terminal.