How Clipwell is built
The architecture, technology choices, and decisions behind Clipwell.
This is the engineering companion to the user docs. It explains how Clipwell is built and why — the architecture, the technology choices, and the decisions recorded as ADRs.
The one-sentence version
Clipwell is a headless daemon that owns the clipboard and a SQLite history, and exposes it over three protocols (REST, WebSocket/SSE, MCP); every UI — including the first‑party picker — is just a client of that public API.
Architecture
The daemon, the capture pipeline, and the multi-protocol API surface.
Tech stack
.NET 10, Avalonia, SQLite, ASP.NET minimal APIs, the MCP C# SDK.
Decision records
The ADRs — what was decided, and the reasoning at the time.
Principles
- One source of truth. History lives in the daemon. Clients never reach around it.
- Dogfood the public API. The picker uses the same REST/WS endpoints third parties do — no privileged backchannel.
- Per‑OS behind interfaces. Clipboard capture, global hotkey, and paste each sit behind an interface with a platform implementation.
- Measure the promise. The picker's show‑cycle latency is logged so the single‑digit‑millisecond claim is backed by real numbers, not vibes.