KeyPause

Ready to dust off your keyboard?

Pause your keys, wipe away the dust, and pick up exactly where you left off.

English · 한국어

---

Wiping a keyboard with the Mac awake means stray characters in your document, shortcuts firing, and brightness keys reacting to a cloth. KeyPause holds every keystroke for as long as you're cleaning, blacks out all your displays so you can actually see the dust, and gets out of the way the moment you're done.

It doesn't clean anything. It makes your Mac safe to clean.

• Nothing gets through — regular keys, modifiers, and brightness, volume, and media keys alike
• Every display goes black so dust and fingerprints show up
• Three ways out, always available
• No menu bar icon, no background process — launch it, clean, and it quits

Status: in development. There's no release yet. Build from source below.

The overlay above is the whole screen. Dots fill as you press Escape, and the countdown shows when it will unlock on its own.

Getting out

While keys are paused there are always three ways out:

Escape ×5	Consecutively. Any other key resets the count; holding it down does nothing.
Click Unlock	Mouse movement and clicks are never blocked.
Wait	Unlocks itself after a minute of no input. Adjustable from 30 seconds to 5 minutes.

Escape and Unlock quit the app — you've said you're done. The timer instead returns you to KeyPause's start screen and stays in front, because it can't know whether you finished, and a stray keystroke should land on KeyPause rather than in your document.

Requirements

macOS 13 Ventura or later, and Accessibility permission (System Settings → Privacy & Security → Accessibility). That permission is the only way to intercept keystrokes before they reach other apps.

Privacy

KeyPause reads key events only to discard them and to count consecutive Escape presses. It never records, stores, or transmits what you type. No account, no network access, no analytics.

It stores exactly one thing: your auto-unlock delay, in ~/Library/Preferences/. The source is here so you can check these claims rather than take them.

Building from source

git clone https://github.com/mabyko/KeyPause.git
cd KeyPause
open App/KeyPause.xcodeproj

Build and run the KeyPause scheme. A clean clone builds with the sacrificial bundle identifier forked.keypause.local; see docs/PLAN.md to set up your own.

The app is not sandboxed — sandboxing is incompatible with the event tap it relies on, which is also why KeyPause cannot ship on the Mac App Store.

Why did it unlock? — reading the log

KeyPause records when it starts blocking and why it stopped. It never records what you type.

/usr/bin/log show --predicate 'subsystem == "com.mabyko.keypause"' --last 1h --style compact

12:03:06  blocking started (auto-unlock after 60s)
12:03:47  released: idleExpired

Reason	What happened
unlocked	You pressed Escape five times or clicked Unlock.
idleExpired	No input for the configured delay. Raise it in the start screen if this keeps interrupting you.
tapLost	macOS switched off the input block and it could not be restored. KeyPause released rather than leave you looking at a black screen that no longer protects anything.
Secure Input이 활성	A password field had focus, so KeyPause refused to start.

If you see tapLost, please open an issue with the surrounding log lines — that path is hard to reproduce deliberately.

Uninstalling — order matters

tccutil can only reach a bundle identifier that still resolves to an installed app, so clear the permission first:

# 1. the Accessibility grant — BEFORE deleting the app
tccutil reset Accessibility com.mabyko.keypause

# 2. the app
rm -rf /Applications/KeyPause.app

# 3. your auto-unlock preference (~60 bytes)
rm -f ~/Library/Preferences/com.mabyko.keypause.plist

Step 1 is the one people miss, and running it out of order fails with No such bundle identifier. macOS does not revoke an Accessibility grant when you delete an app — the record stays in its permission database, keyed by bundle identifier, and System Settings simply stops showing rows it cannot resolve, so it looks cleared when it isn't. The practical consequence: install anything with the same bundle identifier later and it inherits the grant silently.

Already deleted the app? The grant is stranded. Reinstall, run step 1, then delete again.

Built it yourself? Substitute the identifier your build actually uses in steps 1 and 3 — a clean clone uses forked.keypause.local, and a personal Local.xcconfig uses whatever you set there. Check it with:

/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' /Applications/KeyPause.app/Contents/Info.plist

Known limitations

Deliberate, not oversights. Reasoning in docs/SPEC.md.

• The trackpad is not blocked. Scrolling and gestures still work, so wiping your trackpad is not covered.
• The Touch Bar is not covered by the overlay. Keystrokes from it are still blocked, but it stays lit.
• KeyPause won't start while Secure Input is active — for example, while a password field has focus. macOS takes those keystrokes first, so KeyPause refuses to start rather than fail silently.
• The login window and lock screen are out of scope.

Documentation

• docs/SPEC.md — what KeyPause does and why, including the reasoning behind each limitation
• docs/PLAN.md — flows, technical decisions, and build milestones

License

MIT © mabyko