Clipboard copy silently fails when outer terminal ignores OSC 52

[huiihao]

Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.
• I reproduced this bug on the version and environment reported below using the exact steps provided.

Current behavior

When pressing Ctrl+C or using mouse-select in Claude Code (or any app) running inside herdr, the "copied to clipboard" toast appears, but the content is not actually available in the system clipboard. Pasting (Ctrl+V) pastes whatever was previously in the clipboard, not the content that was just "copied."

The same herdr instance running via herdr --remote does not have this problem — clipboard works correctly in that path.

Expected behavior

After copying text from an app inside herdr, the content should be available in the system clipboard and pasteable immediately with Ctrl+V.

Reproduction

1. Open VS Code integrated terminal
2. SSH into a remote Linux server
3. Run herdr on the remote server
4. Open Claude Code inside a herdr pane
5. Select a code block and press Ctrl+C to copy, or use mouse-select copy
6. Observe the "copied to clipboard" toast
7. Try Ctrl+V to paste — the clipboard contains old or no content

Alternatively (without SSH):

1. Open VS Code integrated terminal on Windows with WSL
2. Run herdr inside WSL
3. Copy text from any pane app — "copied to clipboard" appears but paste fails

Impact

This makes herdr unusable as a daily driver for Claude Code in VS Code, which is a very common workflow. The clipboard is critical — every code block, command output, or log excerpt that Claude Code generates needs to be copyable. The workaround of using herdr --remote instead of a direct SSH connection works but adds friction and is not always available (e.g., behind jump hosts that do not allow persistent remote connections).

Environment

• Herdr version: 0.7.5-preview
• Update channel: preview
• Operating system: Windows 11 (host), Ubuntu 24.04 (WSL), Ubuntu 24.04 (remote server via SSH)
• Terminal: VS Code integrated terminal (1.131.0)
• Shell, if relevant: bash, zsh
• Relevant config, if any: default config

[akbash-bot]

To distinguish Herdr's clipboard routing from the outer VS Code terminal's OSC 52 support, please run this once outside Herdr in the same SSH-connected VS Code integrated terminal:

printf '\033]52;c;aGVyZHItb3NjNTItdGVzdA==\a'

Then paste into a Windows text field and reply with whether it produced exactly herdr-osc52-test. The command does not read or print any clipboard contents or other private data.

[naisanzaa]

Experiencing the same thing on MacOS. Says "copied to clipboard" but no way to paste.

[winternewt]

Decided to try herdr, having same issue with Claude + Herdr + MobaXTerm ( no OSC 52 support ):
Claude + MobaXTerm - clipboard works
Claude + Herdr + KiTTy works (OSC 52 supported)

[huiihao]

It was discovered that using herdr --remote to connect to a remote server works fine for clipboard copying; however, when herdr is started directly on the remote server, the copy function fails.

[akbash-bot]

Thanks — that confirms the direct-server and --remote paths differ, but it does not show whether the direct terminal can carry clipboard writes at all.

For the final diagnostic, please SSH to the server in VS Code, stay at the shell before starting Herdr, and run:

printf '\033]52;c;aGVyZHItb3NjNTItdGVzdA==\a'

Then paste into a Windows text field and reply with only one of these results: pasted herdr-osc52-test or clipboard unchanged. This command does not read or print clipboard contents or other private data.

[huiihao]

pasted herdr-osc52-test

[mabrunoro]

Found this in Claude Code, in Linux Mint 21

[choukh]

Adding a code-path trace and client-side instrumentation for this, since #2776 was consolidated here. Everything below is first-hand measurement on a setup that removes SSH, WSL and VS Code from the picture entirely.

Environment: herdr 0.8.0 stable (protocol 19), macOS arm64, Warp v0.2026.07.29.09.05.stable_02, purely local session mode — no SSH, no WSL, no VS Code, no --remote. Reproduces 7/7.

The toast is not evidence of a write, and it is not evidence of a failure either

Tracing v0.8.0:

• src/app/actions.rs:2285 sets self.request_clipboard_write = Some(text.into_bytes()) and line 2286 immediately logs info!("copied selection to clipboard"). The log fires on enqueue, before anything attempts a write — so that log line can never indicate success.
• src/app/input/clipboard.rs::dispatch_pending_clipboard_write drains it into AppEvent::ClipboardWrite via event_tx.try_send, warning failed to queue clipboard write event on a full channel. No such warning appears in my server log, so the event is queued fine.
• src/server/headless.rs:2101 — the headless server does not take the write_osc52_bytes-to-stdout path (that is monolithic-only, per the doc comment at :2376). It forwards instead:

AppEvent::ClipboardWrite { content } => {
    let data = base64::engine::general_purpose::STANDARD.encode(content.as_slice());
    if self.send_to_foreground_client(ServerMessage::Clipboard { data }) {
        self.app.show_clipboard_feedback();
    }
    true
}

The toast is gated on send_to_foreground_client returning true. So a visible toast means the server believed it handed the payload to a client. That puts the break at or after client delivery, not in the copy/selection code.

Client-side instrumentation

Ran the client with HERDR_LOG=debug, then did one drag-select in an idle plain-shell pane. Three sources, same copy:

Source	Result
Server log	06:24:17.381 INFO herdr::app::actions: copied selection to clipboard
Client debug log	755 new lines, all herdr::raw_input. Zero hits for clipboard/osc/copy
System clipboard	byte-identical before and after (4 Hz pbpaste polling + hexdump)

Caveat I cannot resolve from outside: the client's debug logging covers its own input parsing, so I can't tell whether it received ServerMessage::Clipboard and dropped it, or never received it.

This is not the OSC 52 path failing — the native path is failing too

should_prefer_osc52_for_env is ssh_connection.is_some() || ssh_tty.is_some() || vscode_ipc_hook_cli.is_some() || wsl. I dumped the environment of both processes: the server daemon (PID 44884) and the attached client have none of SSH_CONNECTION, SSH_TTY, VSCODE_IPC_HOOK_CLI, and are not WSL. So should_prefer_osc52() is false on both, and write_osc52_bytes should try crate::platform::write_clipboard — i.e. spawn pbcopy — before ever emitting an escape sequence.

pbcopy is on the daemon's PATH (/usr/bin is present) and works fine from processes in that tree — I set the clipboard from a shell that is itself a descendant of the herdr server. So the terminal-independent branch is failing too.

That matters for triage: on this setup the bug cannot be explained by OSC 52 support, terminal behaviour, or transport. Both branches of write_osc52_bytes are terminal-independent here, and neither takes effect.

Outer terminal is ruled out on this setup as well

Writing ESC ] 52 ; c ; <base64> BEL directly to the attached client's tty, while herdr is running and in alt-screen, sets the macOS clipboard correctly — BEL- and ST-terminated, at 1 KB / 8 KB / 64 KB payloads. Pasting into herdr also works normally (bracketed paste). Only the copy direction is broken.

Only one interactive client was attached throughout (client_id=23), so foreground-client ambiguity isn't a factor in this reproduction.

---

Net: the failure is downstream of send_to_foreground_client returning true, and it defeats the native pbcopy branch as well as the OSC 52 branch. Happy to run any instrumented build or targeted diagnostic on this machine — it reproduces on demand and has no SSH/WSL/VS Code variables to control for.

[ianqueros]

Found this in mint 22.3 (Ubuntu 24) running a local X11 session in bash with herdr 0.8.0 (default config). Not tied to any specific harness. The system did not have xclip installed, making herdr silently fall back to emitting OSC 52 escape sequences to stdout and optimistically display the toast, even though nothing was copied. Solved by installing xclip.

[mabrunoro]

Found this in mint 22.3 (Ubuntu 24) running a local X11 session in bash with herdr 0.8.0 (default config). Not tied to any specific harness. The system did not have xclip installed, making herdr silently fall back to emitting OSC 52 escape sequences to stdout and optimistically display the toast, even though nothing was copied. Solved by installing xclip.

This solved for me as well