§ Feature

Clipboard history and secret vault

Press ⌥V, type a few characters of something you copied an hour ago, hit Return. The part most clipboard managers skip: anything that looks like a credential never enters the history in the first place.

previous copied
Press Option-V, choose an item, and paste it.

Keyboard-only retrieval

The panel opens on ⌥V with the search field already focused. Type to filter, ↑ ↓ to move, ⏎ to paste, esc to dismiss. While the panel is open, ⌥1 through ⌥9 and ⌥0 jump straight to the first ten entries — so the common case, “the thing I copied just before this one”, is ⌥V then ⌥2, with no searching at all.

Nothing here needs the mouse, which is the point. It is a retrieval surface, not a clipboard manager you are meant to curate.

Secrets are diverted, not stored and hidden

Every clipboard write passes through a scanner built on gitleaks detection rules before it is recorded. When a value matches — an API key, a token, a private key block — it is written to the macOS Keychain and shown masked in a separate vault view. The plaintext never lands in the history database at all.

The distinction matters. A clipboard manager that stores your sk-proj-…key and then marks it “sensitive” in the UI has still written it to disk in a searchable store. KeyMic’s history never receives it.

What it deliberately ignores

Where it lives

History is a local SwiftData store on your Mac, with an in-memory fallback if the disk store cannot initialise. It is not uploaded and not synced — if you enable settings sync, that covers preferences and keybindings, never clipboard contents. Vault entries stay in the Keychain and never leave it.

The server enforces the same line from its side: the settings-sync endpoint rejects any payload carrying a secret-shaped key rather than storing it. See Security & Architecture for the full data-flow.

Download for MacmacOS 14.0+ · 4.5 MB · AGPL-3.0 · v1.0.3

Also in KeyMic: keyboard remapping, or see everything on one page.