EverythingCommandPalette and putting Everything search inside the PowerToys palette

A thin extension whose whole job is a search path

EverythingCommandPalette, abbreviated ECP, is an extension for PowerToys Command Palette, the launcher that Microsoft ships as part of PowerToys. The extension adds the ability to search the computer for files and folders using Everything inside CmdPal.

That is the entire feature in one sentence, and it is worth being precise about what it means. ECP is not a launcher, not a file manager and not a search engine of its own. It is a provider inside a launcher that already exists, and the search it exposes comes from Everything, the separate tool that maintains its own index of the file system. ECP is the piece that connects one to the other.

The language is C#, and the project is a .NET solution. The repository layout shows a fairly conventional structure: `EverythingCmdPal.sln` at the root, a `Directory.Build.props` and a `Directory.Packages.props` for shared build and package version settings, a `nuget.config` for the feed configuration, and two source directories, `EverythingCmdPal/` for the extension itself and `Helper/` for supporting code. A `Directory.Packages.props` with central package management is a modern choice, and the `nuget.config` sitting in the root means the restore behaviour is pinned for whoever builds it rather than inherited from a machine level default.

The audience is narrow and obvious: Windows users on PowerToys who also run Everything, and who want file search in the same keystroke-driven interface as everything else they launch.

Five install channels for the same extension

The installation section lists five methods and asks you to choose one. They are, in the order given: the MS Store, Chocolatey, Scoop, WinGet, and an App Package in MSIX form.

The badges at the top of the project confirm that three of those channels are actively maintained by someone. There is a Chocolatey package named `everythingcmdpal`, a Scoop package named `everything-cmdpal` in the extras bucket, and a WinGet package published as `lin-ycv.EverythingCmdPal` under the winget-pkgs manifests.

That list is the practical answer to a question every Windows tool has to answer: how does this thing get onto a managed machine. A home user can pick whichever package manager they already use, and the WinGet route is the one most likely to fit a script-driven fleet. A corporate environment that blocks the Microsoft Store is served by Chocolatey, Scoop or WinGet. The MSIX App Package is the option for someone who wants the payload without a store account, and it is also the form that behaves most predictably on a locked-down machine.

The important caveat is that the project does not put the install commands in the repository. The documentation says detailed explanations and instructions are on the wiki page, so the repository is a pointer to the install procedure rather than the procedure itself. If you are writing an unattended deployment, you will need the wiki or the package manifest to get the exact command and any configuration the extension expects.

A second pointer works the same way for behaviour. The plugin features and settings are explained on a features page in the wiki, which means the settings surface of the extension is documented outside the code.

The version numbers are not SemVer, and that matters for packaging

The three most recent releases are v0.5.25082.0 from 2025-11-13, v0.9.2.0 from 2026-05-03, and v0.9.26030.0 from 2026-07-10.

Look closely at the structure and it does not follow the usual three-part semantic version convention. The first number stays below one, so the plugin is pre-1.0 by its own numbering. The middle segment changes in a way that is not a simple counter: 25082 to 9 to 26030. That pattern, a four digit block that advances with the calendar, is what a build-stamped or date-derived version looks like, and it is a plausible reading rather than a documented one, since the repository does not explain the scheme.

What is certain is the practical effect. A version string like 26030 cannot be compared by a human the way 0.9.3 can, and it is not ordered by semantic versioning rules. Any tooling that sorts or compares these versions, including a package feed that expects monotonic SemVer, will behave in ways you would need to verify rather than assume. The gap between 25082 and 9 also tells you the middle component is not a patch counter.

The second observation is about release cadence. There is roughly a five month gap between the 2025-11-13 release and the 2026-05-03 one, then about two months to the 2026-07-10 release, and the last push to the branch was on 2026-09-09. The repository is not archived, and there is work in it after the newest tag, so the published version and the tip of the branch are not the same thing. For a plugin distributed through three package managers plus a store listing, that means the channel versions can drift, and the safest habit is to pin one channel rather than mix them.

The repository documents support channels, not the plugin itself

The support section is short and points in three directions. Bugs go to GitHub Issues. If you are comfortable with the code, you can fix a bug yourself and open a Pull Request with the fix. Anything else, including questions that are not bugs, goes to GitHub Discussions.

That three-way split is a reasonable convention, and the invitation to send a pull request says something about how the project expects to receive fixes.

What is missing from the repository is the substance. There is no architecture description, no mention of how the extension talks to Everything, no note about which Everything versions are supported, and no description of the settings that the features page covers. The only in-repository description of behaviour is the single sentence about searching for files and folders.

There is also a small documentation inconsistency worth noting. The contribution section sends you to a developer page, and the link points at the wiki of a differently named repository, `lin-ycv/CommandPalette`, rather than the wiki of `lin-ycv/EverythingCommandPalette` that the rest of the project uses. It may be an intentional shared wiki, or it may be a stale link. Either way, a contributor following the pointer should expect to look around.

The practical upshot for an adopter is that the repository is a distribution and support surface, and the wiki is where the real documentation lives. That is a legitimate structure for a plugin, but it means your evaluation depends on a wiki page rather than on what you can read in the tree.

Where this is the wrong tool

There are three situations where adding ECP is the wrong move, and they are easy to identify.

The first is a machine without Everything. ECP delegates its file search to Everything, so on a machine where Everything is not installed and running, the file and folder search path has nothing behind it. The extension may still appear in the palette, but the part it exists for will not work. Installing ECP is not a substitute for installing Everything, and the repository does not describe bundling it or a fallback path.

The second is a workflow that needs more than finding a file. ECP exposes search. Opening a folder tree, browsing, previewing, bulk operations and anything that depends on a file manager's concept of a working directory are outside what the extension claims to do.

The third is a non-Windows machine. The extension is a PowerToys Command Palette extension, the package channels are Windows channels including the MS Store and WinGet, and the primary language is C# in a .NET solution, but nothing here suggests a cross platform build. The project is Windows only in practice.

There is one more practical constraint that is easy to overlook: this is an extension whose usefulness depends on the surrounding PowerToys installation. If the target machine has PowerToys but an older build whose extension interface does not match what ECP expects, the failure is a mismatch between two separately updated pieces of software, and the plugin's own release notes are not where you would look for the answer.

Against the standalone Everything window, the difference is one keystroke

The realistic alternative is not another plugin. It is the two tools side by side, which is how most people use them today: CmdPal for launching applications and running commands, and the Everything window for finding files, opened with a hotkey when needed.

The difference in approach is entirely about the interaction cost. With both tools, finding a file means pressing a hotkey to summon a different window, type a query, and then switch back to what you were doing. With ECP installed, the same query goes into the same palette you already use for everything else, so the launcher and the file search are one surface.

What ECP does not change is the underlying search. The results come from Everything's index, so the speed and the matching behaviour are the same in both arrangements. ECP adds a presentation layer and a keystroke, not a search engine. That also means the failure modes are shared: if a file is not in the index, it will not be found through the palette either, and the extra step in the chain does not add any recovery for a missing index entry.

The case for adopting it is therefore about workflow consolidation rather than capability. If you find yourself alt-tabbing between the palette and the Everything window several times a day, the extension removes that. If you do not, or if you prefer a dedicated window with its own filters and sorting, then the plugin adds a dependency to your launcher for no benefit, and the standalone arrangement is the better default.

Editorial conclusion

EverythingCommandPalette fits a Windows user who already runs Everything and wants the same file search inside the PowerToys Command Palette, especially on a machine where the palette is the only launcher they keep open. It is the wrong tool if you do not run Everything at all, since the extension adds the Everything search path and nothing else, and it is not a replacement for a full file manager. Before installing, confirm three things: which of the five install channels matches how your machines are provisioned, since the MSIX path is the one that survives a profile reset on a managed device, that the Everything search index is already populated on the target machine, and what the features page on the wiki says about the plugin settings, because the repository itself does not document them. The code is EPL-2.0, the most recent release is v0.9.26030.0 from 2026-07-10, and the last push was on 2026-09-09.

Frequently asked questions

Official sources

1. Issues
2. License: EPL-2.0
3. lin-ycv/EverythingCommandPalette on GitHub
4. README
5. Releases