A free, open-source macOS menu bar app that scans every registered keyboard shortcut across your apps, Karabiner-Elements, skhd, and macOS system shortcuts, then shows exactly where they collide. No accounts, no telemetry, no dependencies.
Hi everyone. I make small Mac utilities, and several of them depend on global keyboard shortcuts. Every time I wanted to assign a new one, I had to guess whether it was already claimed by another app, a system shortcut, or an automation tool. There was no simple way to check, so I built HotkeyClash.
It scans every registered shortcut on your Mac in a single pass and shows you exactly where they conflict, with app icons and source badges. It also separates real conflicts (two global hotkeys on the same combo) from harmless overlaps (two apps reusing a shortcut in their own menus).
It is completely free and open source under GPL-2.0. No accounts, no telemetry, no network access, zero third-party dependencies. Signed and notarized by Apple. macOS 14 and up.
This is the first release, so I would love your feedback, bug reports, and feature requests. Next up: parsers for Keyboard Maestro, BetterTouchTool, Hammerspoon, Alfred, and Raycast, plus a live mode that shows which app actually catches a combo when you press it.
GitHub: https://github.com/Wunderlandmed...
I’ve definitely had moments where a shortcut didn’t work and I had no idea if macOS, another app, Raycast, or some automation tool had already claimed it. Debugging that manually is not fun. I like that HotkeyClash separates real global conflicts from harmless overlaps. That detail matters, because otherwise the tool would probably just create more noise instead of actually helping.
Also really appreciate the no telemetry, no account, open-source approach here. For a menu bar utility that scans local app/system behavior, that feels like the right default.
Curious how hard it is to support tools like Raycast, Alfred, BetterTouchTool, and Keyboard Maestro. Do they expose shortcut data cleanly, or do you need custom parsers for each one?
@andrasczeizel Thanks Andras, that is exactly the experience that pushed me to build it. The "is it macOS, an app, Raycast, or some automation tool" guessing game is miserable to debug by hand.
You put your finger on the hardest design call: the conflict classification. Early on the tool flagged every overlap and the list was useless, because tons of apps reuse the same combo inside their own menus and that is completely fine. So now it separates definite conflicts (two global hotkeys claiming the same combo, a guaranteed clash) from potential ones (a global hotkey overlapping a per-app menu shortcut, which only bites when that app is focused). The goal is a list you can act on, not noise.
And yes, no telemetry, no account, open source was a deliberate default rather than a marketing line. For a utility that reads your app and system shortcut data locally, I did not want anyone to have to trust me on what it does. You can read exactly how it inspects things.
On your question: there is no clean shared API, so it is a custom parser per tool, and the difficulty varies a lot by how each one stores its data.
Running apps are the exception. Their menu shortcuts come through the macOS Accessibility API in a uniform way, so that is one code path for every app.
Everything else means reading each tool's own storage format directly:
Karabiner-Elements and skhd (already supported) are plain config files, JSON and a simple text format, so those were the easiest.
Keyboard Maestro stores macros in a plist. Readable, but the shortcut data is buried in a nested macro structure.
Alfred and Raycast keep things in plist and JSON in their app support folders, so medium effort, mostly mapping their key formats to macOS keycodes.
BetterTouchTool is the spicy one. It is a SQLite database, so it means querying the store and decoding how it represents triggers.
So no, none of them expose shortcut data cleanly in a common shape, but all of them are readable with a dedicated parser. They are on the roadmap in roughly that order of demand. Each parser is a self-contained piece, so if you happen to live in one of these tools and want to help, contributions are very welcome.
Report
Shortcut collisions across apps, Karabiner and skhd are impossible to debug by hand, so a tool that just shows the clashes is great. Open-source with no telemetry is the cherry on top. Congrats on the launch Kemal!
HotkeyClash
YourSitee
I’ve definitely had moments where a shortcut didn’t work and I had no idea if macOS, another app, Raycast, or some automation tool had already claimed it. Debugging that manually is not fun. I like that HotkeyClash separates real global conflicts from harmless overlaps. That detail matters, because otherwise the tool would probably just create more noise instead of actually helping.
Also really appreciate the no telemetry, no account, open-source approach here. For a menu bar utility that scans local app/system behavior, that feels like the right default.
Curious how hard it is to support tools like Raycast, Alfred, BetterTouchTool, and Keyboard Maestro. Do they expose shortcut data cleanly, or do you need custom parsers for each one?
HotkeyClash
@andrasczeizel Thanks Andras, that is exactly the experience that pushed me to build it. The "is it macOS, an app, Raycast, or some automation tool" guessing game is miserable to debug by hand.
You put your finger on the hardest design call: the conflict classification. Early on the tool flagged every overlap and the list was useless, because tons of apps reuse the same combo inside their own menus and that is completely fine. So now it separates definite conflicts (two global hotkeys claiming the same combo, a guaranteed clash) from potential ones (a global hotkey overlapping a per-app menu shortcut, which only bites when that app is focused). The goal is a list you can act on, not noise.
And yes, no telemetry, no account, open source was a deliberate default rather than a marketing line. For a utility that reads your app and system shortcut data locally, I did not want anyone to have to trust me on what it does. You can read exactly how it inspects things.
On your question: there is no clean shared API, so it is a custom parser per tool, and the difficulty varies a lot by how each one stores its data.
Running apps are the exception. Their menu shortcuts come through the macOS Accessibility API in a uniform way, so that is one code path for every app.
Everything else means reading each tool's own storage format directly:
Karabiner-Elements and skhd (already supported) are plain config files, JSON and a simple text format, so those were the easiest.
Keyboard Maestro stores macros in a plist. Readable, but the shortcut data is buried in a nested macro structure.
Alfred and Raycast keep things in plist and JSON in their app support folders, so medium effort, mostly mapping their key formats to macOS keycodes.
BetterTouchTool is the spicy one. It is a SQLite database, so it means querying the store and decoding how it represents triggers.
So no, none of them expose shortcut data cleanly in a common shape, but all of them are readable with a dedicated parser. They are on the roadmap in roughly that order of demand. Each parser is a self-contained piece, so if you happen to live in one of these tools and want to help, contributions are very welcome.
Shortcut collisions across apps, Karabiner and skhd are impossible to debug by hand, so a tool that just shows the clashes is great. Open-source with no telemetry is the cherry on top. Congrats on the launch Kemal!
HotkeyClash
@eitan_elnekave Hey Eitan, Thanks a lot!