Today I want to share a small problem I ran into while working over SSH and the simple trick I now use to solve it. If you work on remote servers, you might find it useful too.
My Problem
I sometimes work on a remote server over SSH. On that server, I run an AI coding agent such as Claude Code. The agent is great. It reads my code changes and writes pull request (PR) descriptions better than I do.
But I have one rule:
I never store my GitHub token on a remote server.
If someone gains access to the server, any GitHub token stored there could be compromised. I prefer to keep my credentials on my own machine whenever possible.
So my problem was simple:
The AI agent writes text on the server. I need that text in the clipboard of my Mac. How?
My First Mistake
Like every Mac user, I tried this:
echo "Hello" | pbcopy
It didn’t work.
Then I realized why.
Commands run wherever your current shell is running. Since I was inside an SSH session, pbcopy was running on the remote server, not on my Mac.
Most Linux servers don’t even have a clipboard.
The lesson is simple:
Always ask yourself, “Where is this command actually running?”
A Simple Example
Your Mac
└── ssh my-server
│
▼
Remote Server
$ echo "Hello" | pbcopy
Even though you typed the command on your Mac keyboard, your shell is running on the remote server, so pbcopy runs there too.
Things I Tried (And Why I Didn’t Like Them)
Option 1: Copy a File with scp
scp server:/tmp/pr-body.md ~/Downloads/
This works, but it’s annoying.
For just a few lines of text, I have to:
- Copy the file.
- Open the file.
- Copy the text again.
Too many steps.
Option 2: X11 Forwarding
Too heavy.
I only wanted to copy text, not run a graphical application.
Option 3: Install GitHub CLI (gh) on the Server
Easy.
But then I’d need GitHub credentials on the server.
That breaks my security rule.
The Trick I Use Now: OSC 52
OSC 52 is a terminal escape sequence for clipboard operations.
Instead of the server accessing your Mac directly, it sends a special escape sequence through your existing SSH session.
Your terminal recognizes that escape sequence and updates your local clipboard.
Here’s what happens:
- The server encodes your text as Base64.
- It wraps the encoded text in an OSC 52 escape sequence.
- The escape sequence travels through the existing SSH connection.
- Your terminal recognizes it and copies the decoded text into your local clipboard.
The key idea is simple.
Your terminal is the bridge.
OSC 52 escape sequence
+-------------------+ SSH +----------------------+
| Remote Server | -----------------> | Your Terminal App |
| (Claude Code, AI) | | (Ghostty, iTerm2...) |
+-------------------+ +----------+-----------+
|
| Updates
▼
+----------------+
| Mac Clipboard |
+----------------+
The server never talks directly to your Mac’s clipboard.
It only sends an OSC 52 escape sequence through your SSH session, and your terminal updates your local clipboard.
One thing I’ve learned over the years is this:
The best solutions don’t always require new tools. Sometimes they simply make better use of the tools you already have.
How to Set It Up
Add this function to your remote server’s shell configuration (~/.bashrc or ~/.zshrc).
pbcopy() {
if [ -z "$SSH_TTY" ]; then
echo "Error: not running in an SSH session." >&2
return 1
fi
encoded=$(base64 | tr -d '\n')
printf '\033]52;c;%s\a' "$encoded" > "$SSH_TTY"
}
Reload your shell:
source ~/.bashrc
Now you can use it just like the real pbcopy command on macOS.
echo "Hello from the server!" | pbcopy
Go back to your Mac.
Press ⌘ + V.
You’ll see:
Hello from the server!
It Works Great with AI Coding Agents
This is the workflow I use every day.
Instead of manually selecting text, the AI agent can write directly to my clipboard.
pbcopy <<'EOF'
## What this PR does
- Fixes the login bug
- Adds tests
- Cleans up the authentication flow
EOF
I review the text, make any edits I want, and paste it into GitHub.
My GitHub token never leaves my Mac.
Two Things I Learned
1. Write to $SSH_TTY, Not Standard Output
AI agents often capture or redirect command output.
If the OSC 52 escape sequence gets redirected into a log file or another process, your terminal never receives it.
$SSH_TTY points to the terminal device for your SSH session, ensuring the escape sequence reaches the terminal you’re actually using.
2. Add a Safety Check
Notice this check at the beginning of the function.
if [ -z "$SSH_TTY" ]; then
echo "Error: not running in an SSH session." >&2
return 1
fi
Without it, the escape sequence could accidentally end up in a redirected file or log.
Small defensive checks like this help prevent confusing bugs later.
Before You Try It
- Your terminal must support OSC 52. I use Ghostty and it works great. iTerm2, WezTerm, kitty, and several other terminals also support it. Some require enabling clipboard access first.
- Only use this with servers you trust. OSC 52 allows a remote server to request clipboard updates. That’s convenient when you intend it, but it’s also why many terminals let you disable or confirm clipboard writes.
- Using tmux? You may need to enable OSC 52 passthrough in your
tmux.conf. - OSC 52 is best for text. Some terminals limit the maximum clipboard size, so copying very large content may require additional configuration.
Summary
My goals were simple:
- Keep GitHub credentials on my Mac.
- Avoid copying files with
scp. - Copy AI-generated text directly into my local clipboard.
- Keep the workflow simple.
OSC 52 solved all of those problems.
The server never accesses my clipboard directly.
My terminal acts as the bridge, receiving the OSC 52 escape sequence and updating my local clipboard.
It takes about five minutes to set up, and it’s become part of my everyday workflow.
If you work with AI coding agents on remote servers, I highly recommend giving it a try.
References
- xterm Control Sequences (OSC 52) — The official reference that defines OSC 52 for clipboard manipulation.
- Ghostty Configuration Reference — Explains how Ghostty handles OSC 52 clipboard writes and related configuration.