Hotkey HQ
Who is eating this key?
The problem
When a Windows shortcut stopped working, the binding could belong to the OS, Claude Code, VS Code, PowerToys, Terminal or the focused app, and answering “who is eating this key?” meant searching several settings files. Global hooks made the result less obvious because PowerToys or NVIDIA could win before the focused app saw the key.
What it does
Every keyboard shortcut competing for a key on a Windows machine — Claude Code, VS Code, Windows itself, PowerToys, Windows Terminal and your own bindings — on a single keyboard you can press keys against.
It answers the question you actually have when a shortcut misbehaves, rather than making you grep six settings files. Runs as its own desktop window off one dependency.
Why it is built this way
I read the running user's configuration live and put every claimant on one pressable keyboard, with defaults explicitly versioned when they have to be hand-maintained. The app stays local and refuses cross-origin requests with a per-run token; it also refuses the tempting low-level global hook because capturing every keystroke like a keylogger is not a reasonable trade for a reference tool.
What was hard
PowerToys stores vendor defaults and user overrides under labels that collapse to the same name, so the resolver had to keep separate maps, write the override slot and restart PowerToys before the old binding actually stopped firing. Obsidian created the opposite problem: it persists only overrides, so a complete layer had to combine a defaults table with live vault settings.
Outcomes
- One keyboard, every source
- Press-to-identify
- Open source