TieZ: a Tauri clipboard manager with tags, WebDAV and MQTT sync

The problem TieZ targets: clipboard history that leaves the machine

A clipboard holds one item. The moment you copy something else, the previous item is gone. Every desktop operating system has added some form of history to soften this, but those histories are usually shallow, unsearchable, and tied to one machine. TieZ is aimed at people who copy constantly and want the history to survive a reboot and follow them to a second computer.

The README frames the project around four claims: instant access through native listeners and a Rust core, workflows built on rich text and tags, local-first storage with masking of sensitive data in previews, and sync over WebDAV or MQTT. The intended audience is stated indirectly. The installation table lists Windows 10 and 11 plus macOS Sierra 10.15 and later, and the repository topics include macos, windows, tauri, react, rust, mqtt and webdav. This is a desktop tool for developers and power users on those two platforms, not a server component and not a browser extension.

What separates it from a plain history list is the combination. Tags let you file an item rather than scroll for it. Sync means the item can be pasted on another device. Masking means the preview pane does not show a full ID number or phone number while you are screen sharing. Each of those is a separate design decision, and the README presents them together as the reason to choose TieZ over the clipboard history your OS already ships.

How TieZ is put together: Tauri shell, React UI, Rust core

The repository layout is the clearest description of the architecture. There is a src/ directory for the frontend, a src-tauri/ directory for the native side, and a root-level vite.config.ts with two tsconfig files. The package.json names the project tiez-app and lists @tauri-apps/api, @tauri-apps/plugin-dialog, @tauri-apps/plugin-opener, @tauri-apps/plugin-process and @tauri-apps/plugin-updater as dependencies, alongside React 19, react-virtuoso and react-window for list virtualisation, framer-motion for animation, prismjs for syntax handling, franc-min for language detection, and qrcode.react.

That dependency list tells you where the work happens. Clipboard capture, storage and sync are native responsibilities, which is why the README says native listeners and a Rust core. The frontend is a web view rendering the history list, the tag editor and the settings screens. Virtualisation libraries matter here because a clipboard history grows without bound; react-virtuoso and react-window both being present suggests different lists use different rendering strategies. franc-min is a language-detection library, which fits the global search feature: detecting the language of a copied string is useful when you are searching across mixed content.

The Tauri updater plugin is listed, so the app has an update path built in rather than requiring a manual re-download. The plugin-process dependency implies the app can restart or exit itself as part of that flow. None of this is unusual for a Tauri application, but it does mean the data flow is split: the UI never owns the clipboard, it asks the Rust side, and the Rust side owns whatever storage and network transports are configured.

Installing TieZ on Windows or macOS and capturing a first item

TieZ does not publish to a package manager according to the README. Installation is a download from the releases page, and the README's platform table gives the expected artefact for each platform: a .exe or a portable .zip on Windows, and a .dmg on macOS. Linux is listed as support coming soon with the output marked TBD, so there is no Linux build to install today.

On Windows, take the .exe if you want an installed application, or the .zip if you want a portable copy you can run from a folder without an installer. On macOS, open the .dmg and drag the app into place. The README does not describe code signing or notarisation, so if macOS refuses to open the app after installation, that is a gap in the documentation rather than something this article can resolve.

If you are building from source instead, the repository is a Vite project with Tauri scripts. The development command is defined in package.json and enables the devtools feature, which the release build does not:

npm install
npm run tauri:dev

The first command installs the frontend dependencies from package-lock.json. The second starts the Tauri development build with devtools enabled, which is what you want while inspecting the UI. For a production build without devtools, package.json defines:

npm run tauri:build

macOS builds are split by architecture. package.json has tauri:build:mac-arm for aarch64-apple-darwin and tauri:build:mac-intel for x86_64-apple-darwin, and release:all runs both in sequence. The Intel script sets RUSTUP_TOOLCHAIN to stable-aarch64-apple-darwin and points PATH, RUSTUP_HOME and CARGO_HOME at the usual locations under the home directory, which is a cross-compilation setup rather than a plain build.

Once the app is running, the workflow is the one the README describes: copy text, rich text, an image or a file path, and TieZ collects it. Open the history, apply a tag, and search by content, source app or date. The README's sequential paste feature is the one worth trying first, because it changes how you work rather than just storing what you copied.

Sync over WebDAV and MQTT, and what the README does not settle

TieZ offers two transports and they are not equivalent. WebDAV is a file-oriented protocol: you point the app at a server you control and it stores history there, which the README summarises as your data, your cloud. MQTT is a publish-subscribe messaging protocol, and the README describes it as optimised for real-time synchronisation between devices. The repository topics list both, and the README also mentions LAN file transfer for devices on the same network and a verification code sync feature that pushes OTP codes to your active device.

That last feature is the most opinionated thing in the README. Automatically forwarding one-time codes to another device is convenient and also a security decision, because an OTP is only as private as the transport carrying it. If you enable it over MQTT, the broker sees the code. The README does not state whether payloads are encrypted end to end before they reach the broker, and it does not describe the broker configuration fields. Treat that as unknown rather than assume it is handled.

The same caution applies to WebDAV. The README says data is local-first and that previews are masked, but it does not say whether the synced history is encrypted at rest on the WebDAV server or whether masking applies to the stored record or only to the on-screen preview. The phrase in the README is that masking happens in previews, which reads as a display-layer feature. If your threat model includes the sync target, that distinction matters and the documentation does not resolve it.

There is also no documented rollback. If you point TieZ at the wrong WebDAV directory, or a broker starts echoing stale messages, the README gives no procedure for undoing a sync. Set up the transport against an empty destination first.

Where TieZ is the wrong tool

Linux is the clearest boundary. The README lists Linux support as coming soon and the output as TBD, so on Linux there is nothing to install. The repository topics include neither linux nor a Linux packaging format, which is consistent with that. Anyone searching for a Linux clipboard manager should look elsewhere today.

The second boundary is the licence. TieZ is GPL-3.0. For an individual installing a desktop utility that is irrelevant. For a company that wants to bundle a clipboard manager into a product, or link it into a proprietary workflow, the copyleft terms change the calculus. That is a licensing question for your own counsel, not something this article can settle.

The third boundary is scope. TieZ is a desktop application for Windows and macOS. It is not a headless service, it is not a CLI, and the README does not describe an API. If you want clipboard history on a server, in a terminal session, or inside a CI job, TieZ does not address that. Similarly, if you only ever copy on one machine and never search your history, the operating system's built-in clipboard history is a smaller dependency with no sync surface to misconfigure.

Finally, the README is a marketing page more than a manual. It lists features in tables and shows theme screenshots, but it does not document configuration keys, storage format, retention defaults, or what happens when a sync target is unreachable. The advanced settings feature is described as granular control over cleanup rules, with no detail on what those rules are. Plan on reading the app's own settings screens rather than the README.

Compared with Ditto and CopyQ

Ditto is the reference point people search for alongside TieZ, and it is a long-standing Windows-only clipboard manager. The difference in approach is platform and architecture. Ditto is native Windows and stays there; TieZ is built on Tauri and ships on both Windows and macOS from the same codebase, with the src/ and src-tauri/ split in the repository. If you need one tool for a mixed Windows and Mac desk, Ditto cannot cover it. If you only use Windows and want a tool with a long track record, Ditto is the more conservative choice.

CopyQ is the other common comparison, and it is the more scriptable of the three. It is known for a command-line and scripting interface that lets you automate clipboard handling. The README for TieZ describes no scripting surface at all; its automation story is sequential paste and external editor collaboration, both interactive features. So the split is: CopyQ when you want to script what happens to clipboard content, TieZ when you want a graphical history with tags and built-in sync. TieZ's sync is the feature neither comparison point centres on, and that is the reason someone would pick it over either.

Editorial conclusion

Adopt TieZ if you work on Windows or macOS, want clipboard history stored locally, and already have a WebDAV endpoint or an MQTT broker you trust. Do not adopt it if you need Linux, if you want a package-manager install rather than a release download, or if you cannot accept a GPL-3.0 desktop application. Before installing, confirm that a matching asset exists on the releases page for your platform and architecture, and decide which sync transport you will configure, because the README does not document rollback if a sync target turns out to be wrong.

Frequently asked questions

Official sources

1. jimuzhe/tiez-clipboard on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases