Persistent Clipboard Systems: Windows vs. Linux Ecosystems

1. Executive Summary

The transition of the operating system clipboard from a volatile, single-buffer memory segment into a persistent, networked, and historical database represents a fundamental shift in human-computer interaction (HCI) and system architecture. This report provides an exhaustive, expert-level analysis of the Windows Clipboard History feature—introduced in Windows 10 Version 1803 and refined in Windows 11—juxtaposed against the fragmented yet highly capable landscape of Linux clipboard management systems. The scope of this analysis encompasses productivity utility, architectural security, forensic implications, and cross-device synchronization mechanics.

The investigation reveals a distinct dichotomy in design philosophy. Windows Clipboard History prioritizes seamless integration, ubiquity, and ease of use, leveraging the centralized Microsoft Cloud infrastructure to bridge the desktop-mobile divide.1 However, this convenience introduces significant privacy vulnerabilities, including non-end-to-end encrypted (E2EE) data transmission, forensic persistence in local SQLite databases, and potential metadata leakage through telemetry.3 Conversely, the Linux ecosystem, characterized by tools such as CopyQ, GPaste, and Cliphist, offers unparalleled granular control, scripting capabilities, and local data sovereignty, but suffers from fragmentation caused by the display server transition from X11 to Wayland.5

Furthermore, this report addresses the technical challenges inherent in developing a direct Linux equivalent to the Windows "Cloud Clipboard." It proposes a theoretical architecture for a secure, cross-distribution Linux clipboard system that leverages decentralized synchronization protocols (e.g., Syncthing) and compositor-level portals to match Windows' utility while bypassing its security deficits.

2. Historical Context and Evolution of the Clipboard

To understand the current state of clipboard management, one must appreciate the evolution of the underlying mechanisms. Historically, the clipboard was designed as a transient buffer. In the X11 architecture, this was managed via "selections" (Primary, Secondary, and Clipboard), relying on Inter-Client Communication Conventions Manual (ICCCM) standards. In Windows, the OLE (Object Linking and Embedding) clipboard provided similar functionality but remained ephemeral; data existed only as long as the source application remained open or the system remained powered.

The paradigm shift occurred with the realization that the clipboard is a proxy for user intent and short-term memory. Modern workflows require the retention of multiple distinct data fragments—code snippets, URLs, images, and credentials—simultaneously. This necessity drove the development of third-party "clipboard managers" (e.g., Ditto on Windows, Klipper on Linux) and eventually led Microsoft to integrate this functionality directly into the OS kernel and shell, effectively commoditizing the clipboard manager market.

3. Windows Clipboard History: A Monolithic Architecture

3.1 Functional Architecture and User Experience (UX)

The Windows Clipboard History is not merely an application but a system-level feature deeply integrated into SystemSettings.exe, Explorer.exe, and the input stack. Activated via the specialized keystroke Windows Key + V, it overlays a floating UI element on top of the active window, presenting a chronological list of copied items.1

3.1.1 Core Capabilities and Data Handling

The system is engineered to retain a history of the last 25 copied items. This First-In-First-Out (FIFO) buffer automatically purges the oldest non-pinned items as new content enters the stack.1 The retention mechanism distinguishes between "volatile" history and "pinned" items:

• Volatile History: Cleared upon system restart or user-initiated clearing.

• Pinned Items: Persist across reboots, transforming the clipboard into a rudimentary "snippet manager" for frequently used text blocks.1

The supported data types are intentionally limited to optimize performance and network bandwidth:

1. Plain Text: Standard ANSI/Unicode strings.

2. Rich Text Format (RTF): Text with basic formatting attributes.

3. HTML: Web content preserving links and layout.

4. Bitmap Images: Visual data, strictly capped at 4 MB per item.1

This 4 MB size limit is a critical architectural constraint.7 While necessary to prevent the local database (ActivitiesCache.db) from ballooning and to ensure rapid cloud synchronization, it significantly hampers utility for creative professionals who frequently manipulate high-resolution assets or vector graphics, forcing them to rely on traditional single-buffer copy-paste for larger files.

3.1.2 Cloud Synchronization and the "Roaming" Profile

The defining feature of the Windows implementation is the "Cloud Clipboard." When the "Sync across devices" toggle is enabled in System Settings, the OS hooks into the Connected Devices Platform (CDP).1 This allows for the near-real-time replication of clipboard content across any Windows 10/11 device logged into the same Microsoft Account (MSA).

The synchronization operates in two modes:

1. Automatic Sync: Every qualified item (under 4 MB, supported format) is encrypted, uploaded to the Microsoft Graph, and pushed to other devices.1

2. Manual Sync: Users must explicitly select items in the history UI to sync them. This mode offers a privacy compromise, allowing users to keep local history for sensitive items while sharing specific snippets.1

This integration extends to the mobile ecosystem via the Microsoft SwiftKey Keyboard on Android.2 By bridging the desktop-mobile gap, Microsoft creates a "walled garden" experience similar to Apple's Universal Clipboard, albeit relying on a cloud relay rather than local peer-to-peer (P2P) proximity networking.

3.2 Forensic Artifacts and Local Storage Mechanisms

A critical aspect of the Windows architecture is data persistence. Unlike traditional clipboards that reside in RAM, Windows Clipboard History is backed by a disk-based database. This has profound implications for digital forensics and privacy.

3.2.1 The ActivitiesCache.db Database

Forensic research identifies the ActivitiesCache.db file as the central repository for clipboard history. This SQLite database is typically located at:

C:\Users\%USERNAME%\AppData\Local\ConnectedDevicesPlatform\<UserProfile>\ActivitiesCache.db.4

Within this database, the ActivityOperations table records clipboard events. Specific forensic indicators include:

• ActivityType 10: Denotes data residing in the clipboard.8

• ActivityType 16: Denotes a copy or paste operation.4

• Payload: The actual content is stored in the ClipboardPayload column, typically as a Base64 encoded string.7

3.2.2 Implications of Forensic Persistence

The existence of this database means that "clearing" the clipboard history via the UI does not necessarily sanitize the disk immediately. SQLite databases often use a Write-Ahead Log (WAL) (ActivitiesCache.db-wal) or leave deleted records in unallocated pages until a "vacuum" operation occurs.7 Consequently, sensitive data such as passwords, credit card numbers, or cryptographic keys copied to the clipboard may remain recoverable by forensic tools long after the user believes they have been deleted. This persistence vector makes the Windows Clipboard a significant target for malware and forensic investigators alike.

3.3 Shortcomings regarding Productivity and Utility

While the Windows implementation excels in accessibility, it falters in depth and power-user utility.

1. Arbitrary Capacity constraints: The hard limit of 25 items is non-configurable.1 For developers, researchers, or data entry specialists who may need to reference a history of 50-100 items, this limitation forces the adoption of third-party tools like Ditto or Clipboard Master.9

2. Lack of Search Granularity: The search function within Win+V is rudimentary, lacking support for Regular Expressions (Regex), date-range filtering, or application-specific filtering.9

3. Data Type Exclusion: The rejection of proprietary formats (e.g., CAD objects, complex serialized data) and large files (>4 MB) means the history feature cannot serve as a complete backup for the system clipboard.1

4. No Scripting/Automation: Unlike Linux counterparts, Windows Clipboard History is strictly a storage and retrieval system. It cannot automatically modify text (e.g., stripping formatting, converting case) or trigger scripts upon capture.11

4. Security Architecture and Privacy Analysis

The integration of cloud synchronization introduces a massive expansion of the threat surface. This section analyzes the security model of the Windows Clipboard and contrasts it with Linux philosophies.

4.1 Encryption and Trust Models

4.1.1 Service-Side vs. Client-Side Encryption

Microsoft documentation asserts that clipboard data is "encrypted in transit and at rest".1 However, careful analysis of the security architecture reveals that this is likely Service-Side Encryption (SSE) where Microsoft holds the decryption keys, rather than client-side End-to-End Encryption (E2EE).3

The distinction is critical. In an E2EE model (Zero Knowledge), the service provider (Microsoft) transmits encrypted blobs they cannot read. In the current Windows model, the data must be decryptable by the service to process the "Roaming" functions across different devices that may not share a pre-exchanged private key. This implies that:

1. Internal Access: Technically, Microsoft personnel or automated systems (e.g., for spam/malware detection or AI training) could potentially access clipboard contents.14

2. Legal Compulsion: Data stored in the Microsoft Cloud is subject to subpoena and law enforcement requests, unlike data that never leaves the local machine.12

4.1.2 The "Password Leak" Vector

Users frequently use the clipboard to move passwords from managers (like Bitwarden or KeePass) to login fields. If Cloud Sync is enabled, these plain-text passwords are uploaded to the cloud.14 While password managers often attempt to use the CF_EXCLUDECLIPBOARDCONTENT flag or clear the clipboard automatically, implementation is inconsistent. If an application fails to flag data as sensitive, Windows treats it as generic text and syncs it.14

4.2 Corporate and Enterprise Control

Recognizing these risks, Microsoft provides mechanisms for enterprise administrators to restrict this feature.

• Group Policy (GPO): Administrators can disable Clipboard History and Cloud Sync via Computer Configuration > Administrative Templates > System > OS Policies.15

• Intune/MDM: Policies allow for the segregation of "Corporate" vs. "Personal" clipboard data.

• Edge for Business: Features like "Protected Clipboard" define trusted boundaries, preventing data from being pasted from managed enterprise apps into unmanaged personal apps or browsers.16

This level of control is robust for enterprise environments but relies on the administrator actively configuring these restrictions. For the average consumer or "Bring Your Own Device" (BYOD) worker, the default settings favor convenience (sync enabled) over security.12

5. The Linux Clipboard Management Landscape

The Linux ecosystem operates on fundamentally different architectural principles. There is no singular "Linux Clipboard." Instead, clipboard functionality is a derivative of the display server protocol—traditionally X11, and increasingly Wayland. This distinction drives the capabilities and limitations of Linux clipboard managers.

5.1 X11 vs. Wayland: The Security Schism

5.1.1 The Legacy X11 Model

Under the X Window System (X11), the clipboard is a global, shared resource. Any application connected to the X server can query the clipboard contents at any time without explicit user permission.

• Productivity Implication: This allows for robust, highly compatible clipboard managers (e.g., Parcellite, Diodon, CopyQ) that work "out of the box".5

• Security Implication: The model is inherently insecure. A malicious background process (keylogger or spyware) can silently monitor the clipboard (CLIPBOARD and PRIMARY selections) and harvest sensitive data.18

5.1.2 The Wayland Security Model

Wayland was designed to rectify X11's security flaws by enforcing strict isolation. By default, a Wayland client cannot read the clipboard contents of another client unless it has input focus.

• Productivity Implication: This security model "breaks" traditional clipboard managers, which rely on background monitoring. A clipboard manager in Wayland cannot passively "listen" to copy events.6

• The Solution (Portals and Protocols): To restore functionality, Wayland compositors (like Sway, Hyprland, GNOME's Mutter) have implemented privileged protocols such as wlr-data-control or the xdg-desktop-portal Clipboard interface. These allow authorized tools (like cliphist or wl-paste) to act as a designated clipboard manager.21

5.2 Comparative Analysis of Leading Linux Tools

The Linux ecosystem offers a diverse array of tools that, when configured correctly, exceed Windows in raw power but lag in integration.

Feature Dimension	CopyQ	GPaste	Cliphist	Windows History
Primary Ecosystem	Cross-Platform (Qt)	GNOME (GTK)	Wayland (TUI/CLI)	Windows Shell
History Capacity	Unlimited / Configurable	Configurable	Unlimited (Disk)	Fixed (25 Items)
Search Engine	Advanced Regex / Scripting	Basic Search	Fuzzy Search (via Rofi)	Basic Text Match
Scripting / Actions	Yes (ECMAScript)	No	Pipe to Scripts	No
Image Support	Yes	Yes	Yes (Binary blobs)	Yes (<4MB)
Cloud Sync	No (Manual Plugin)	No	No	Yes (Native)
Security Model	Local storage (Encrypted tabs optional)	Local Daemon	Local Binary Store	Cloud + Local DB

5.2.1 CopyQ: The Power User's Benchmark

CopyQ represents the pinnacle of clipboard utility. It introduces the concept of Tabs, allowing users to segregate clipboard history into categories (e.g., "Code," "Work," "Personal"). Its defining feature is the Scripting Interface: users can write JavaScript-like scripts to automatically transform data.11

• Example: A script can detect if a copied string is a hex color code and automatically append the RGB equivalent.

• Example: A script can detect a URL and automatically fetch the page title to store alongside the link.
  This programmability makes CopyQ a productivity multiplier that Windows cannot match.

5.2.2 Cliphist: The Wayland Native

For users on modern Wayland compositors (Hyprland, Sway), cliphist has emerged as the standard. It functions as a lightweight daemon that serializes clipboard data (text and images) to disk. Unlike the GUI-heavy Windows interface, cliphist is designed to be piped into fuzzy finders like rofi or wofi, allowing for keyboard-driven, instantaneous searching of thousands of items.21

6. The Synchronization Gap: Bridging Linux Devices

The most glaring functional deficit in Linux compared to Windows is the lack of a native, seamless "Cloud Clipboard." However, the community has developed decentralized alternatives that offer superior privacy.

6.1 KDE Connect: The LAN Approach

KDE Connect provides a robust ecosystem for device integration over a Local Area Network (LAN).

• Mechanism: It uses TLS (Transport Layer Security) to encrypt communication between devices.24

• Clipboard Sync: It supports bi-directional clipboard synchronization.

• The Android Restriction: Modern Android versions (10+) restrict background apps from reading the clipboard for privacy reasons.25 This breaks the "automatic" sync from Phone to PC.

• Workarounds: Users must either manually click "Send Clipboard" in the KDE Connect notification or use ADB (Android Debug Bridge) commands (adb shell pm grant...) to grant the app special READ_LOGS or overlay permissions to bypass these restrictions.25

6.2 Syncthing: The Decentralized Approach

For users who require sync outside the LAN or wish to sync persistent history databases (like CopyQ's tabs), Syncthing offers a peer-to-peer file synchronization solution.

• Integration with CopyQ: CopyQ supports synchronizing specific tabs with a disk directory. By pointing Syncthing to this directory, users can effectively sync their clipboard history across computers without a central cloud server.28

• Latency: The trade-off is latency. Syncthing is optimized for file integrity, not real-time chat-like speed. Synchronization may take seconds rather than milliseconds.29

6.3 Command-Line Solutions

Tools like croc and ClipCascade provide secure, ephemeral file and text transfer.

• Croc: Uses PAKE (Password Authenticated Key Exchange) for secure transfers through relays, ensuring E2EE.30

• ClipCascade: A Rust-based tool designed to mimic the "Universal Clipboard" functionality using a client-server architecture that can be self-hosted, bypassing the limitations of LAN-only tools like KDE Connect.31

7. Comparative Analysis Summary

7.1 Productivity and Utility

Capability	Windows Clipboard History	Linux (CopyQ / Cliphist)
Ease of Access	High (Win+V is pervasive)	Medium (Requires setup/binding)
Data Capacity	Low (25 items, 4MB limit)	High (Unlimited, configurable)
Search Power	Low (Basic text match)	High (Regex, fuzzy finding, tags)
Automation	None	High (Scripting, Actions)
Context	Passive (Storage only)	Active (Can execute commands)

Insight: Windows prioritizes accessibility for the novice user, creating a low barrier to entry. Linux tools prioritize efficiency for the expert user, trading setup complexity for long-term speed and capability.

7.2 Security and Privacy

Attribute	Windows Ecosystem	Linux Ecosystem
Data Location	Local DB + Microsoft Cloud	Local Disk + User-defined Sync
Encryption	Service-Managed Keys (Not E2EE)	User-Managed (GPG/SSH/TLS)
Forensics	High Persistence (ActivitiesCache.db)	Variable (Depends on config)
Trust Model	Trust Microsoft (Centralized)	Trust Self / Open Source (Decentralized)
Leak Potential	High (Cloud sync defaults)	Low (No default sync)

Insight: The "Cloud Clipboard" is a convenience feature that acts as a surveillance device by design. It centralizes user data. Linux's lack of a default cloud clipboard is a feature, not a bug, for privacy-conscious users.

8. Proposal for a "Universal" Linux Clipboard Solution

The request asks for a proposal to develop a Linux equivalent to the Windows Cloud Clipboard if one does not exist. While tools exist, a unified, "it just works" solution is missing.

8.1 The "OpenClipSync" Architecture

I propose a modular system, theoretically named "OpenClipSync", designed to provide the seamless experience of Windows with the security of Linux.

8.1.1 Component 1: The Compositor-Agnostic Daemon

To solve the Wayland/X11 fragmentation, the core daemon must leverage the xdg-desktop-portal infrastructure.

• Mechanism: The daemon registers as a portal client. It requests org.freedesktop.portal.Clipboard access.22

• Fallback: For compositors without portal support, it falls back to wl-paste --watch (Wayland) or xcb (X11).

• Function: It listens for changes and writes payloads to a secure local store.

8.1.2 Component 2: The Encrypted Storage Vault

• Storage Format: A SQLite database similar to Windows, but with column-level encryption using SQLCipher or Libsodium.

• Key Management: The encryption key is derived from the user's login keyring (GNOME Keyring / KWallet), ensuring that the clipboard is unreadable if the user is not logged in.

8.1.3 Component 3: The Sync Layer (The Cloud Replacement)

Instead of building a central server (which mimics Windows' privacy flaws), OpenClipSync should utilize an Encrypted Peer-to-Peer Mesh.

• Protocol: Integration with Syncthing Core (via its Go library) or Libp2p.

• Topology: Devices discover each other via DHT (Distributed Hash Table) or Local Discovery.

• Transport: WebRTC for traversing NATs without manual port forwarding.

• Data Flow:

1. Copy Event on Device A.

2. Daemon encrypts payload with a shared pre-shared key (PSK).

3. Payload is pushed via QUIC/TLS to Device B.30

4. Device B decrypts and injects into its local clipboard.

8.1.4 Component 4: The Mobile Bridge (Android)

To match Windows/SwiftKey, an Android app is required.

• Challenge: Android 10+ background restrictions.

• Solution: The app implements an Accessibility Service (a legitimate use case for clipboard managers) to monitor the clipboard without root, or uses the READ_LOGS permission workaround for power users.25

• Sync: The Android app acts as a node in the Libp2p/Syncthing mesh.

8.2 Feasibility Analysis

• Technical Feasibility: High. All components (Syncthing, xdg-desktop-portal, SQLite, Libsodium) are mature open-source technologies.

• Practicality: The main barrier is distribution. Packaging this solution to work seamlessly across Fedora (SELinux enabled), Arch (bleeding edge), and Ubuntu (Snap-focused) requires significant effort in packaging (Flatpak/Snap) and permission management.

9. Conclusion

The Windows Clipboard History feature is a triumph of integration, successfully modernizing a decades-old interface paradigm. It empowers the average user with history and cross-device flow with zero configuration. However, this convenience is inextricably linked to the Microsoft data ecosystem, creating a persistent forensic trail and a potential data leak vector through non-E2EE cloud storage.

The Linux ecosystem offers a powerful, albeit fragmented, alternative. Tools like CopyQ and Cliphist provide productivity ceilings far higher than Windows, with unlimited history, advanced scripting, and complete data sovereignty. The "Cloud Sync" gap, while real, is bridged by secure, decentralized tools like KDE Connect and Syncthing, which prioritize privacy over convenience.

For the security-conscious professional, the Linux approach—specifically a localized manager combined with an encrypted P2P sync channel—is the only responsible choice. For the generalist seeking efficiency, Windows remains superior, provided the privacy trade-offs are understood and accepted. The proposed "OpenClipSync" architecture represents the ideal future: a system that combines the seamless utility of Windows with the trustless security architecture of Linux.

Works cited

1. Using the clipboard - Microsoft Support, accessed December 30, 2025, https://support.microsoft.com/en-us/windows/using-the-clipboard-30375039-ce71-9fe4-5b30-21b7aab6b13f

2. How to use Microsoft SwiftKey Keyboard to copy and paste text between SwiftKey and Windows, accessed December 30, 2025, https://support.microsoft.com/en-us/topic/how-to-use-microsoft-swiftkey-keyboard-to-copy-and-paste-text-between-swiftkey-and-windows-85c8ca64-7091-477f-91d1-99c3b1f75138

3. Sync.com claims it's end-to-end encrypted and that they can't decrypt your data stored on their servers. That's false. : r/DataHoarder - Reddit, accessed December 30, 2025, https://www.reddit.com/r/DataHoarder/comments/17tyupn/synccom_claims_its_endtoend_encrypted_and_that/

4. Clipboard Payloads via ActivitiesCache.db | Detection - Insider Threat Matrix, accessed December 30, 2025, https://insiderthreatmatrix.org/detections/DT090

5. Best Open Source Linux Clipboard Managers 2025 - SourceForge, accessed December 30, 2025, https://sourceforge.net/directory/clipboard-managers/linux/

6. Keeping the clipboard alive - Ξ, accessed December 30, 2025, https://blog.ce9e.org/posts/2024-09-04-clipboard/

7. How to Perform Clipboard Forensics: ActivitiesCache.db, Memory Forensics and Clipboard History - @inversecos, accessed December 30, 2025, https://www.inversecos.com/2022/05/how-to-perform-clipboard-forensics.html

8. Windows.Forensics.Clipboard :: Velociraptor - Digging deeper!, accessed December 30, 2025, https://docs.velociraptor.app/exchange/artifacts/pages/windows.forensics.clipboard/

9. The Best Clipboard Managers for Every Platform - TextExpander, accessed December 30, 2025, https://textexpander.com/blog/best-clipboard-managers

10. The 5 best clipboard managers for every device in 2025 - Zapier, accessed December 30, 2025, https://zapier.com/blog/best-clipboard-managers/

11. CopyQ - GitHub Pages, accessed December 30, 2025, https://hluk.github.io/CopyQ/

12. Windows 11 Privacy Settings: How to Protect Your Data and Stay Secure, accessed December 30, 2025, https://windowsforum.com/threads/windows-11-privacy-settings-how-to-protect-your-data-and-stay-secure.375073/

13. Encryption in the Microsoft cloud, accessed December 30, 2025, https://learn.microsoft.com/en-us/purview/office-365-encryption-in-the-microsoft-cloud-overview

14. Warning : With Windows 11, the clipboard is stored on the cloud - Password Manager, accessed December 30, 2025, https://community.bitwarden.com/t/warning-with-windows-11-the-clipboard-is-stored-on-the-cloud/52401

15. How to Enable or Disable Windows 10 Clipboard History - NinjaOne, accessed December 30, 2025, https://www.ninjaone.com/blog/enable-or-disable-clipboard-history-in-windows/

16. Microsoft Edge for Business: Protected Clipboard (In Preview), accessed December 30, 2025, https://learn.microsoft.com/en-us/deployedge/microsoft-edge-management-protected-clipboard

17. Ctrl+C Ctrl+V Made Better With These Clipboard Managers in Linux - It's FOSS, accessed December 30, 2025, https://itsfoss.com/linux-clipboard-managers/

18. Wayland clipboard broken till when? - 1Password Community, accessed December 30, 2025, https://www.1password.community/discussions/1password/wayland-clipboard-broken-till-when/157146

19. How can I limit a program's ability to use certain Wayland features such as recording the screen or accessing the clipboard? : r/swaywm - Reddit, accessed December 30, 2025, https://www.reddit.com/r/swaywm/comments/k2xmgq/how_can_i_limit_a_programs_ability_to_use_certain/

20. [Feature request] A clipboard manager portal · Issue #743 · flatpak/xdg-desktop-portal, accessed December 30, 2025, https://github.com/flatpak/xdg-desktop-portal/issues/743

21. Clipboard Managers - Hyprland Wiki, accessed December 30, 2025, https://wiki.hypr.land/Useful-Utilities/Clipboard-Managers/

22. Clipboard - XDG Desktop Portal documentation - Flatpak, accessed December 30, 2025, https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.Clipboard.html

23. Scripting API - CopyQ documentation - Read the Docs, accessed December 30, 2025, https://copyq.readthedocs.io/en/latest/scripting-api.html

24. KDEConnect - KDE UserBase Wiki, accessed December 30, 2025, https://userbase.kde.org/KDEConnect

25. How to sync clipboard in KDE Connect/Android 11? - Ask Ubuntu, accessed December 30, 2025, https://askubuntu.com/questions/1345176/how-to-sync-clipboard-in-kde-connect-android-11

26. KDE Connect ClipBoard sync - Help, accessed December 30, 2025, https://discuss.kde.org/t/kde-connect-clipboard-sync/6422

27. 446366 – No way to send clipboard from Android to a desktop, if the persistent indicator is disabled. - KDE bug tracker, accessed December 30, 2025, https://bugs.kde.org/show_bug.cgi?id=446366

28. Synchronize with Documents - CopyQ documentation - Read the Docs, accessed December 30, 2025, https://copyq.readthedocs.io/en/latest/synchronize.html

29. Sync not happening quickly enough for CopyQ - Support - Syncthing Community Forum, accessed December 30, 2025, https://forum.syncthing.net/t/sync-not-happening-quickly-enough-for-copyq/22731

30. schollz/croc: Easily and securely send things from one computer to another :package - GitHub, accessed December 30, 2025, https://github.com/schollz/croc

31. ClipCascade is a lightweight utility that automatically syncs the clipboard across devices, no key press required. - GitHub, accessed December 30, 2025, https://github.com/Sathvik-Rao/ClipCascade

32. This free and open-source self-hosted app syncs your clipboard across all of your devices, accessed December 30, 2025, https://www.xda-developers.com/open-source-self-hosted-app-syncs-clipboard-across-devices/

33. Add Clipboard Control to xdg-desktop-portal backend (!53) · Merge requests - GitLab, accessed December 30, 2025, https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/53