How it works
A link with no one in the middle
Two apps stay connected over whichever path is best — and everything that crosses a wire is sealed before it leaves the device.
background service
clip copied · sealing
a deliberately dumb pipe
⇄ fwd 96 B · opaque
menu-bar agent
✓ opened · pasted
Bluetooth presence beacon
phone ↔ Mac directly — powers proximity auto-lock, fully local
frames: clip · cmd · stat · note · sms — all sealed with ChaCha20-Poly1305
The path is chosen for you
Same Wi-Fi? Straight to the Mac.
The Mac runs a small local server and announces itself on the network; the phone finds it automatically and connects LAN-direct. No relay hop, lower latency, and it works with zero server setup.
Out the door? The relay takes over.
When the LAN link drops, both ends fall back to the relay you host. Each pairing shares a room id; the relay matches the two sockets in that room and forwards frames without understanding them. When you come home, the link moves back to LAN on its own.
Walking away? Bluetooth notices.
The phone broadcasts a low-energy presence beacon derived from your pairing — the Mac measures its signal and locks the screen when you're out of range. It needs neither Wi-Fi nor the relay, so it keeps working with no internet at all. (Locking only — macOS offers no way to auto-unlock.)
Sealed before it leaves
Pairing gives both devices a shared 32-byte secret — it rides in the QR code and is stored in the Mac's Keychain and the phone's secure storage. From then on, every frame (clips, commands, battery, notifications, messages) is encrypted with ChaCha20-Poly1305 on the sending device and only opened on the receiving one.
- Each frame is bound to its type, so a captured frame can't be replayed as a different kind of message.
- Frames carry a timestamp and are accepted only within a short freshness window; repeats are dropped by a replay cache.
- The relay authenticates clients with a token and rate-limits rooms — but even a hostile relay only ever sees ciphertext.
- No account, no cloud, no telemetry. The only secrets live on your two devices and in your own server's config.
The Android trick
Modern Android doesn't let ordinary apps read the clipboard in the background — that would normally kill two-way sync the moment you switch apps. Link to Mac gets around it honestly: the app pairs with the phone's own ADB over Wireless Debugging and starts a tiny privileged helper on the device itself. That helper has shell-level clipboard access and keeps running even after the app is swiped away.
Everything stays on your phone — it's your device granting your own app more of its own power. Turning on Wireless Debugging once per setup is the only ceremony.
Under the hood
Four small programs, one link
Android app
Expo · React Native · Kotlin
Pairing, settings, and a foreground service that does clipboard sync, mirroring and the Bluetooth beacon — it survives the app being swiped away.
Mac menu-bar agent
Swift 6 · SwiftUI
Lives in the menu bar with a full dashboard window: your phone's status, clip history, notifications and message threads. Shows the pairing QR.
Relay server
Node.js · WebSocket
A deliberately dumb pipe. Two sockets meet in a room and it shovels opaque, encrypted bytes between them. Auth token, rate limiting, Docker-ready.
Privileged daemon
Java · dex
The clipboard helper the Android app starts through the phone's own ADB. It has the permissions regular apps lack, and keeps running on its own.