You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A "default" profile the user deleted comes back for good when CreateDefaultProfile() runs before InitializeAsync() (#189 returns on the #206 path) #248
CreateDefaultProfile (Keybinding/KeybindingManager.cs:269-299) promises that "a startup call therefore does not bring back a default profile the user deleted after making another". It decides that from Profiles.GetAllProfiles() at :280, which only looks at memory. Before InitializeAsync() memory is empty, so it creates "default". Init then loads the user's other profiles next to it, and SaveAsync writes "default" back to disk.
#206 made calling CreateDefaultProfile() (or sharing a profile manager through DI) before init a supported path. #189's fix only covers init-first.
using(KeybindingManagerm=new(dir)){awaitm.InitializeAsync();m.CreateDefaultProfile();m.Profiles.CreateProfile("vim","Vim");m.Profiles.SetActiveProfile("vim");m.Profiles.DeleteProfile("default");awaitm.SaveAsync();}using(KeybindingManagerm=new(dir)){Profile?created=m.CreateDefaultProfile();// before initawaitm.InitializeAsync();// created = default, profiles = default,vimawaitm.SaveAsync();}using(KeybindingManagerm=new(dir)){awaitm.InitializeAsync();// profiles = default,vim (expected: vim)}
Why it matters
A user who deleted the default profile gets it back on the next launch, and the save makes that permanent. This is #189's symptom again for any app that seeds its default before loading.
Suggested fix
Do one of these:
Have KeybindingManager track whether InitializeAsync has run. Before it has, have CreateDefaultProfile either throw InvalidOperationException or defer the decision until the stored profiles are loaded.
In InitializeAsync, drop an untouched placeholder "default" (created by CreateDefaultProfile, never bound and never persisted) when the stored data has other profiles but no "default".
Acceptance criteria
A test with the sequence above ends with only vim stored, and CreateDefaultProfile either returns null, throws a clear error, or has its placeholder discarded by init.
Activity
matt-edmondson commentedon Nov 12, 2026
Triage
KeybindingManager.CreateDefaultProfile/InitializeAsyncordering (follow-up to Calling CreateDefaultProfile() at startup, as documented, recreates a deleted "default" profile and makes it the active profile on every launch #189 and Creating a profile before InitializeAsync() silently discards the stored profile with that id, and the next SaveAsync overwrites the user's bindings on disk #206)InitializeAsynckeeps the Creating a profile before InitializeAsync() silently discards the stored profile with that id, and the next SaveAsync overwrites the user's bindings on disk #206 call order working. Throwing before init would break callers that Creating a profile before InitializeAsync() silently discards the stored profile with that id, and the next SaveAsync overwrites the user's bindings on disk #206 now treats as supported.Generated by Claude Code