[BUG] KDE Konsole < 24.12: copy reports "sent N chars via OSC 52" but the clipboard is never written — KONSOLE_VERSION is available for exact detection

Preflight Checklist

• [x] I have searched existing issues. The closest are #80184 (VTE / Ptyxis / GNOME Terminal) and #76902 (Terminal.app). This is a distinct terminal family, and — unlike those — the capability is version-gated and there is an exact, synchronous detection signal already sitting in the environment that Claude Code does not use. Filing separately so it can be actioned; tracked under #81472.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.220)

What's Wrong?

On KDE Konsole older than 24.12, an explicit copy in the TUI renders

sent 333 chars via OSC 52 · if paste fails, hold Shift while selecting for native copy

…and the system clipboard is never written. The byte count reads as strong confirmation that the copy worked, so the user has no reason to suspect otherwise.

OSC 52 clipboard writes only landed in Konsole 24.12 (KDE bug 372116, RESOLVED FIXED, merged 2024-07-24 via konsole!767). Every Konsole before that silently swallows the sequence — including 23.08.5, which is what Ubuntu 24.04 LTS ships, i.e. the current LTS desktop default.

Why this is not a duplicate of #80184

• It is version-gated, not a permanent property of the terminal. VTE never supports OSC 52; Konsole works fine at ≥ 24.12 and fails below it. A terminal-name blocklist gets this wrong in both directions.
• The detection signal is free and already present. Konsole exports its version into every session as an MMmmpp integer:

``console
$ echo $KONSOLE_VERSION
230805 # 23.08.05 → no OSC 52. Threshold: >= 241200
``

One integer comparison. No handshake, no async probe, no timeout.

• Claude Code already asks the terminal who it is. The 2.1.220 bundle contains XTVERSION and CSI > q, and the startup handshake captured off a pty emits:

``
ESC[?2004h ESC[?1004h ... ESC[>0q ESC[c
``

So terminal identification is already implemented — it just isn't used to gate the OSC 52 path.

Standalone repro (no Claude Code involved)

Konsole 23.08.5, X11:

$ printf '\033]52;c;%s\007' "$(printf 'OSC52-PROBE' | base64 -w0)"
$ qdbus org.kde.klipper /klipper getClipboardContents
<unchanged — OSC52-PROBE never appears>

I also verified it against a live session by writing the sequence directly into the claude process's pty (/dev/pts/N): clipboard contents before and after are byte-identical, and never contain the probe string.

There is no fallback path on this configuration

OSC 52 is the only path that runs:

• xclip, xsel, wl-copy — none installed. A stock Ubuntu 24.04 KDE desktop ships none of them.
• Not running under tmux.
• X11 session, so the Wayland wl-copy path discussed in #80184 is never reached either.

So the copy is a guaranteed no-op, reported to the user as a success with an exact byte count.

What Should Happen?

1. Do not state success for an unverifiable write. OSC 52 generates no reply; sent 333 chars via OSC 52 is an unconditional claim that the code cannot possibly have confirmed. Either verify a real path, or phrase it as an attempt.
2. Gate OSC 52 on KONSOLE_VERSION when it is set: < 241200 → treat OSC 52 as unavailable. Exact, synchronous, no probing.
3. When no working clipboard path exists at all, say so. On this configuration nothing can write the clipboard, and the user needs to be told that — with hold Shift while selecting as the primary instruction, not a parenthetical trailing a success message. A file fallback (write the text out, print the path) would also be a reasonable escape hatch.

Point 3 is the one that actually costs users time. The current message is worse than no message: it actively directs the user to go debug their terminal, their clipboard manager, or their own hands.

Steps to Reproduce

1. Ubuntu 24.04 LTS + KDE Plasma, Konsole 23.08.5 (echo $KONSOLE_VERSION → 230805), X11 session.
2. Ensure xclip / xsel / wl-copy are not installed. Not inside tmux.
3. Start claude (2.1.220) and trigger an explicit copy in the TUI.
4. The UI shows sent N chars via OSC 52 · if paste fails, hold Shift while selecting for native copy.
5. Paste anywhere → nothing. qdbus org.kde.klipper /klipper getClipboardContents → unchanged.

Workaround for anyone landing here: hold Shift while drag-selecting to force Konsole's native selection (this bypasses the TUI's mouse capture), then Ctrl+Shift+C. Or upgrade Konsole to ≥ 24.12.

Environment

| | |
|---|---|
| Claude Code | 2.1.220 |
| Terminal | Konsole 23.08.5, KONSOLE_VERSION=230805 |
| OS | Ubuntu 24.04.4 LTS (Noble Numbat) |
| Desktop | KDE Plasma 5.27.12, X11 |
| TERM | xterm-256color |
| Kernel | 6.8.0-136-generic |
| Clipboard helpers | none (xclip, xsel, wl-copy all absent) |
| tmux | not in use |

Related

• #80184 — same failure mode (unconditional success message, OSC 52 ignored) on VTE
• #76902 — same class on macOS Terminal.app
• #71826 — mouse capture blocking native selection, which is what pushes users onto the OSC 52 path to begin with
• #81472 — [META] copy/paste tracking issue