ST’s installer registers the application to be available in “Open with…” context menue via:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\sublime_text.exe]
and sets up some file types it claims to support via:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\sublime_text.exe\SupportedTypes]
Beyond that it registers an “Open with Sublime Text…” context menu item via
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\sublime_text]
@="Open with Sublime Text"
"Icon"="\"C:\\Program Files\\Sublime Text\\sublime_text.exe\",0"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\sublime_text\command]
@="\"C:\\Program Files\\Sublime Text\\sublime_text.exe\" \"%1\""
None of those registry keys would hijack all file types or mess things up that badly.
TBH, I’d hesitate to use those legacy WinXP apps like FileTypesMan. I haven’t followed their development, but the way Windows 10/11 handle file type associations has slightly changed - adding another layer to dynamically handle active associations beyond what’s pre-configured in HKEY_CLASSES_ROOT
aka. HKEY_LOCAL_MACHINE\SOFTWARE\Classes
. Hence I wouldn’t be surprised such tools to mess things up.
Nevertheless everything looks fine here:
If really everything is assigned to Sublime Text, I’d start looking for HKEY_CLASSES_ROOT\*
key in registry.
If it’s (Default)
value is non-empty, that’s likely the root cause as it assigns any file extension to specified application.
Also check if it contains a sub-key like \shell\open\command
to Sublime Text. Remove open
key. It shouldn’t exist in *
.
Don’t mess with file associations under SOFTWARE\Explorer by any means. Those are managed by Windows.