clipferry

Name: clipferry
Author: bkrdmrcioglu

Overview Schema Source Related Servers Discussions Admin

Clipferry is a small app for macOS and Windows that keeps one clipboard across the computers on your desk. Install it on both, pair them with a 9-digit code, and anything you copy on one shows up on the other. The computers find each other on your Wi-Fi and talk directly, end-to-end encrypted. It also:

Catches secrets before they travel. API keys, tokens, private keys, passwords and one-time codes are recognised on your device. By default they sync masked and are deleted everywhere after a few minutes. You can also keep them on the device or sync them normally.
Remembers and searches. Every clip from every device lands in a searchable history, newest first, with the device and time. You can pin the ones you reuse.
Talks to AI tools. Cursor, VS Code, Windsurf and any other MCP client can ask "what did I just copy on my other machine?"
Keeps your data yours. Clips go straight from one computer to the other over your local network. Nothing passes through a cloud, and nothing needs to be set up besides the app. Different networks (home Mac, office PC)? Add an optional relay you run yourself.

How it works

        MacBook                        same Wi-Fi                     Windows PC
 ┌──────────────────┐        encrypted, direct (no server)     ┌──────────────────┐
 │ Clipferry        │ ◄──────────────────────────────────────► │ Clipferry        │
 │  clipboard       │                                          │  clipboard       │
 │  history         │     found each other with Bonjour/mDNS   │  history         │
 │  MCP ◄─ AI tools │                                          │  MCP ◄─ AI tools │
 └──────────────────┘                                          └──────────────────┘

You copy something. Clipferry checks whether it looks like a secret, saves it to the local history and encrypts it with your ferry key (XChaCha20-Poly1305).
The encrypted clip goes straight to your other computers on the same network. They find each other with Bonjour/mDNS, the same way AirDrop and printers are found.
Each device decrypts the clip, adds it to its own history and puts it on the clipboard, ready to paste.

Pairing uses a password-authenticated key exchange (PAKE) over the 9-digit code, so the code never travels and a wrong guess fails. The ferry key is handed over only after the exchange succeeds. If one computer is asleep, the other catches it up on whatever it missed when it wakes.

Related MCP server: ClipMCP

Screenshots

Install

macOS with Homebrew:

brew install --cask bkrdmrcioglu/tap/clipferry

Or download the latest build from Releases: the .dmg for macOS, -windows-setup.exe for Windows.

macOS (11 Big Sur or later, Apple silicon and Intel)

Open Clipferry-x.y.z-macos.dmg and drag Clipferry into Applications.
Open it. The first time, macOS may say the app is from an unidentified developer. Right-click Clipferry in Applications, choose Open, then Open again.
A clipboard icon appears in the menu bar, and the Clipferry window opens. When macOS asks whether Clipferry may find devices on your local network, click Allow. That is how it finds your PC.

Windows (10 and 11, x64 and ARM)

Run Clipferry-x.y.z-windows-setup.exe. It installs for your user only, without administrator rights. If SmartScreen warns you, click More info → Run anyway.
Clipferry starts and its icon appears in the system tray, next to the clock. Click the ^ arrow if it is hidden. When Windows Firewall asks, allow Clipferry on private networks. That is how your Mac reaches it.

Prefer no installer? Clipferry-amd64.exe (or -arm64.exe) is a portable single file. Clipferry uses Microsoft Edge WebView2 for its window, which is preinstalled on Windows 10 and 11.

Clipferry lives in the menu bar (macOS) or system tray (Windows); closing its window keeps it running. To have it start with your computer, turn on Start Clipferry when this computer starts in the welcome card or in Settings. The same option is in the icon's menu as Start at login.

Updates and languages

Clipferry checks for new versions a few times a day. With Install updates automatically on (the default, in Settings), it downloads the new version, checks it against the SHA-256 checksum published with the release, installs it and restarts by itself. You can also check and install by hand from Settings → Updates, or from Install update in the icon's menu when one is waiting. Builds from source (go run, development versions) never update themselves.

The app is available in English and Turkish. It follows your system language, and you can choose another in Settings → Language. To add a language, translate internal/ui/dist/i18n.js and the tray menu texts in cmd/clipferry/main.go.

Pair your computers

Both computers must be on the same network (the same Wi-Fi, or Wi-Fi and Ethernet on the same router).

On the first computer, open Clipferry and click Show a code.
On the second computer, click Enter a code and type it.
Done. Copy on either one and paste on the other.

If the second computer cannot find the first, check that:

both are on the same network, and not on a guest network with "client isolation";
Clipferry was allowed through the Windows Firewall and has macOS's local network permission (System Settings → Privacy & Security → Local Network).

To add a third device, use Add a device in the menu or the Devices panel. A pairing code works once and expires after 5 minutes.

Secrets

Clipferry looks for the following before anything leaves your device:

Detected	Examples
Cloud and API keys	AWS, GitHub, GitLab, AI providers, Stripe, Slack, Google, npm
Tokens	JSON Web Tokens
Private keys	`-----BEGIN … PRIVATE KEY-----`
Credentials in text	`password=…`, `api_key: …`, `postgres://user:pass@host`
Codes and cards	6–8 digit one-time codes, card numbers (Luhn-checked)
Password-like strings	random-looking single tokens with mixed character classes
Password managers	anything 1Password, Bitwarden, KeePass and others mark as concealed

In Settings → Passwords, keys and codes you choose what happens to them:

Sync briefly (default): synced and shown masked, then deleted from every device's history after 1–60 minutes. If it is still on your clipboard at that point, the clipboard is cleared too.
Keep local: never leaves this device and is not stored in history.
Sync normally: synced and kept, but still masked in the UI.

AI tools never see secret contents unless you turn on Let AI tools read secrets. They are told that a secret was copied, and of what kind.

Connect an AI tool (MCP)

Each Clipferry app serves an MCP endpoint on this computer at http://127.0.0.1:47823/mcp, protected by a per-device token. Click the plug icon in the Clipferry window to get a ready-to-paste config with your token filled in.

Cursor: ~/.cursor/mcp.json

{
  "mcpServers": {
    "clipferry": {
      "url": "http://127.0.0.1:47823/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

VS Code: .vscode/mcp.json

{
  "servers": {
    "clipferry": {
      "type": "http",
      "url": "http://127.0.0.1:47823/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

Tool	What it does
`get_latest_clip`	The most recent clip, optionally only from another device (`from_other_device: true`) or a named device
`list_recent_clips`	Recent history across devices, optionally for one device
`search_clips`	Search the history
`list_devices`	The devices sharing this clipboard

Any other MCP client that supports Streamable HTTP takes the same URL and Authorization header.

Clients that only start local processes (stdio): use clipferry-mcp, a small standalone server that reads the history the app keeps on the same computer. It does not need the app to be open. Download it for your platform from Releases, or run go install github.com/bkrdmrcioglu/clipferry/cmd/clipferry-mcp@latest, then configure:

{
  "mcpServers": {
    "clipferry": { "command": "clipferry-mcp" }
  }
}

Then ask your assistant something like "Use the error I just copied on my Windows machine" or "Find the SQL query I copied yesterday".

Different networks? Run a relay (optional)

Same Wi-Fi needs nothing else. If your computers are on different networks (a Mac at home, a PC at the office), they need a meeting point. A Clipferry relay is a tiny server that forwards the already-encrypted clips and cannot read them. Run it on any server you have:

git clone https://github.com/bkrdmrcioglu/clipferry
cd clipferry
docker compose up -d

Put it behind HTTPS (Coolify, Caddy, Traefik, nginx…). Then, on every device, open Settings → Connection, choose Relay server and enter wss://your-relay.example.com. To keep strangers off your relay entirely, set CLIPFERRY_RELAY_TOKEN and enter the same token on your devices.

Coolify: create a new resource from this Git repository using the Docker Compose build pack, set a domain for the relay service on port 8080, and deploy.

The relay keeps the last 20 encrypted messages of each ferry for 24 hours, so a laptop that was asleep still catches up. It stores nothing on disk.

Build from source

You need Go 1.26+. Building the macOS app also needs the Xcode command line tools.

go test ./...                 # unit tests + end-to-end test
./scripts/build-macos.sh      # dist/Clipferry.app and a .dmg (on macOS)
./scripts/build-windows.sh    # dist/Clipferry.exe, plus the installer if NSIS is installed
go run ./cmd/clipferry-relay  # a relay on :8080

Try it without two computers

go run ./cmd/clipferry-demo

This starts two simulated devices ("MacBook Pro" and "Windows PC") on a simulated local network in one process, pairs them, copies some sample clips, and prints a URL for each device's window. Add CLIPFERRY_UI_DIR=internal/ui/dist to edit the UI live.

Project layout

Path	What
`cmd/clipferry`	Desktop app (Wails v3): tray/menu bar icon, window, start at login
`cmd/clipferry-relay`	The optional relay server, for devices on different networks
`cmd/clipferry-mcp`	Standalone MCP server over stdio, reading the app's history
`cmd/clipferry-demo`	Two simulated devices for development
`internal/core`	Engine: clipboard watching, secret policy, sync, local API, MCP
`internal/ferry`	Connections and code pairing (PAKE)
`internal/lan`	Finding devices on the local network (mDNS)
`internal/relay`	Relay protocol; every device also runs one for its local network
`internal/box`	Encryption and key derivation
`internal/secrets`	Secret detection
`internal/store`	Local SQLite history with full-text search
`internal/sysclip`	Native clipboard access for macOS and Windows
`internal/ui/dist`	The app window (plain HTML, CSS and JS, no build step) and its translations
`internal/update`	Self-update from GitHub releases, verified against published checksums

Security notes

Everything sent between devices is encrypted with a 256-bit key shared only by your paired devices, whether it goes over your network or through a relay.
For same-network sync, each device listens on TCP port 47824 on your local network. A device that is not paired sees only encrypted bytes.
The local API and MCP endpoint listen on 127.0.0.1 only. They require this device's token and reject requests whose Host is not a loopback name (protection against DNS rebinding).
The history is stored unencrypted on each device, in ~/Library/Application Support/Clipferry (macOS) or %APPDATA%\Clipferry (Windows), like any clipboard manager's. Secrets in Sync briefly mode are removed from it when they expire.
Leave this ferry stops a device from syncing. Removing a lost device from a ferry for good requires a new ferry for now: leave the ferry on every device and pair them again. Key rotation is on the roadmap.
Release builds are not code-signed yet, hence the first-launch warnings above.

How Clipferry compares

	Clipferry	KDE Connect	LocalSend	ClipCascade	Pushbullet
Automatic Mac ↔ Windows clipboard sync	✓	✓ (weak on macOS)	manual send	✓	✓
Needs a server or account	no	no	no	your own server	account
Works across different networks	with your own relay			✓	✓
Setup	install + code	install + accept	install	run a server	account
End-to-end encrypted	✓	✓	✓	✓	partly
Secrets detected and expired	✓
Searchable history	✓
AI tools (MCP)	✓
Open source / self-hostable	✓ / ✓	✓ / n.a.	✓ / n.a.	✓ / ✓	✗ / ✗

Roadmap

Images and small files
Signed and notarized builds
Linux app
Ferry key rotation when a device is removed

License

MIT

Available Tools

4 tools

get_latest_clipB

Get the most recently copied text, optionally only from another device ("what I just copied on my other machine").

Name	Required	Description	Default
`device`	No	Only consider clips from the device with this name
`from_other_device`	No	Only consider clips copied on another device of the ferry

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, yet it discloses nothing about the safety/scope profile. It does not say what happens when no clip exists, whether 'most recent' is scoped to the current device by default, whether results are sync-fresh, or what the return shape is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the core action first, followed by a short illustrative parenthetical that earns its place by anchoring a real use case. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with zero required parameters and full schema coverage, this covers the essentials of what it does. It is still thin on failure/empty behavior and on how device and from_other_device interact when both are supplied, which matters since there are no annotations to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, making 3 the baseline. The description does slightly reinforce the intent by framing from_other_device as 'optionally only from another device,' but adds no distinction between using the device name filter versus the boolean flag.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get the most recently copied text,' which is unambiguous about what the tool returns. It does not name the sibling it differs from, but 'most recently' plus the optional-device scoping is enough to distinguish it from list_recent_clips and search_clips without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The quoted scenario ("what I just copied on my other machine") implies when to reach for it, giving a concrete user intent. However, it never states when NOT to use it or that list_recent_clips/search_clips are the alternatives for browsing or querying, leaving the routing decision partly to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_devicesB

List the devices that share this clipboard.

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden; 'List' implies a safe read, but it says nothing about whether inactive/current devices are included, whether results are scoped to the authenticated user, or what fields a device entry carries. For a zero-parameter read this is an acceptable but thin disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, fully front-loaded, no filler. Nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should hint at what a device record contains or at least that the result is a device collection; it only restates the listing action. Adequate for a trivial zero-param tool, but return-shape information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The single sentence is consistent with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('devices') scoped to 'this clipboard', which inherently separates it from the sibling tools that all operate on clips. It stops short of an explicit differentiation sentence, but the resource noun alone is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus the clip-oriented siblings, no prerequisites, and no note on scope (e.g., which clipboard or account). The agent must infer usage entirely from the resource noun.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_recent_clipsA

List recent clipboard history across the user's devices, newest first.

Name	Required	Description	Default
`limit`	No	How many clips to return, 1-50 (default 10)
`device`	No	Only clips from the device with this name

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It usefully discloses the result ordering (newest first) and cross-device scope, but says nothing about permissions, auth, pagination behavior, or what a returned clip contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-formed sentence with zero waste, front-loading the action and the scoping/ordering constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-optional-parameter list tool this is close, but with no output schema the description should say what a clip record looks like and how results beyond the limit behave. The absence of sibling differentiation also leaves routing incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both the limit (1-50, default 10) and device filter are already documented. The description adds no syntax or semantics beyond what the schema provides, making the baseline 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list clipboard history) with scope qualifiers: across devices and newest-first ordering. It does not, however, distinguish itself from the close sibling get_latest_clip or from search_clips, which an agent must infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the word 'recent' suggests browsing rather than targeted lookup, but the description never says when to prefer this over search_clips or get_latest_clip, nor any conditions for using it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_clipsA

Search the clipboard history of all the user's devices for text.

Name	Required	Description	Default
`limit`	No	How many clips to return, 1-50 (default 10)
`query`	Yes	Text to look for in the clipboard history

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does add useful behavioral context — that the search spans all of the user's devices and targets text rather than metadata — but it says nothing about matching semantics (substring vs fuzzy), permission/auth requirements, or result ordering. It conveys a read-only, non-destructive character only by implication of 'search'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, with the resource and cross-device scope front-loaded. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter search tool with a fully documented schema, the description covers what it searches and where. However, with no annotations and no output schema, an agent still lacks matching semantics and any hint about result shape or ordering, which the description could have supplied in a clause.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'query' and 'limit' are already documented with ranges and defaults. The description adds no meaning beyond the schema — it does not clarify matching behavior for 'query' or how limit interacts with ordering. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('search') and resource ('clipboard history') plus a scope ('all the user's devices') and content type ('text'). This differentiates it reasonably from list_recent_clips and get_latest_clip, though it never explicitly contrasts itself with those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the word 'search' plus the cross-device scope suggests it is the tool for query-driven lookup rather than browsing recent items. There is no explicit statement of when to prefer list_recent_clips or get_latest_clip instead, and no prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.2.1Oct 26, 2026
- First observedget_latest_clip
- First observedlist_devices
- First observedlist_recent_clips
- First observedsearch_clips

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-10-26 17:30 across 4 tools

Disambiguation4/5

Each tool has a distinct verb+target: get single latest clip, list devices, list history, search text. The only mild overlap is get_latest_clip versus list_recent_clips, since the former is effectively a single-item version of the latter, but the descriptions ('what I just copied on my other machine' vs 'history newest first') make the intent clear enough.

Naming Consistency5/5

All four names follow a clean snake_case verb_noun pattern (get_latest_clip, list_devices, list_recent_clips, search_clips). Verbs (get/list/search) accurately reflect the operation type with no stylistic drift.

Tool Count4/5

Four focused, read-oriented tools fit a narrow clipboard-sync domain without bloat. The surface is slightly thin (no way to push/set a clip or manage devices), but each tool clearly earns its place.

Completeness3/5

Read paths are well covered: latest, history, search, and device enumeration. However, there is no write/push operation to send clipboard content to another device, no delete/clear history, and no per-clip retrieval by ID, which are notable gaps for a clipboard-sharing service.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Related MCP Connectors

ReMCP BOAuth
site.remcp
Securely control computers you explicitly pair through files, terminals, processes, screenshots, desktop UI/input, clipboard, browser automation, diagnostics, and document tools.
Command Line File Systems OS Automation
1741
https://remcp.site/mcp
Local MCP BOAuth
com.local-mcp
Mac & Windows: let ChatGPT, Claude & Cursor use your email, calendar, iMessage, Teams, files.
Calendar Management Email File Systems
297373
https://local-mcp.com/mcp
Local Commander BOAuth
app.localcmd
Give your AI hands on every computer you own. Remote control of your Windows, Mac and Linux machines from one ChatGPT, Claude or Cursor chat — even from your phone. Ask it to find out why the office server is crawling, update every PC in the house, sort out your mom's laptop from another city, or ship the site from your work machine while you're on a train. It runs commands, reads files and takes a screenshot when it needs to see the screen. You decide what each computer allows, and you can cut any of them off in a second.
CI/CD & DevOps Command Line OS Automation
251
https://localcmd.app/mcp
ASR Memory (에사 AI) — Shared memory for AI toolsOAuth
com.asrmemory
Shared memory for AI tools: save once, recall word for word from Claude, ChatGPT, Codex or Gemini.
Knowledge & Memory Note Taking
1
https://asrmemory.com/mcp

Related MCP Servers

Maccy Clipboard MCP
vlad-ds
A
license
Not graded
quality
D
maintenance
An MCP server that gives Claude and other AI assistants access to your Maccy clipboard history, allowing search, retrieval, and management of copied content through natural conversation.
Updated a year ago (2025-07-21 12:15 UTC)
9
MIT
ClipMCP
Developer Tools Knowledge & Memory Search
susmetaa01
A
license
Not graded
quality
D
maintenance
A standalone clipboard history MCP server for macOS that monitors clipboard in real-time, stores history locally in SQLite, and exposes it to any MCP-compatible AI assistant.
Updated 6 months ago (2026-04-19 14:40 UTC)
5
MIT
clipboard-history-mcp
Knowledge & Memory Security
d-khomenko
A
license
Not graded
quality
D
maintenance
Enables Claude to browse, search, and restore clipboard history with type classification, secret detection, and Touch ID-gated decryption.
Updated 3 months ago (2026-08-01 21:23 UTC)
19
MIT
CrossPasteofficial
Workplace & Productivity Image & Video Processing Search
CrossPaste
A
license
A
quality
A
maintenance
Open-source cross-device clipboard manager with a built-in MCP server. Search and retrieve clipboard history synced across all your devices, read OCR text extracted from copied images, and add new items to the clipboard.
Updated 2 days ago (2026-10-25 03:32 UTC)
5
2,661
AGPL 3.0

How it works

Screenshots

Install

macOS (11 Big Sur or later, Apple silicon and Intel)

Windows (10 and 11, x64 and ARM)

Updates and languages

Pair your computers

Secrets

Connect an AI tool (MCP)

Different networks? Run a relay (optional)

Build from source

Try it without two computers

Project layout

Security notes

How Clipferry compares

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

CrossPasteofficial