Windows 11’s streamlined right-click menu solved one problem and created another: it buried the commands power users actually use every day. For long-time Windows users, that means a simple workflow like opening a file in Notepad++ can now take extra clicks, extra mouse movement, and extra friction. The fix is refreshingly old-school: a single registry-based shell verb that puts your favorite app back at the top level of File Explorer’s context menu.
What makes this tweak so satisfying is not just that it works, but that it restores a kind of
agency Windows has slowly been taking away from advanced users. Instead of depending on whatever an installer decided to register, you can define your own permanent right-click entry for any executable. It is a small change with an outsized effect on daily productivity, and it exposes a bigger truth about Windows 11’s design philosophy: cleaner interfaces often come with hidden costs for people who live in the operating system all day.
Background
Windows context menus have always been a battleground between simplicity and control. On one side, Microsoft wants a cleaner, more predictable shell experience that avoids clutter and badging every file type with a wall of actions. On the other side, long-time users want direct access to the tools they trust, especially for tasks they repeat dozens of times a day.
That tension sharpened in Windows 11, where Microsoft redesigned File Explorer’s context menu and pushed many legacy entries behind
“Show more options.” The change looks tidy at first glance, but it adds friction to the exact use cases that matter most to power users. The result is a UI that is arguably
more elegant but often
less efficient.
The registry tweak described here is not a hack in the fragile sense. It is a return to a documented Windows shell mechanism that has existed for years, and Microsoft’s own documentation explains that verbs can be added under registry locations such as
HKEY_CLASSES_ROOT to extend shortcut menus. In other words, this is not a workaround for a broken system so much as a user-controlled layer sitting directly on top of the shell.
The specific trick uses the wildcard *
HKEY_CLASSES_ROOT\shell*
path, which applies to all files rather than a single extension. That distinction matters because it lets you create a universal action like “Edit with Notepad++” without changing file associations, defaults, or the behavior of double-clicking. Microsoft’s shell documentation also notes that verbs can be positioned at the top or bottom of a menu and can be extended through registry-defined commands.
This is why the method feels so elegant: it bypasses the most annoying part of modern Windows without disturbing the rest of the system. You are not reassigning ownership of .txt files, not hijacking “Open,” and not relying on the app to keep its own shell extension alive. You are simply telling Explorer, when I right-click any file, offer this command immediately*.
Why Windows 11 Made This Feel Harder
The most immediate reason this tweak matters is that Windows 11’s context menu design inserts a delay into a task that should be instantaneous. For a one-off user, a second click is no big deal. For a developer, sysadmin, writer, or analyst who constantly opens files in a preferred editor, those extra clicks compound into real time lost.
Microsoft’s newer menu is designed around visual restraint and consistency, but it also assumes that the most commonly used commands can be surfaced automatically. That assumption does not hold for every workflow. A file editor like Notepad++ may be the most important action in someone’s daily routine, yet Windows 11 treats it like a legacy add-on instead of a first-class command.
A cleaner menu is not always a faster menu
A
cleaner interface is not automatically a better interface. The narrower the visible menu, the more the operating system relies on hidden layers, flyouts, and secondary menus to preserve access to functionality. That approach can improve aesthetics, but it often harms discoverability for advanced tasks.
This is especially noticeable with context menus because their value lies in immediate recognition. If a command is not visible in the first menu, users often stop thinking of it as part of their working surface. Once that happens, productivity erodes not because the tool disappeared, but because the system made it feel optional.
- Windows 11 prioritizes visual simplicity.
- Power users prioritize speed and direct access.
- Hidden menu layers increase friction.
- Repeated actions become noticeably slower.
The contrast with macOS is instructive. On Apple’s platform, the right-click and “Open With” experience tends to surface supported apps more naturally because the OS leans on app metadata and declared file support. Windows does have “Open With,” but it has always been more dependent on installer behavior and registry registration, which makes it feel less automatic and
more contingent on how software vendors package their apps.
The Notepad++ case is just the tip of the iceberg
Notepad++ is a perfect example because it is popular, portable, and frequently used as a secondary editor rather than the system default. Many users want it one click away without making it the default editor for every text file. That makes it an ideal candidate for a custom shell verb.
The deeper lesson is that the same pain point affects
VS Code, portable utilities, scripting tools, and niche apps that do not always register themselves as deeply as traditional desktop software. The tweak is useful not because Notepad++ is special, but because its workflow pattern is common: a preferred app that should be
available instantly without becoming the default.
How the Registry Verb Actually Works
The mechanism behind the tweak is simpler than it sounds. Windows shell verbs are registry entries that define commands shown in context menus. When you place a verb under *
HKEY_CLASSES_ROOT\shell
, you are telling Explorer to show that command for all file types.
The basic structure is straightforward: create a key for the menu label, add a command
subkey, and set the default value of that subkey to the executable path followed by "%1"**. That placeholder is replaced by the selected file’s path when the command runs. Microsoft’s shell docs show the same general pattern for verbs, including command strings that pass the selected file into the app.
Static verbs are simple, stable, and user-controlled
This approach is often better than relying on a shell extension DLL. A static verb is just registry data and a command string, which makes it easier to understand, easier to back up, and easier to remove. It also avoids some of the complexity that comes with COM-based context menu handlers or vendor-specific shell integration.
That simplicity has another advantage: it is
less fragile across app updates. If an installer or updater does not rewrite the relevant registry key, your custom entry remains intact. That is an important point for portable apps and tools that are frequently reinstalled or run from nonstandard paths.
You can also adjust a few details to refine the experience. Microsoft documents a
Position value that can place verbs at the top or bottom of the menu, and an
Extended value that hides a verb unless the user holds Shift while right-clicking. That means you can keep the menu decluttered while still preserving a power-user action when you need it.
- Label key: controls what the menu says.
- command subkey: controls what launches.
- "%1": passes the selected file path.
- Position: controls menu placement.
- Extended: makes the entry Shift-only.
Why wildcarding every file matters
The wildcard asterisk in **HKEY_CLASSES_ROOT*** is the key to making this trick broadly useful. Instead of binding the action to one file extension, you are binding it to the generic file object. That means the entry appears regardless of whether you clicked a .txt file, .log file, .json file, or something else entirely.
That is also why the method is more flexible than “Open With” or “Choose another app.” Those features are tied to file associations and user choices; this registry verb is a direct shell action. It does not ask Windows what should happen. It tells Windows what should happen.
Why This Beats “Open With”
“Open With” seems like the obvious answer, but it is really designed for a different job. It is useful when you want to open a file
once with a different app or when you want to change the default application. It is much less useful when you want a permanent, visible shortcut to your preferred tool without changing defaults.
That distinction matters a lot for people who use several editors or utilities interchangeably. You might want Notepad++ for quick edits, VS Code for heavier work, and the default Notepad app for simple checks. The shell verb model supports that reality far better than one default file association ever could.
Portable apps make the limitation worse
Portable apps often do not self-register with Windows the same way traditional installers do. As a result, they may not appear in the obvious places when you right-click a file. The app may be perfectly capable of opening the file, but Explorer does not know enough to make it a first-class option.
That is where a manual shell verb shines. It gives you a stable menu item even if the app lives in a zipped folder, a USB drive, a synced folder, or a custom location outside
Program Files. It is a small but important advantage for users who value flexibility over rigid installation patterns.
A second issue is that Windows 11 visually demotes legacy options. Even when the app is present, it may sit behind
“Show more options”, which means the menu path is no longer ergonomic. That extra friction is often enough to make users abandon the action altogether, especially when speed is the reason they wanted the app in the menu in the first place.
- Open With is good for one-time choices.
- Shell verbs are better for permanent workflow shortcuts.
- Portable apps benefit the most.
- Windows 11’s hidden menu adds friction to discovery.
Default behavior and custom behavior are not the same thing
A subtle but important advantage of this tweak is that it does not change the system default. That means your file associations remain untouched, which is exactly what many advanced users want. You can keep Notepad++ as an always-available companion tool without making it the universal handler for text files.
This separation of concerns is one reason the registry method feels more
professional than casual users might expect. It keeps behavior layered: defaults stay defaults, and custom actions remain explicit. In practical terms, that makes the system easier to reason about and less likely to surprise you later.
Notepad++ as the Perfect Example
Notepad++ has long occupied a sweet spot in the Windows ecosystem. It is lightweight, fast, and familiar, but it is not the default editor for everyone. It is one of those apps that many users install specifically because they want a superior alternative available
on demand.
That makes it ideal for a custom right-click entry. You do not need it to take over every text file. You just want it one click away when you spot a configuration file, a log, or a script that needs a quick edit.
Why the app feels more useful when it is one click away
The difference between a tool being installed and a tool being
reachable is huge. A menu item in the top-level context menu changes the perceived cost of using the app. If a command is visible instantly, users are much more likely to invoke it.
This is especially true in troubleshooting and development scenarios. A person who is working through logs, markup, or code snippets may open and close files dozens of times in a short session. Saving even a single click per file opens up a real productivity gain over time.
There is also a psychological effect here. When the command is present in the first menu, the app feels integrated into the operating system rather than appended onto it. That integration creates confidence, and confidence leads to repetition. Repetition is what turns a convenience into a habit.
- Notepad++ is popular but not always the default.
- The app is ideal for selective, frequent use.
- A visible verb lowers the friction threshold.
- The workflow benefit accumulates over time.
Updates, shell integration, and maintenance
One concern that often comes up is whether an app update might interfere with a manually created verb. In practice, this is possible but usually not catastrophic. If a future Notepad++ installer reinstalls its own shell integration, it could potentially conflict with your custom entry, but that is more of a maintenance consideration than a reason to avoid the tweak entirely.
This is where backing up the registry key matters. If you export *
HKEY_CLASSES_ROOT\shell** before editing it, you can restore the state quickly if anything goes sideways. That backup step turns the whole procedure from a risky modification into a reversible customization.
Safety, Backup, and Reversibility
Any registry change deserves caution, even when the change is simple. The good news is that this one is easy to reason about and even easier to roll back. Microsoft’s shell model is built around explicit keys and values, which means there is no mystery about what the system will do once the command is added.
The safest habit is to export the relevant registry branch before making changes. If you only plan to touch *
HKEY_CLASSES_ROOT\shell**, back up that key first and store the .reg file somewhere obvious. That way, if you mistype the path or decide you dislike the menu entry later, restoration is trivial.
The right backup habit is a small investment
A lot of users skip backup because the tweak looks simple. That is understandable, but it is exactly the kind of tweak that deserves a few extra seconds of caution. Even a harmless-looking registry mistake can create confusion, and confusion is what turns a two-minute fix into an hour of troubleshooting.
Because this is a
static verb rather than an injected shell extension, the recovery path is straightforward. You can remove the menu entry by deleting the key or importing your backup file. That is one reason this is a much more comfortable registry edit than older, more invasive shell customization methods.
A practical workflow looks like this:
- Export the target registry key.
- Add the custom verb.
- Test the menu entry on a sample file.
- Restart Explorer only if the entry does not appear.
- Restore the export if anything behaves unexpectedly.
That sequence is simple, repeatable, and easy to document for yourself or for a team. It also gives you a clean rollback plan, which is essential whenever you are editing system behavior.
Why this is safer than changing defaults
Changing the default program for a file type is a heavier-handed action. It affects every double-click and every file association decision the system makes afterward. By contrast, a custom context-menu verb is narrow and explicit, which makes it much easier to predict.
That narrow scope is what makes the tweak feel
responsible as well as useful. You are not forcing the operating system to re-evaluate file ownership. You are adding a shortcut to a tool you already trust.
Enterprise, Power User, and Casual User Impact
The value of this registry trick is not evenly distributed across all user types. For casual users, it may be a neat convenience but not a necessity. For power users, developers, and enterprise support staff, it can become a serious time saver because the same workflow is repeated across dozens or hundreds of files.
In managed environments, the ability to expose a standardized custom action can be very attractive. IT teams often want a stable, obvious way to launch an approved editor or utility without changing user defaults. The shell verb model can help with that, though deployment policy and registry permissions still need to be handled carefully.
Power users get the biggest return
Power users tend to be the ones who notice menu friction first. They also tend to be the ones who most appreciate a solution that is low-maintenance after setup. Once the verb is in place, it keeps paying dividends every time a file needs a quick edit.
For developers, the benefit is even clearer. Editing logs, JSON, INI files, batch scripts, and config files is part of the daily rhythm of troubleshooting. A visible
Edit with Notepad++ command becomes muscle memory, and muscle memory is what saves time under pressure.
For enterprise users, the benefit depends on policy. Some environments lock down registry edits, and some standardize on specific app deployment methods. But where allowed, a centrally defined shell verb can improve workflow consistency without requiring a full change to file associations.
Consumers see the problem as annoyance, not architecture
Consumers may not think in terms of shell verbs or registry hives. They just know that Windows 11 made a previously obvious action feel buried. The registry fix works because it restores the old relationship between intention and action: right-click, see command, click once, done.
That is why this tweak has such broad appeal. It answers a very human complaint with a very Windows solution. The system becomes less abstract and more direct.
- Power users want speed.
- Developers want repetition without friction.
- IT teams want controlled consistency.
- Casual users want obvious actions.
The broader competitive angle
This also highlights a competitive difference between Windows and other desktop platforms. On macOS, contextual app availability tends to feel more integrated. On Windows, app integration is often more dependent on installers, shell registration, and user-managed customization. That gives Windows more flexibility overall, but it also makes the experience feel more fragmented.
For Microsoft, that fragmentation is both a strength and a weakness. It enables deep customization, but it also means users often have to do some of the integration work themselves. The registry tweak is a perfect example of that tradeoff in action.
Strengths and Opportunities
The appeal of this tweak is not just that it fixes an annoyance. It also shows how much practical value there is in preserving user-controlled shell behavior, especially when modern UI changes make common tasks less direct. In a sense, this tiny registry entry restores the idea that Windows should adapt to the user’s workflow, not the other way around.
- Immediate access to a preferred app from any file.
- No default association changes required.
- Works with portable apps that do not self-register well.
- Simple to back up and restore.
- Low cognitive overhead once configured.
- Can be extended to multiple apps and workflows.
- Supports decluttering via the Extended registry value.
Risks and Concerns
The method is clean, but it is not completely free of tradeoffs. Any registry edit can be misapplied, and a poorly typed command path can lead to confusing failures or a nonfunctional menu item. There is also the broader concern that Microsoft’s shell UI may continue evolving in ways that make legacy customizations feel increasingly out of step with the rest of the system.
- Registry mistakes can create avoidable troubleshooting.
- Paths with spaces must be quoted correctly.
- App updates could occasionally interfere.
- Enterprise lockdowns may restrict registry access.
- Security policies may treat custom verbs cautiously.
- Menu clutter can return if too many verbs are added.
- Windows UI changes may further hide legacy behaviors.
Looking Ahead
The best thing about this registry trick is that it is both old and still relevant. Windows has moved on in appearance, but the shell still runs on many of the same underlying ideas that have guided it for years. That means users who understand those mechanics can still shape the system to their own needs, even when the UI tries to keep the surface cleaner and simpler.
What Microsoft does next matters here. If the company wants Windows 11 to feel truly modern, it needs to preserve the speed and flexibility power users expect without forcing them into the registry for basic productivity workflows. A built-in way to pin preferred apps to the top-level context menu would be a small but meaningful quality-of-life improvement.
- A built-in UI for custom verbs would reduce friction.
- Better per-user app registration could improve reliability.
- More visible context-menu customization would help power users.
- Shell behavior documentation should be easier to discover.
- Portable-app support deserves better first-class treatment.
The deeper lesson is that productivity gains do not always come from flashy features or AI integrations. Sometimes the biggest improvement is simply putting the right command back where your hand expects it to be. When a two-minute registry change reliably saves time every day, it is hard to argue with the result.
Windows 11 may have hidden the old shortcut, but it did not eliminate the underlying mechanism. That is the real story here: the operating system still contains the tools for a fast, customizable workflow, and the users who know where to look can still take back control.
Source: MakeUseOf
This simple registry tweak gave me the best productivity boost on Windows