The important distinction is between what Microsoft has formally announced, what has already shipped for app developers, and what independent reports observe in Insider builds. Those are related developments, but they do not prove that every older custom command will receive the same treatment as a modern app extension.
The redesign is now a File Explorer feature, not just a design idea
Microsoft has announced that a redesigned File Explorer context menu is rolling out to Windows Insiders. Its stated goals are familiar to anyone who has used Windows 11: make the menu faster and simpler, reduce visual clutter, and avoid presenting a long undifferentiated stack of commands whenever a file or folder is right-clicked.
The crucial new element is customization. Microsoft says users will be able to control which app extensions appear in the main context menu and which are placed in a submenu. The submenu itself can also be hidden. The redesigned menu also includes controls for built-in commands.
That is a material shift from the blunt choice often associated with Windows 11’s earlier context-menu design: accept Microsoft’s streamlined first menu, or use Show more options to reach commands that did not fit the new model. If a commonly used application integration is recognized by the new settings interface, a user should be able to keep it prominent rather than treating it as overflow by default.
For ordinary PC users, that could make the right-click menu more practical. A person who frequently sends files to a particular app, shares through a preferred service, or invokes a regular compression tool may be able to surface that extension without restoring every rarely used command. Conversely, someone who wants an especially spare menu can move extensions into the submenu—or remove that submenu from view.
That flexibility is promising, but it has boundaries that matter.
The registry-command problem remains the central concern
Independent reports on the Insider implementation say that legacy commands added through the Windows Registry are still being placed under Show more options. Microsoft’s existing support guidance is consistent with the general principle: extensions that are not available in the streamlined menu remain accessible through that legacy entry.
This is not a trivial edge case for all Windows users. Registry-based context-menu commands have long been a straightforward way for power users, administrators, script authors, and smaller utilities to add actions to File Explorer. Examples can include launching a script against a selected item, opening a file in a specialist editor, invoking a command-line tool, running a bespoke backup routine, or using an in-house line-of-business utility.
For these users, the concern is not merely that an action takes one more click. Context menus are valuable because they make a command available precisely where the object is selected. Moving a frequently used command into a secondary legacy menu breaks that directness and makes carefully tailored workflows feel less native.
Still, it is important not to overstate what has been established. Microsoft’s announcement explicitly describes configuration for app extensions, including their placement in the main menu or a submenu. It does not explicitly say whether every manually created Registry verb is classified as an app extension for those settings. Nor does it say that users can promote each legacy Registry command into the main redesigned menu.
That leaves two possibilities:
- The current Insider behavior may reflect a deliberate compatibility boundary, where older Registry integrations remain usable but are kept in the legacy overflow.
- Or Microsoft could broaden the settings model, alter the behavior of particular classes of commands, or otherwise refine the implementation before general release.
The available evidence supports the first behavior as an observed early-build issue, not as an immutable final policy. Users should therefore avoid assuming that the promised customization automatically applies to every command they have added themselves.
Why app extensions and custom verbs may be treated differently
Microsoft’s approach makes sense from a platform-maintenance perspective, even if it frustrates advanced users. Context menus historically became crowded because many applications registered entries independently. A clean, reliable menu needs rules about grouping, labels, icons, relevance, and whether a command belongs on a file, folder, drive, desktop background, or multiple item selection.
Modern extension mechanisms give Windows and application developers more structured information with which to make those decisions. A hand-authored Registry command, by contrast, may be perfectly useful but may not expose the same level of metadata or follow the newer extension model.
That does not mean legacy commands are inherently unsafe or unworthy of first-class placement. Many are created by skilled users for highly specific needs. But it helps explain why Microsoft may be reluctant to let every registered verb appear automatically in the compact menu. Doing so could recreate the sprawl that the redesign is intended to solve.
The policy question is whether the system should optimize only for a tidy default or also provide a credible power-user path. Keeping legacy commands available under Show more options preserves compatibility. Giving users a supported way to selectively pin trusted, frequently used legacy commands would better preserve agency. The material currently available does not establish that such a pinning mechanism exists.
Split menus have already moved from proposal to stable API
Part of the confusion around this story comes from the fact that a related developer technology has moved quickly.
Microsoft publicly demonstrated a proposed WinUI pattern often described as a split context menu in November 2025. Its core behavior is simple: one control has a primary button for the default action and a separate flyout button for additional actions. In Microsoft’s terminology, the shipped WinUI control is SplitMenuFlyoutItem.
This is intended to let developers offer a useful default without listing every variation at the top level. A compression app, for example, might make its most common operation immediately reachable while putting alternative formats or less common choices behind the flyout portion of the control. Done well, that reduces menu length without concealing the full feature set.
Crucially, this is no longer merely an API proposal. SplitMenuFlyoutItem shipped in the stable Windows App SDK 1.8.6 release on March 18, 2026. Developers using the relevant Windows App SDK tooling can therefore build around a stable control rather than waiting for Microsoft to create it.
That fact should not be mistaken for proof that every Windows desktop context menu, especially File Explorer’s shell menu, will automatically adopt the pattern. A WinUI control is a building block available to app developers. The File Explorer redesign is a separate shell-level product decision with its own compatibility and settings behavior. The two developments share the aim of concentrating common actions and nesting alternatives, but they should be assessed independently.
A shorter menu can still produce interaction mistakes
The split-control approach also has genuine design costs. In the public review of the API, contributors questioned whether a primary label can accurately represent a flyout containing several different actions. The concern is sound: if the main part says something specific, users can reasonably expect the arrow portion to offer closely related variations rather than a mix of substantially different operations.
One disputed compression example was later removed after Microsoft’s author agreed that it was not suitable. That exchange does not invalidate the control. It shows why the feature needs careful application.
A split menu works best when all of its choices belong to a clearly understood family and the default action is genuinely safe and common. It works less well when the parent label overpromises, the flyout contains heterogeneous tasks, or users cannot predict whether they should click the text area or the arrow. In those cases, compactness can become ambiguity.
Accessibility and discoverability also deserve attention. A split affordance introduces two adjacent targets with different consequences. Keyboard navigation, screen-reader announcements, focus behavior, visible labeling, and touch-friendly target sizes need to make that distinction clear. The dossier does not provide final accessibility findings for the File Explorer implementation, so it would be premature to declare the design accessible or inaccessible. It does establish that the conceptual questions were raised during review.
What Windows users should do now
Because the new File Explorer menu is rolling out to Insiders, its behavior and final configuration remain subject to change. The practical approach differs by user type.
Everyday users
If the redesigned menu reaches your Insider build, start with the new Context Menu settings rather than immediately turning features off. Put the few app actions you genuinely use in the main menu, move occasional actions to the submenu, and consider hiding the submenu only if it does not contain anything you need.
The goal should not be the smallest possible menu. It should be the shortest menu that still exposes your regular work without forcing repeated detours.
Power users and IT administrators
Inventory the commands your workflows actually depend on, especially those installed by scripts, management tools, portable utilities, or custom Registry changes. Test them from the exact File Explorer locations where they matter: files, folders, drives, the desktop, and multi-selection views can each behave differently.
If a required command appears only under Show more options, treat that as a usability regression even if it remains technically functional. Document the impact before changing internal guidance or deployment scripts. Where the command comes from a commercial or managed application, check whether its vendor offers a current extension model or update that works with the redesigned menu.
For home users who manually edit the Registry, the safest stance is restraint. Do not remove existing commands merely because they are not visible in the new top-level menu; the available reporting indicates that they remain reachable through the legacy path. But do not assume an unsupported Registry tweak can safely force those commands into the redesigned interface. The available material provides no basis for recommending such modifications.
Developers
For new Windows applications, the stable SplitMenuFlyoutItem API offers a way to provide a default command and related alternatives without multiplying top-level entries. Use it only when the relationship is obvious. A clear primary action, a coherent set of alternatives, and predictable labeling matter more than fitting more capabilities into a smaller visual space.
Developers maintaining older shell integrations should also view the File Explorer changes as a compatibility signal. A legacy command may continue to work while becoming harder for users to find. That is not the same as removal, but it can still reduce real-world feature usage.
The 26H2 timing should not be treated as settled
The redesigned context-menu work is relevant to Windows 11 version 26H2, but a precise public-release month is not established by the available information. Microsoft has described general availability as planned later in 2026, without confirming an October launch.
That distinction matters for organizations planning upgrades and for enthusiasts deciding whether to wait. Insider availability is not a guarantee that a feature’s behavior, settings, or rollout scope will be identical in the eventual broadly available release. The treatment of legacy custom commands is exactly the sort of detail that can change during that interval.
A better menu needs both order and user control
Microsoft’s redesign addresses a real Windows problem: right-click menus can become slow, crowded, and incoherent when every installed application demands equal prominence. The ability to choose which supported app extensions sit in the main menu, move others into a submenu, or hide the submenu altogether is a stronger answer than a one-size-fits-all streamlined menu.
But the criticism over Registry-created commands identifies the test Microsoft has not yet conclusively passed. Compatibility alone is not enough when a command is central to a user’s work. If the new customization settings apply only to modern extensions while trusted legacy verbs remain permanently behind Show more options, the tidy default will come at a disproportionate cost to some of Windows’ most capable users.
For now, the evidence supports cautious optimism about the configurable redesign and justified skepticism about its legacy-command story. The right outcome is not a return to an unfiltered menu. It is a system that stays clean by default while giving users a supported, understandable way to decide which of their own essential tools deserve to be one click away.