# GPaste: a GNOME clipboard daemon with named histories and password handling > GPaste is a clipboard management system for GNOME written in C, combining a daemon that keeps persistent named histories, a GTK 4 interface, a GNOME Shell extension and a CLI. It fits GNOME users who copy and paste repeatedly and care about secrets leaving the clipboard, and it does not fit other desktops. **Keruspe/GPaste** — Clipboard management system - Repository: https://github.com/Keruspe/GPaste - Stars: 951 · Forks: 71 - Language: C - License: BSD-2-Clause - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/keruspe-gpaste ## One daemon, several named histories, and a Shell extension GPaste is described plainly: a clipboard management system for GNOME, made of a daemon that remembers what you copy, a GTK 4 interface, a GNOME Shell extension and a CLI to get it back. Four front ends over one service, and the split is what makes it usable in practice. The daemon holds the history. The GTK 4 tool, launched by a shortcut, gives you a window to browse, search, merge and edit. The GNOME Shell extension adds a menu entry in the panel that names the history currently in use and lets you switch to, create, empty, back up or delete one. The CLI, gpaste-client, gives you the same operations from a script or a keybinding. The design decision that shapes everything else is the set of named histories. You can keep several and switch between them, and each can be backed up and deleted independently. For a single clipboard, one history would be enough. The moment history is something you navigate, categories start to matter, and the README says the history in use is named in the Shell menu for exactly that reason. The scope is GNOME and GNOME only. The build depends on gnome-control-center, gcr and the Shell extension, and one build option, gnome-shell, is on by default because it controls both the extension and the mutter clipboard backend. This is a GNOME citizen, and the rest of this review is about what that buys and what it costs. ## Three storage backends, switchable at any time Where the history is stored is a choice you make, and the README names three backends: an XML file, a per-history SQLite database that persists incrementally, or nothing at all. The XML file is the simple case. The SQLite backend is per history, so each named history is its own database, and it persists incrementally rather than rewriting everything on each change, which matters for a large history of images and rich text. The third option, no storage, is the one privacy sensitive users reach for: history lives in memory and is gone when the session ends. You are not locked into a choice made at install time. The README says the backend can be switched at any time from the preferences or with a client command: ```bash gpaste-client migrate ``` That is a genuinely useful operation and it is also a risk. Migrating moves a history you care about between storage formats, and because the same data is being rewritten, the moment of migration is the moment worth having a backup. The README's separate mention of backing up a history from the Shell menu is the natural companion to it. Images are handled with a checksum, so the same picture copied twice is stored once. Depending on the backend, images are kept as files or as database blobs. Everything you copy is claimed to be captured: plain text, rich text, HTML, images, URIs and colours. That breadth is the reason the tool feels complete, and it is also the reason the storage backend matters, since rich content is where the size and memory limits will bite first. ## Password entries are excluded from the plain-text history The password handling is the most interesting mechanism in the project, and the README is unusually detailed about it, including about its own limits. The basic idea is that an item can be marked as a password. Once marked, it is shown as a name instead of its contents, and it is excluded from the plain-text history. Give it a timeout and the clipboard stops handing it out once that timeout runs out. Marking is available from the UI, and there is a default shortcut for it, Ctrl+Alt+S, which marks the active item as a password if it is a text one. The interoperability part is more interesting still. A text that a password manager marks as a secret, using KDE's x-kde-passwordManagerHint, is taken in as a password on its own, and GPaste marks the passwords it puts on the clipboard the same way, so other clipboard managers can recognise them. There is a documented catch: current GTK advertises the marker on X11 but cannot serve its value, so other managers may not recognise GPaste passwords there. Two edge cases are spelled out. Deleting a password entry clears its selection, including after a rename, and a separate named entry with the same value is kept distinct rather than merged. There is also a rate-limiting angle, via the optional pwquality build option, described as rating a passphrase or a password as it is typed. And the passphrase for the encrypted history can be kept in the keyring through the optional libsecret option. The result is a clipboard that can hold a secret without that secret sitting in an ordinary history entry. ## Global shortcuts are routed through the XDG portal so Wayland and X11 behave alike Clipboard managers on Linux have a long-standing problem: keyboard shortcuts that work under X11 often stop working under Wayland, because the server no longer lets a client grab the keyboard globally. GPaste's answer is to route shortcuts through the XDG portal, so the behaviour is the same on both, and there is one switch in the preferences that turns every shortcut off. The default bindings are worth reading as a set, because they show the intended workflow. Ctrl+Alt+H shows the history, Ctrl+Alt+G launches the graphical tool, Ctrl+Alt+V pops the first item off the history, and Ctrl+Alt+S marks the active item as a password. Two more deal with the X11 primary selection, which is the middle-click selection that has no equivalent in most other applications: Ctrl+Alt+O syncs the clipboard to the primary selection and Ctrl+Alt+P syncs the primary selection back to the clipboard. The last, Ctrl+Alt+U, uploads the active item to a pastebin. All of them are configurable in the preferences, and the same operations are reachable from the CLI, the UI and the Shell extension, which is how the project avoids having one narrow path to each feature. The favourites mechanism is worth separating from the rest. Pin an item and the history never drops it on its own: the size and memory limits give way instead. The list can then be filtered down to the pinned items from the UI, the extension or the CLI. In practice that means a snippet you rely on daily cannot be evicted by a burst of image copies, which is the standard failure mode of a size-limited clipboard history. ## Installing is one command per distribution, and the extension still needs enabling GPaste is packaged widely, and the README lists the commands. On Fedora: ```bash sudo dnf install gpaste gpaste-ui gnome-shell-extension-gpaste ``` On Arch Linux a single package covers the daemon, the graphical tool and the extension: ```bash sudo pacman -S gpaste ``` On Debian and Ubuntu the package name carries a version digit: ```bash sudo apt install gpaste-2 gnome-shell-extension-gpaste ``` On openSUSE: ```bash sudo zypper install gpaste ``` The README notes that GPaste is packaged in plenty of other distributions, naming Alpine, nixpkgs, Void and Gentoo, with Repology tracking which version each one ships. That is a useful pointer when you need to know what a given distribution is currently carrying. One manual step survives every route: wherever it came from, enable the extension in the Extensions app once it is installed. A user who installs the package and sees nothing happen has most likely missed this, not misconfigured the daemon. Building from source is a meson and ninja job. The README gives the build and optional dependencies for rpm and deb systems separately, then the same sequence everywhere: ```bash git clone https://github.com/Keruspe/GPaste.git cd GPaste meson setup build ninja -C build sudo ninja -C build install sudo glib-compile-schemas /usr/share/glib-2.0/schemas/ ``` The final line matters and is easy to skip. Without recompiling the GLib schemas, the settings the daemon expects are not registered. ## The Debian package name tracks an old API and the library requirements are new Two version facts decide whether GPaste will install cleanly on your machine. The first is the Debian and Ubuntu package name. The digit in gpaste-2 tracks the library API version, and the README says it becomes gpaste-3 once the release lands. Ubuntu's copy lives in universe and lags a long way behind, several major versions even on the current LTS, while Debian unstable keeps up. If you are on Ubuntu, the version you install from the archive is not the version described in the README, and that gap is where surprises live. The second is the library floor for a source build. The README states that GPaste currently needs GLib 2.90, GTK 4.24, libadwaita 1.10 and gcr 4, and adds that libadwaita is newer than anything Debian ships outside experimental, so a deb-based build of the 51 series needs one built by hand. On rpm systems the build dependencies are listed as a single dnf line, with an optional second line for libsodium, sqlite, libsecret, libpwquality, gobject-introspection and vala, all of which are on by default when found. The build options make the trade-offs explicit, and every feature option defaults to auto, meaning enabled when the dependency is present and skipped otherwise. So a missing optional library silently removes a feature rather than failing the build, which is convenient and also means you should read the configure output to see what you actually got. A minimal build is available: ```bash meson setup build -Dgnome-shell=false -Dintrospection=false -Dvapi=false ``` That drops the Shell extension, the GIR data and the Vala bindings. The sqlite option needs SQLite 3.35 or newer, and the systemd option controls the systemd user unit. Packaging also matters for the build itself: dbus, systemd and gnome-control-center are wanted for their pkg-config files alone, to say where the service, interface, unit and keybinding files go, and a packager can name those four directories with -Ddbus-services-dir, -Ddbus-interfaces-dir, -Dsystemd-user-unit-dir and -Dcontrol-center-keybindings-dir instead. ## What GPaste does not do, and the lighter alternative to a history daemon GPaste has limits that come from its shape rather than from bugs. The first is desktop scope. Everything about the packaging, the extension and the mutter clipboard backend assumes GNOME. The keyboard shortcut path needs the XDG portal, and the Shell integration is the Shell integration, so on KDE or Xfce none of that integration is present. The README also records a specific interoperability gap, since current GTK advertises the x-kde-passwordManagerHint marker on X11 but cannot serve its value, so other managers may not recognise GPaste passwords there. The second is that the password feature is not a password manager. It marks an item so it is hidden and can time out. It does not store credentials, does not generate them, and does not tell you where a secret came from. The optional libsecret option only remembers the passphrase for the encrypted history in the keyring. The third is size. The history obeys size and memory limits, and only favourites are exempt. A history stuffed with images and rich text will hit those limits, which is the reason the deduplication by checksum and the choice of storage backend matter. The lighter alternative is a clipboard watcher with no history, no daemon and no desktop integration, which simply keeps the current selection. The difference in approach is exactly the point: such a tool has nothing to install into a session, nothing to configure and no way to retain what you copied, and on Wayland it can only manage what the compositor lets it see. GPaste trades that lightness for a persistent, searchable, multi-category history with secret handling. Which side of that trade you should take depends on whether you re-paste old snippets often enough to feel the difference, and on whether you are on GNOME at all. ## Conclusion Adopt GPaste if your day is spent on GNOME, you reuse snippets often enough to want history, and you want clipboard secrets marked as such so they expire instead of sitting in plain text for anyone to paste. Do not adopt it on KDE, Xfce or a headless box, and do not expect it to replace a password manager, because it remembers what you copied rather than what you own. Before installing, read the Debian and Ubuntu paragraph in the README, since the packaged gpaste-2 tracks an older library API and Ubuntu's copy lags several major versions, and check the GLib 2.90, GTK 4.24 and libadwaita 1.10 requirements if you plan to build from source. ## FAQ ### How do I install GPaste on Ubuntu? The README gives sudo apt install gpaste-2 gnome-shell-extension-gpaste for Debian and Ubuntu, and notes that the digit tracks the library API version so it becomes gpaste-3 once the release lands. Ubuntu's copy lives in universe and lags several major versions, while Debian unstable keeps up. After installing, enable the extension in the Extensions app. ### How does GPaste keep clipboard secrets out of the normal history? An item can be marked as a password, in which case it is shown as a name instead of its contents and excluded from the plain-text history, and a timeout makes the clipboard stop handing it out. A text marked as a secret by another password manager using KDE's x-kde-passwordManagerHint is taken in as a password automatically. ### Can I move my GPaste history to a different storage backend? Yes. The README says the backend can be switched at any time from the preferences or with gpaste-client migrate, and lists the choices as an XML file, a per-history SQLite database that persists incrementally, or no storage at all. ### Do the GPaste keyboard shortcuts work on Wayland? The README says global shortcuts go through the XDG portal so they behave the same on Wayland and X11, and that one switch in the preferences turns every shortcut off. The default bindings include Ctrl+Alt+H to show the history and Ctrl+Alt+S to mark the active item as a password. ### What are the build requirements for GPaste from source? The README states that GPaste needs GLib 2.90, GTK 4.24, libadwaita 1.10 and gcr 4, and that libadwaita is newer than anything Debian ships outside experimental, so a deb-based build of the 51 series needs one built by hand. The build uses meson setup build followed by ninja -C build, and the schema files must be recompiled with glib-compile-schemas. ## Sources - [Issues](https://github.com/Keruspe/GPaste/issues) - [Keruspe/GPaste on GitHub](https://github.com/Keruspe/GPaste) - [License: BSD-2-Clause](https://github.com/Keruspe/GPaste/blob/master/LICENSE) - [README](https://github.com/Keruspe/GPaste/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/keruspe-gpaste