KeybindingManager.SetChords can split one batch across two profiles if the active profile changes mid-call

[matt-edmondson]

What's wrong

Keybinding/KeybindingManager.cs L197-L205:

Profile activeProfile = Profiles.GetActiveProfile() ?? throw new InvalidOperationException("No active profile is set");

return OperationHelper.ExecuteWithCount(chords, Keybindings.BindChord);

activeProfile is fetched only to check that an active profile exists, and is never used afterwards. Each entry goes through the two-argument IKeybindingService.BindChord(commandId, chord), which looks up the active profile again for every entry.

Failure scenario

1. Profile a is active, and thread 1 calls SetChords with N entries.
2. Partway through, thread 2 calls SetActiveProfile("b").
3. The remaining entries are bound into b.
4. SetChords reports N bindings set. They are split across two profiles, and neither profile has the batch the caller asked for.

CLAUDE.md promises thread-safe services, and recent fixes (#142 and the lookup-overload guards) close this kind of gap elsewhere.

Suggested fix

Bind against the profile the method already resolved, using the existing three-argument overload (IKeybindingService.BindChord(string profileId, string commandId, Chord chord)):

return OperationHelper.ExecuteWithCount(chords, (commandId, chord) => Keybindings.BindChord(activeProfile.Id, commandId, chord));

Check other KeybindingManager batch helpers for the same pattern.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Low. It needs a SetActiveProfile racing a SetChords batch, which is unlikely in practice. The fix is one line using the existing three-argument BindChord overload.
• Area / suggested assignment: Keybinding/KeybindingManager.cs SetChords and any sibling batch helpers
• Related: SetActiveProfile racing DeleteProfile leaves the active id pointing at a deleted profile, so a later profile with that id becomes active on its own #120 (another SetActiveProfile race) and Lock a profile's chords so concurrent binds cannot corrupt them [minor] #142 (chord locking). The same pattern could be audited in one pass.
• Duplicates: none found
• In progress: no open PR covers this.

---

Generated by Claude Code