Which Wayland compositors support clipboard managers

Mutter implements neither data-control protocol, so every tool built on wl-paste --watch fails here regardless of how well it works elsewhere. A GNOME Shell extension sidesteps the question by running as JavaScript inside Mutter's own process, where it can reach the internal selection API directly. The trade-off is that a GNOME version bump can break every extension at once.

Muffin is Mutter's fork and inherits the same gap without inheriting GNOME's extension route, which makes Cinnamon the least served of the mainstream desktops on a Wayland session. Cinnamon's Wayland session is still marked experimental and Mint defaults to X11, so in practice most Cinnamon users are on X11 — where every X11 clipboard manager works normally.

KDE skipped the wlroots protocol and implemented the standardised ext-data-control-v1 instead, so KWin is the clearest case of "supports one, not the other". Klipper ships with Plasma and needs no protocol at all. External tools work too, subject to the version gate below.

Hyprland implements ext-data-control-v1 and wlr-data-control, which means it works with both current tools and older ones written against the wlroots protocol. This is the configuration most clipboard-manager documentation assumes.

Sway is the wlroots compositor the original wlr-data-control protocol was designed against, and it has since added the standardised successor as well. Everything in the usual Wayland clipboard stack works here.

niri implements both data-control protocols, so the standard scrolling-WM clipboard stack works without special handling.

System76's compositor implements both data-control protocols, which puts COSMIC in a better position for clipboard managers than either GNOME or Cinnamon out of the box.

labwc is a wlroots-based stacking compositor in the Openbox tradition and implements both data-control protocols.

Wayfire is the mirror image of KWin: it implements wlr-data-control and not the standardised successor. A tool written strictly against ext-data-control-v1 will find nothing here, while anything built on the wlroots protocol works fine.

river implements wlr-data-control only. The common tools all still bind it, so in practice the usual stack works.

phoc is the compositor behind the Phosh mobile shell and implements wlr-data-control only. Clipboard managers are an unusual thing to want on a phone, but the protocol is there.

Canonical's compositor library implements the standardised protocol and not the wlroots one, so it has the same version considerations as KDE.

Deepin's compositor implements both data-control protocols.

An independent compositor written in Rust, implementing both data-control protocols.

GameScope is a micro-compositor for running games under a fixed resolution and refresh rate. Clipboard history is not a use case it serves, and on a Steam Deck the desktop mode you would actually want it in runs KWin instead.

Cage runs exactly one application fullscreen. There is no second client to hold a clipboard history, which is why the protocol is absent rather than an oversight.

Louvre is a C++ library for building compositors rather than a compositor people run as a desktop. Whether clipboard managers work depends on what a downstream author implements on top of it.

Weston exists to demonstrate the protocol, and the core protocol deliberately withholds clipboard access from unfocused clients. No clipboard manager can watch the selection on a Weston session.