clipcat: a clipboard daemon and clients in Rust, driven by dmenu or rofi

A daemon, a CLI and a menu client, not one program

Clipcat is a clipboard manager written in Rust, and the interesting decision is that it is three programs rather than one.

The architecture is described as client-server, with two role types, Server and Client. The clipcat daemon runs as a background process and performs four tasks: it watches for changes to the clipboard, it caches clipboard content, it inserts content into the clipboard, and it acts as a gRPC server waiting for remote procedure calls from clients.

The clients then divide the work. clipcatctl is the command line client, providing a command line interface, and it sends three operations to the server: List to list the cached clips, Insert to replace the current content of the clipboard with a clip, and Remove to remove cached clips from the server.

clipcat-menu is the third program, a client that calls a built-in finder or an external finder for selecting clips. The documentation shows demonstrations with three different external finders, Rofi, dmenu and skim, and there is a screenshot for each, so the project treats the picker as a pluggable choice rather than shipping its own menu.

That split is what makes the tool scriptable. The daemon owns the state, so anything that can talk to the daemon can read and write the clipboard history, and the menu client is a thin wrapper over that interface. The audience is a Linux desktop user who wants a clipboard history without a heavy GUI application, and who is comfortable with a daemon and a config file.

The licence is GPL-3.0-only, the default branch is develop, and the last push was on 2026-10-19, with the workspace version at 0.26.0.

The X11 selections, and why your history fills with stray words

The most useful section in the README for a new user is the one about X11 and Wayland clipboard selections, because it explains a behaviour that otherwise looks like a bug.

On X11 and Wayland there are multiple clipboard-like selections. The standard Clipboard is what Ctrl+C and Ctrl+V use. The Primary selection is the mouse selection, the text you highlight with the mouse, which you paste with the middle mouse button. The Secondary selection is described as a rarely used, historical X11 feature.

Clipcat can watch any combination of these selections, using enable_clipboard and enable_primary in the [watcher] section of the configuration.

If you have used a Unix desktop for any length of time, you know the consequence. Highlight a word in a document and it is now in your clipboard history. Do that a few times and your history is a pile of single words and short fragments that you did not copy on purpose.

The documentation gives the fix as a tip. If you want to track only standard Ctrl+C copying, set enable_primary = false and synchronize_selection_with_clipboard = false.

That is a better default than most clipboard managers on Unix, and it is a small piece of configuration knowledge that a reader of the source would otherwise have to discover by trial and error. Note that the tip is about the [watcher] section, so this is a server-side setting rather than something the menu client controls.

gRPC over TCP and over a Unix socket, plus D-Bus

The feature list names gRPC support twice, once for gRPC over HTTP and once for gRPC over a Unix domain socket, and separately lists D-Bus support. That is a lot of ways for a client to reach a local daemon, and the choice has consequences.

The Rust dependency list shows the stack behind it. Tonic at version 0.14 with the gzip feature is the gRPC framework, with prost and prost-types for the protobuf layer and tonic-prost-build for the code generation. Axum and tower with a timeout feature handle the HTTP side, and hyper-util sits underneath. The protobuf definitions live in their own crate, crates/proto, which is where the service definition and the message types are generated from.

A Unix domain socket is the better choice for a local daemon because it keeps the traffic off the network stack entirely, and a client that connects over HTTP is the option for a remote session. Offering both means the same protocol serves two deployment shapes.

D-Bus support is the more interesting of the two, because D-Bus is the native interprocess channel on a Linux desktop and a lot of the surrounding tooling already speaks it. The crate list includes zbus, the Rust D-Bus implementation, and there is a dedicated crates/dbus-variant package, which suggests the D-Bus interface is a separate wire format for the same operations rather than a translation layer over gRPC.

The consequence for a user is that any script can drive the clipboard history through whichever interface is convenient, and a desktop application that already talks D-Bus does not have to learn gRPC to reach the daemon.

Three config files, and why using the wrong one is a parse error

The Usage section opens with a setup step and a warning that will save you a confusing afternoon.

Each program has its own separate configuration file, and you have to use the correct default-config command for each one. clipcatd default-config produces clipcatd.toml, the server config. clipcatctl default-config produces clipcatctl.toml, and clipcat-menu default-config produces clipcat-menu.toml.

Using the wrong config file, for example using the clipcatctl config for clipcatd, will result in parse errors. The failure mode is a parse error rather than a silent misconfiguration, which is the better of the two, but the setup is three separate commands and the directory has to exist first:

# Create the config directory first
mkdir -p "$XDG_CONFIG_HOME/clipcat"

# Generate default configs for each program
clipcatd default-config      > "$XDG_CONFIG_HOME/clipcat/clipcatd.toml"
clipcatctl default-config    > "$XDG_CONFIG_HOME/clipcat/clipcatctl.toml"
clipcat-menu default-config  > "$XDG_CONFIG_HOME/clipcat/clipcat-menu.toml"

The files land in $XDG_CONFIG_HOME/clipcat, so the layout follows the XDG base directory convention, and the config format is TOML, with a toml.toml formatter configuration in the repository root alongside taplo.toml, the TOML language server configuration, and treefmt.toml and rustfmt.toml for the rest of the formatting.

The workspace is split into the three programs plus nine library crates, and the library names describe the design: crates/base, crates/cli, crates/client, crates/clipboard, crates/dbus-variant, crates/external-editor, crates/metrics, crates/proto and crates/server. The presence of crates/external-editor and crates/metrics tells you the project has hooks for a text editor workflow and for exposing usage data, even though the README does not describe them in detail.

Running the daemon, and the Wayland and macOS caveats

Starting the daemon is two commands, and the documentation insists you read the help first:

# Show the usage. Please read the usage before doing any other operations.
clipcatd help

# Start and daemonize clipcatd. It will run in the background.
# You can use `pkill clipcatd` to stop it; a `SIGTERM` signal will be sent to clipcatd.
clipcatd

# Alternatively, you can start clipcatd but keep it in the foreground.
# You can press `Ctrl+C` in your terminal to stop it; a `SIGINT` signal will be sent to clipcatd.
clipcatd --no-daemon

The daemonize and foreground split is a small quality of life detail that a lot of daemons get wrong, and the documentation explains the signal behaviour for both, so you know what to expect from pkill and from Ctrl+C.

The platform support is where the caveats live. The feature list marks X11 as supported, Wayland as experimental, and macOS as supported. The Architecture section then details the windowing system integrations for X11 and Wayland only, using x11rb and arboard on X11, and wl-clipboard-rs with arboard on Wayland, with arboard shared between them.

So the honest summary is that X11 is the mature path, Wayland is explicitly experimental, and macOS is a supported target without the same set of windowing integrations spelled out. On X11 the clipboard protocol is a well understood selection mechanism, and on Wayland the data control protocol that arboard's wayland-data-control feature talks to is the newer and less settled route, which is why the experimental label is there.

The arboard dependency is configured in the workspace with default-features = false and the image-data and wayland-data-control features enabled, so the image support and the Wayland path both come from that one crate.

Where clipcat is the wrong choice

The first case is a Wayland desktop, and this is the constraint that will decide it for most people reading now. Wayland support is marked experimental in the feature list. A clipboard manager that misses selections or fails to restore them is worse than no clipboard manager, because you find out at the moment you paste.

The second case is a macOS user expecting the system clipboard history. macOS is in the feature list as supported, but the architecture documentation covers the X11 and Wayland integrations and says nothing about how the macOS path works, and the rest of the project is shaped around Unix conventions such as the Primary selection, dmenu, rofi and D-Bus. The macOS entry is real, but the project around it is a Unix one.

The third case is a user who wants a graphical application with search, previews and a settings UI. What is described here is a daemon plus command line clients plus an external picker, which is a configuration and keyboard workflow, not a mouse-and-window one.

The alternative worth comparing is a clipboard manager that ships its own GUI, of which there are many for X11 and Wayland, some written in Rust and some not. The difference in approach is where the state lives and who draws the menu. Clipcat keeps the state in a daemon and lets you pick the menu, so you get the picker you already like and a history you can also reach from a shell script or a keybinding, and the cost is that you configure three config files and run a background process. A self-contained GUI gives you a polished single application with no daemon to manage, at the price of no scriptable interface and one more Electron or GTK process on your desktop.

Editorial conclusion

clipcat fits a Linux user on X11 who wants a clipboard history they can drive from the keyboard and script against, since the daemon, the command line client and the menu client are separate programs with a gRPC or D-Bus interface between them. It is the wrong choice for a Wayland desktop in 2026, since that support is marked experimental, and it is the wrong choice for a macOS user who expects a native clipboard history, since the macOS support in the feature list is not matched by the same set of windowing integrations described elsewhere. Before adopting it, generate each program's own default config with its own default-config command, because the three binaries use separate files and mixing them produces parse errors, and decide whether you want the Primary selection tracked alongside the standard clipboard before you set enable_primary and synchronize_selection_with_clipboard.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. xrelkd/clipcat on GitHub