Copywarden: the clipboard, encrypted.

why

The most sensitive buffer on your Mac.

Think about what crosses your clipboard in a day: passwords that miss the password manager, API keys, patient names, deal terms, that one production connection string. Clipboard managers make that history persistent — and the popular ones persist it in plaintext. Copywarden is built for the people who can never leak a clip: clinicians, bankers, defense contractors, and the engineers who support them. The pitch is one sentence: the Bitwarden of clipboard management.

crypto architecture

Keys that never leave the hardware.

Every clip is encrypted with AES-256-GCM before it touches disk, under a per-item key derived via HKDF-SHA256 from a randomly generated 256-bit master key. On Macs with a Secure Enclave, the master key is stored wrapped by a non-extractable Enclave key (ECIES) — the Enclave holds the wrapping key and never releases it. Older Macs fall back to Keychain-only storage: device-local, non-synchronizable, accessible only while the Mac is unlocked. Around the crypto core: biometric gates on sensitive reveals, idle re-lock after inactivity, and secure memory scrubbing after use. Per-item keys mean one compromised buffer never becomes a skeleton key for the whole history.

the signature feature

Your history is not for the meeting.

The feature that started the whole project: when Copywarden detects screen capture, recording, or a video-call share — Zoom, Teams, Meet, OBS and more — it redacts every preview behind a privacy banner. Your clipboard history stops being an accidental slide in someone else’s screenshot. Detection is best-effort and the threat model says so, in public — a security tool that overclaims is worse than no tool, so the docs state plainly what it can and cannot see, alongside debugger detection and clipboard-access anomaly monitoring.

shipping it

Solo doesn’t mean unserious.

A one-person product needs a release path that never depends on someone remembering a step, so it’s fully automated: CI runs lint, unit, and UI tests — plus mutation testing, because test suites lie — then builds universal arm64 + x86_64 binaries, signs with Developer ID, submits for Apple notarization, and publishes. Builds through 0.8 go out this way. The product site is a static export served from S3 behind CloudFront — the same stack I run at work, because I trust the tools I operate.

$ ./scripts/release.sh 0.6.0
test      unit · ui · mutation ✓
build     universal (arm64 + x86_64) ✓
sign      Developer ID ✓
notarize  submitted → Accepted
publish   copywarden.com ✓
$ 

lessons

What building it alone taught me.

• Honesty is a security feature. Publishing a threat model that admits detection is best-effort earned more trust than any marketing claim could.
• Owning every layer changes how you build. Crypto design, Swift concurrency, CI, signing, notarization, DNS, CDN — there’s no “someone else’s problem” on a solo product, and that discipline transfers straight back to platform work.
• Local-first is a spine, not a checkbox. Nothing syncs unless the user turns it on; end-to-end encrypted sync is code-complete and stays off by default.

where it stands

Built, and still being sharpened.

The product exists: signed, notarized universal builds, an encrypted store, the redaction behavior described above, and a published threat model and disclosure policy at copywarden.com. The encrypted-sync transports (iCloud, then WebDAV and peer-to-peer on the same ciphertext envelope) are in verification.

It isn’t public yet, and that’s deliberate — I’d rather hold it than ship something that loses to the incumbents on the first comparison. What it already proves is the part I care about here: I can take a security product from crypto design through CI, signing, notarization, DNS and CDN by myself, and hold it to a standard the marketing page states plainly — only claims we can prove.