ExecuteChord returns null when the first binding for a chord belongs to an unregistered command, even if a registered command shares the chord

[matt-edmondson]

What's wrong

KeybindingService.ExecuteChord (Keybinding/Services/KeybindingService.cs, ~line 227) resolves the chord with FindCommandByChord (~line 280), which takes FirstOrDefault over the active profile's bindings. Only after picking that single match does it check whether the command is registered. Two things make that first match stale:

• BindChord does no conflict check, so two commands can share a chord.
• CommandRegistry.UnregisterCommand leaves the command's bindings in profiles.

Repro

registry.RegisterCommand(a); registry.RegisterCommand(b);
service.BindChord("a", Chord.Parse("Ctrl+S"));   // true
service.BindChord("b", Chord.Parse("Ctrl+S"));   // true
service.FindCommandByChord(Chord.Parse("Ctrl+S")); // "a"

registry.UnregisterCommand("a");
service.ExecuteChord(Chord.Parse("Ctrl+S"));      // null
service.FindCommandByChord(Chord.Parse("Ctrl+S")); // still "a"

Expected: ExecuteChord runs b, the only registered command bound to the chord.

Reproduced against the current main build.

Why it matters

Apps that unregister commands (plugins unloading, context-specific commands) end up with shortcuts that silently do nothing, even though another live command is bound to the same keys. There is no error or log to explain why the key stopped working.

Suggested fix

• In ExecuteChord, filter matching bindings by IsCommandRegistered before choosing one.
• Separately, and optionally: remove a command's bindings when it is unregistered, and/or report conflicts from BindChord (reject, or expose a GetConflicts API).

Acceptance criteria

• The repro executes b.
• A regression test covering an unregistered command sharing a chord with a registered one.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Medium. A shortcut silently does nothing even though a live command is bound to it. That needs two things to line up: a chord shared by two commands, and one of them unregistered (plugin unload, context-specific commands). Nothing crashes and no data is lost, but it is confusing and gives no diagnostics.
• Area / suggested assignee: KeybindingService.ExecuteChord / FindCommandByChord, and, if the optional parts are taken on, CommandRegistry.UnregisterCommand and BindChord conflict handling. Maintainer: @matt-edmondson.
• Duplicates / in progress: No duplicate, and no open PR in this repo. It sits next to KeybindingService.ParseChord skips modifier-alias normalization: "Control+S" displays as Ctrl+S but never matches Ctrl+S #107 (chord normalization in ParseChord) and Concurrent BindChord calls corrupt a profile's bindings, despite the "thread-safe services" guarantee #109 (concurrent BindChord), which are other chord-lookup and binding bugs, but it has a different root cause.
• Next steps: Minimal fix: in ExecuteChord, filter candidate bindings by IsCommandRegistered before choosing one. Separately, decide whether unregistering a command should drop its bindings, and whether BindChord should reject or report conflicts. That is an API decision, so it is better tracked on its own. Add a regression test with an unregistered command and a registered command sharing a chord.

---

Generated by Claude Code