Skip to content
ClipHop
Download
6 min read

Clipboard sync for developers: commands, URLs, and snippets between Android and Mac

Concrete developer workflows that benefit from cross-device clipboard sync: OTPs from the phone to the Mac, kubectl commands the other way, shell snippets, test URLs, log links. How ClipHop fits.

By

If you write code, you already do cross-device clipboard more than you realize. Not as a workflow you’ve named, just as friction you tolerate:

  • Your phone buzzes with a 2FA code. You unlock it, read it, type it onto the Mac.
  • A co-worker Slacks you a log URL on your phone. You message it to yourself, wait, click it on the Mac.
  • You’re SSH’d into a machine on your phone (I won’t judge), need to run a kubectl command you have on your Mac. Message-to-self time.
  • Your Mac editor has an error stack trace worth investigating on the phone. You screenshot it. Or you paste it into Slack and pull it up on the phone.

Every one of these is a moment of device-hopping friction that adds up to minutes a day and context-switches that cost more than the minutes. This post is about what a clipboard-sync tool actually changes in developer workflows — with concrete examples — and why the specific design of ClipHop (Bluetooth LE, no network, manual send) fits developer use.

The developer-specific workflows#

1. OTPs and 2FA codes#

The archetypal one. Your bank, your AWS console, your GitHub, your cloud provider’s MFA — all pushing codes to your phone. Typing a 6-digit code from the phone to the Mac is a 5-second operation that you do 5–20 times a day. That’s a real percentage of a developer day on muscle-memory typing.

With ClipHop: copy the code on the phone (long-press in the SMS or authenticator), tap ✈ to send. The code is on the Mac clipboard before you move your eyes. Cmd-V.

Sub-second round-trip, over Bluetooth LE, zero network. Works when you’re connected to a VPN that’s blocking DNS weirdness, on a plane, on hotel WiFi with client isolation — anywhere your phone and Mac are within Bluetooth range.

You’re on the couch, phone in hand, Slack notification lights up with “@here ALARM: prod-api-latency p95 > 400ms” and a link to the Grafana dashboard. You’d like to see it on the Mac screen in front of you. Without clipboard sync:

  • Forward to yourself via iMessage / WhatsApp / Slack DM.
  • Wait for the message to arrive.
  • Click the link.

With clipboard sync:

  • Long-press the URL in Slack on phone, copy.
  • Tap ✈ to send.
  • On the Mac, the URL is already in your clipboard. Cmd-L (or Cmd-V in the address bar), Enter.

This flow is the most common reason developers we talked to gave for wanting cross-device clipboard. Log URLs, Sentry issue links, PagerDuty escalation links, Datadog dashboards, Honeycomb queries — all come as links in phone-Slack, all are pain to move to the Mac.

3. Shell commands and scripts#

The reverse direction is nearly as useful. You have a gnarly kubectl incantation in your Mac editor, and you’re ssh’d into a bastion from a mobile terminal on your phone (Termius, Blink, whatever). You want to run the command there. Without sync:

  • Message-to-yourself. Pray the formatting survives.

With sync:

  • Copy on the Mac panel, hit ✈ or the send shortcut.
  • Long-press in the phone terminal, paste.

Works equally well for SSH snippets, brew install one-liners you want to run on another machine, database queries you prototyped on the Mac and want to run on a cloud shell.

4. Error messages and stack traces#

You’re on the Mac debugging your own server, but you also want to read the error on the phone — either because you’re on your way somewhere, or because you want to paste it into a phone-Slack thread with a co-worker. Copy on Mac, send to phone, long-press in Slack to paste.

The reverse: a crash report appears on your phone (because that’s the device the app runs on). You want to paste the stack trace into a GitHub issue on the Mac. Copy on phone, send to Mac, Cmd-V into the issue editor.

5. Git hashes, commit messages, PR URLs#

Small, high-frequency copy-paste. You’re reviewing a PR on the phone via the GitHub mobile app, want to check out the branch locally. Copy the branch name / PR number on the phone, send. git checkout on the Mac. Or you just finished a commit on the Mac, want to paste the commit hash into a status update on phone-Slack. Works in both directions identically.

Why the ClipHop design fits#

Several choices in ClipHop’s design specifically help developer workflows:

No network dependency#

Developers work from weird networks. Corporate VPNs that route DNS in unexpected ways. Airplane WiFi. Home networks being reset. Coffee shops with captive portals that block mDNS. LAN-based sync tools break in exactly these scenarios. ClipHop’s Bluetooth-LE transport doesn’t care about any of this — the phone and Mac talk to each other directly, radio to radio. If Bluetooth works, the clipboard works.

See Why we chose Bluetooth LE for clipboard sync for the full transport rationale.

Manual send by default#

Developers copy sensitive stuff all day. AWS access keys, database passwords, API tokens, SSH private-key passphrases, production admin credentials. Auto-forwarding every clipboard change is the last thing a developer wants.

ClipHop ships with manual send on: every clip sits in local history until you tap ✈ to push it. The clipboard leaves the device only when you explicitly ask. You’ll never wake up to find an API key you copied three days ago was automatically synced to a device your kid also uses.

See Manual send by default for why content-level filtering isn’t a reliable substitute for this.

End-to-end encrypted with fingerprint verification#

If your threat model includes “someone with Bluetooth proximity could be attempting to MITM my pair,” ClipHop has you covered. AES-256-GCM on session keys from X25519 ECDH, authenticated with Ed25519 identity keys, fingerprint-verifiable on both devices. See How ClipHop encrypts your clipboard for the crypto detail.

For most developers, “an attacker with Bluetooth proximity actively attempting MITM on my cross-device clipboard” is not the attack they’re preparing for. Good. But the design is there if you want it, and the identity-fingerprint model gives you a way to check your pair hasn’t been tampered with — not just at pair time, but any time afterward.

Single-purpose, no telemetry#

A clipboard tool should do one thing. ClipHop does not mirror notifications, doesn’t send files, doesn’t observe your focus windows, doesn’t report crash stats to a backend. There’s no backend. The app on your Mac is one menu-bar process with a foreground service on the phone, and nothing else is happening in the background.

For a developer machine — where you already have 30 menu-bar apps doing obscure things — picking a clipboard tool that runs one visible process and does nothing else is a welcome surprise.

Where ClipHop doesn’t fit#

Honest caveats:

  • Large files: v0.1.0 syncs plain text and URLs. Rich text, images, and files are on the roadmap but not here yet. If you need to move a 20 MB log file, use scp or AirDrop (within Apple) or KDE Connect (within WiFi). ClipHop is for text.
  • Many devices: v0.1.0 supports one active pair at a time — one phone with one Mac. That’s an intentional privacy default. If you want a clipboard that spans 4 devices simultaneously, you want a different tool (or wait for multi-pair support on the roadmap).
  • Team / shared workflows: ClipHop is for your two personal devices. Not a shared team clipboard, not a copy-paste Slack channel. Different product.

Setup#

If your pain is the device-hopping one — especially OTPs and URL-sharing — ClipHop is probably the smallest-friction fix you can install today.

First time you copy an OTP on your phone and paste it on your Mac without typing it, you’ll notice how much that specific friction had been costing you.