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

Support Bug Reports
, , ,
1

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

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

5

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.