Claude Code, OSC 52, Copy Text

Hello,

I wasn't able to recreate the issue on my end. I tested it using Raspberry Pi OS, but the behavior you described did not occur.

Could you try changing the Mouse Click Mode setting?

Go to:
File → Settings → Entry Type → Session → Terminal → Mouse → Set Mouse Click Mode to Windows.

With this setting enabled, right-clicking in the terminal will display a context menu that allows you to copy and paste text.

Please let me know if this helps resolve the issue.

best regard

Unfortunately, it does not. You succeeded in Claude Code? Chatting with Claude (about Claude - the irony!) I got:

- Claude Code toggles bracketed paste mode (\e[?2004h/l) as part of normal operation — this is standard/expected terminal behavior, not unique or misconfigured on Claude Code's end
- Ask specifically: does RDM's right-click paste emit ESC[200~ / ESC[201~ around pasted content, or inject raw keystrokes?
- Contrast: SSH/tmux "work" because they don't require paste to be specially delimited; Claude Code does

Hello,

Thanks for the detailed report and for digging into the OSC 52 angle yourself that pointed us in the right direction.

I set up a matching repro (RDM SSH Shell session to a Debian 13 host, tmux 3.5a, same OSC 52 mechanism Claude Code uses) and tested it systematically with an assist from Claude Code itself to trace through RDM's terminal handling and script the isolated tests. Here's what we found:

RDM's SSH terminal does correctly support OSC 52 clipboard writes. Sending a raw OSC 52 sequence directly over the SSH session (no tmux) copies to the Windows clipboard without issue.

The actual problem is in tmux's default configuration. Debian 13 ships tmux 3.5a, and out of the box:

• set-clipboard defaults to external
• allow-passthrough defaults to off

Neither default alone forwards an OSC 52 clipboard-set request from a program running inside a tmux pane (like Claude Code) out to the terminal attached to tmux and we confirmed that's true regardless of which terminal is on the other end, not something specific to RDM. tmux introduced allow-passthrough as a security-hardening default a while back, and it turns out both settings need to be explicitly enabled together for OSC 52 to pass through either one alone isn't enough.

Fix: add these two lines to ~/.tmux.conf on the Debian host:
set -g set-clipboard on
set -g allow-passthrough on

Then reload with tmux source-file ~/.tmux.conf (or just restart tmux). After that, Claude Code's OSC 52 copy should reach your Windows clipboard through RDM exactly as expected.

The Mouse Click Mode setting I mentioned earlier isn't related to this that only affects xterm-mouse-protocol reporting, not clipboard forwarding, so no need to touch that further.

Let me know if this resolves it on your end.

Best regards,

Amazing! It does! AND ctrl+shift+v will paste text. no more modifying a macro to paste my text every time.

The macro raises a second tangential question - why is macro typing so fast but "Type clipboard" on the Home Ribbon is sooooo slow?

Hello,

Great to hear the tmux fix resolved the OSC 52 copy behavior, and thank you for confirming that Ctrl+Shift+V paste is working as well.

On your follow-up question about typing speed, the difference you are seeing is expected because Type Clipboard and macros use two completely independent typing-delay controls in RDM.
Macros have their own per-macro interval that most users set to zero or near-zero, which is why they feel instantaneous.

Type Clipboard uses a session-level keystroke interval that is intentionally more conservative so that the remote target stays in sync during long payloads, keyboard layout translation, and moments where the remote is busy.

Best regards,

OK thanks. I am sure the Type Clipboard is needed in some scenarios other than mine, but when I could not copy/paste into Claude Code I kept changing the text in a dedicated macro to be what I needed to paste and it worked with the speed of it just fine - several hundred characters across multiple lines (ones that Type Cliboard threw a little bit of a fit about "are you sure - this is long")

Hello,

Thanks for the feedback! I bet that took quite a while to work around 😄.

If you think it would be a good improvement, I'd recommend creating a feature request to add a confirmation message (or similar option) before Type Clipboard pastes long content. That way our product team can review the idea and consider it for a future release.

Best regard.