Cursor Agent CLI `/copy` fails in remote SSH/headless terminal; should support OSC52 fallback or configurable clipboard command

[cb-okhomenko (Oleksandr Khomenko 🇺🇦)]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When running Cursor Agent CLI on a Linux devbox through a remote terminal bridge, /copy last message does not copy the assistant response back to the macOS host clipboard.

This is not a Herdr topology issue. Herdr is launched correctly from the macOS host with --remote, so remote terminal clipboard writes can be bridged back to the Mac if the remote process emits OSC52. Herdr-native selection copy works, and OSC52 clipboard sequences from the remote shell are the correct mechanism for this topology.

The problem is Cursor Agent CLI’s Linux clipboard behavior. In a headless SSH session, Cursor appears to check for Linux GUI clipboard availability via WAYLAND_DISPLAY / DISPLAY, then gives up when neither exists. It does not emit OSC52 and does not provide a configurable clipboard command, so the terminal bridge has nothing to forward.

Environment

• Host machine: macOS
• Remote/devbox: Linux
• Terminal/mux: Herdr launched from macOS with herdr --remote devbox
• Cursor Agent CLI runs inside the remote Linux Herdr pane
• Remote session is headless over SSH: no DISPLAY, no WAYLAND_DISPLAY

Related Public Reports

• Cursor CLI clipboard fallback/config gap:
  https://forum.cursor.com/t/cursor-cli-clipboard-fails-in-container-environment-despite-xclip-xel-being-present-can-we-fall-back-to-them/158413

• Cursor CLI raw output /copy feature discussion:
  Copy Cursor CLI's raw output

• Cursor OSC52 terminal clipboard tracking, separate but related:
  Cursor integrated terminal corrupts UTF-8 OSC 52 clipboard text from tmux

Steps to Reproduce

1. On macOS, start a Herdr remote session:

   herdr --remote devbox
   

2. In the remote Linux pane, confirm it is a headless SSH/remote terminal session:

   env | grep -E 'SSH_CONNECTION|DISPLAY|WAYLAND_DISPLAY'
   

   Expected shape:

   SSH_CONNECTION=...
   # no DISPLAY
   # no WAYLAND_DISPLAY
   

3. Start Cursor Agent CLI in that pane:

   agent
   

4. Ask any prompt that produces a response.

5. Run:

   /copy last message
   

6. Try pasting on the macOS host.

Actual Result

The latest assistant response is not copied to the macOS host clipboard.

Expected Behavior

In a headless SSH/remote terminal session, Cursor Agent CLI should copy via OSC52, so terminal bridges such as Herdr, tmux-compatible terminals, iTerm2, etc. can forward the clipboard write to the local host.

Expected architecture:

cursor-agent /copy
  -> emits OSC52 clipboard sequence
  -> terminal bridge observes OSC52
  -> macOS host clipboard is updated

Current behavior appears to be:

cursor-agent /copy
  -> checks Linux GUI clipboard env
  -> no WAYLAND_DISPLAY/DISPLAY
  -> gives up
  -> emits no OSC52
  -> host clipboard is not updated

Why This Matters

Remote/headless terminal sessions are a core Cursor Agent CLI use case. Linux GUI clipboard checks are not sufficient there. The standard terminal-native mechanism for copying from a remote TTY to a local clipboard is OSC52.

Requested Fix

Add one of:

1. OSC52 fallback when running in a TTY/SSH session and native clipboard commands are unavailable.
2. A configurable clipboard command, e.g. cursor-agent.clipboardCommand, so users can set an OSC52 helper.
3. Both.

Operating System

Linux

Version Information

│ CLI Version 2026.06.24-00-45-58-9f61de7
│ Model Opus 4.8 300K Extra High
│ OS linux (x64)
│ Terminal unknown
│ Shell zsh

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey thanks for the detailed report. The architecture breakdown is accurate. This is a known limitation. On Linux the CLI writes to clipboard only when there’s a GUI session with DISPLAY or WAYLAND_DISPLAY using wl-copy or xclip. In a headless SSH session neither is available so /copy gives nothing and there’s no way to bridge it through the terminal. OSC52 fallback and configurable clipboard command aren’t implemented yet. I reported the issue inside. There’s no timeline for the fix yet.

Here are a couple of temporary options while we wait for the fix. Connect using ssh -X or ssh -Y to set DISPLAY on the remote machine and install xclip or xsel. Then /copy will work normally. Or just copy the response text from the terminal scrollback.

I’ll update the thread when there’s news.

[cb-okhomenko (Oleksandr Khomenko 🇺🇦)]

Thanks, that matches what I found.

One note: terminal clipboard bridging is possible through OSC52; Cursor just doesn’t emit OSC52 today. In my Herdr setup, OSC52 written from the remote pane reaches the macOS clipboard correctly.

As a temporary workaround, I can force Cursor into its wl-copy path by setting a scoped fake WAYLAND_DISPLAY and putting a wl-copy shim first in PATH. The shim reads from stdin and emits OSC52 to /dev/tty, which makes /copy work through Herdr without X11 forwarding.

This is still a workaround. The proper fix would be native OSC52 fallback, or a configurable clipboard command, when running in SSH/headless TTY sessions.

Long term, Cursor should probably support OSC52 fallback directly, or allow the clipboard command to be configured for SSH/headless TTY sessions.

[cb-okhomenko (Oleksandr Khomenko 🇺🇦)]

Adding the workaround I’m using for anyone who lands here later.

In a headless SSH terminal, Cursor Agent CLI does not currently emit OSC52. But if your terminal bridge supports OSC52, you can make /copy work by shimming Cursor’s existing wl-copy path.

In my setup:

• Host: macOS
• Devbox: Linux
• Terminal bridge: herdr --remote devbox
• Cursor Agent CLI runs on the Linux devbox
• No DISPLAY
• No WAYLAND_DISPLAY

First verify OSC52 reaches your host clipboard from the remote pane:

printf '\033]52;c;%s\007' "$(printf %s 'osc52 test from remote' | base64 | tr -d '\n')"

If pasting on the host gives osc52 test from remote, the terminal bridge is fine.

Then create a scoped wl-copy shim on the Linux devbox:

mkdir -p ~/.local/bin/cursor-osc52

cat > ~/.local/bin/cursor-osc52/wl-copy <<'SH'
#!/usr/bin/env sh
payload="$(base64 | tr -d '\n')"

if [ -w /dev/tty ]; then
  printf '\033]52;c;%s\007' "$payload" > /dev/tty
else
  printf '\033]52;c;%s\007' "$payload"
fi
SH

chmod +x ~/.local/bin/cursor-osc52/wl-copy

Launch Cursor Agent with the shim only for that process:

WAYLAND_DISPLAY=cursor-osc52 PATH="$HOME/.local/bin/cursor-osc52:$PATH" agent

What this does:

Cursor sees WAYLAND_DISPLAY
-> Cursor calls wl-copy
-> shimmed wl-copy reads Cursor's clipboard text from stdin
-> shim emits OSC52 to /dev/tty
-> terminal bridge forwards OSC52 to the host clipboard

Do not export the fake WAYLAND_DISPLAY globally. Keep it scoped to cursor-agent.

This is a workaround, not the proper fix. The proper fix is still native OSC52 fallback or a configurable clipboard command in Cursor Agent CLI for SSH/headless TTY sessions.

[deanrie]

Great workaround, thanks for writing it up in such detail. I think it’ll really help any user who finds this thread with the same setup.

The fake WAYLAND_DISPLAY plus a wl-copy shim that emits OSC52 to /dev/tty does a pretty good job of filling the gap until there’s native support. The one caveat, like you mentioned, is that it relies on internal clipboard selection behavior that could change, so keep that in mind when updating the CLI.

A native fix like an OSC52 fallback or a configurable clipboard command for SSH and headless TTY is still on the backlog, and there’s no ETA yet. Once there’s an update, I’ll post it in the thread.