PowerToys makes you pick an install scope once, and winget keeps it forever

Scope is chosen at install time and inherited at every update

The WinGet route is the only one where the readme shows the commands, and it makes the decision explicit with two variants. User scope is the default:

winget install Microsoft.PowerToys -s winget

Machine-wide is the other:

winget install --scope machine Microsoft.PowerToys -s winget

The sentence that matters sits between them: updating PowerToys via winget will respect the current PowerToys installation scope. Consequence: scope is not a property of the package you can change later, it is state the updater follows, so running the machine-wide command over an existing per-user install produces a second installation rather than a conversion. The GitHub route pushes the same choice onto you differently, because there you scroll to Assets and pick the file matching your architecture and install scope, and the readme's guidance is x64 per-user for most devices. The community routes, Chocolatey and Scoop, are linked out to Microsoft's own documentation, so the repository never states what scope those installers use.

Every recent release is a Preview at 0.x with a per-build number

The three most recent tags are v0.101.2712.0, v0.101.2684.0, and v0.101.2652.0, and all three are titled Preview. They are dated 23, 26, and 30 September 2026, so a week produced three releases, and each version string carries a fourth component that increments with the build rather than the feature set. The last push to main is dated 25 September 2026, so the tags and the branch head are not cut on the same cadence. Consequence for anyone automating against this: a 0.x project carries no compatibility promise, and pinning v0.101.2712.0 pins something superseded within days, so a deployment that tracks the Preview channel can change under you without any config change on your side. The MIT license covers the code either way, but the release channel is the part that moves.

The roadmap says several utilities are mid-migration to WinUI 3

The roadmap section names the next version, v0.102, and three pieces of work: modernizing several utilities with WinUI 3, expanding Command Palette with tabs and JavaScript/TypeScript extensions, and adding new productivity improvements across PowerToys. None of those is scoped to a named utility, which is the useful part. Consequence for a user: part of the suite is being rewritten underneath the release notes, so an upgrade can change a utility's appearance or behaviour with no feature entry to explain it, and any instructions you have for the version you are running may not match the version you get. The second item is the more interesting design signal, since it adds a JavaScript and TypeScript extension surface to Command Palette in a repository whose primary language is C, which means the customization path for at least one utility is a script rather than a recompile.

Three dependency systems share the root of one C++ repository

The top level carries enough build configuration to matter. There is vcpkg.json with a matching vcpkg-configuration.json for native C++ dependencies, nuget.config plus packages.config in the legacy per-project NuGet form, and Directory.Packages.props which is the newer central package management manifest. Alongside those sit Directory.Build.props, Directory.Build.targets, Cpp.Build.props, Cpp.Build.targets, and CppRuleSet.ruleset for code analysis, and the solution file is PowerToys.slnx rather than a classic .sln. Consequence for a contributor: a dependency can be declared in three ecosystems at once, and updating it in one does not update the others, so the readme's single sentence pointing at ./doc/devdocs for how to set up a computer to compile is doing all the work of telling you which manifest owns what. A newcomer who adds a package in the wrong system can end up with two versions of the same dependency in one build.

MIT code, but contributions need a signed CLA

The contributing section is unusually explicit about paperwork. It asks that before you start work on a feature you would like to contribute you read the Contributor's Guide, and it says that most contributions require you to agree to a Contributor License Agreement declaring that you grant the rights to use your contribution and that you have permission to do so. The second half is the clause that matters. Consequence for a reader: the repository is MIT, so the code carries a permissive license, but the inbound path is not permission free, which means anyone whose work is owned by an employer or a client has a signing step before a pull request can proceed, and a drive-by fix from a contributor who cannot license their employer's work has no route in. Non-code contributions are invited too, including spec writing, design, documentation, and bug finding, and the readme does not say whether those also require the CLA.

Telemetry gets one sentence, and the field list lives elsewhere

The privacy statement is the whole of it: the application logs basic diagnostic data, described as telemetry, with a pointer to the PowerToys Data and Privacy documentation hosted on an aka.ms link, and a matching DATA_AND_PRIVACY.md at the repository root. Consequence for a reader deciding whether to install: the readme gives you the adjective basic and no fields, no retention period, and no per-utility breakdown, so an assessment before installation means leaving the repository, and a reviewer on a locked-down machine has to fetch that document separately or decide without it. The gap is amplified by the shape of the product, because the 31 listed utilities are separate pieces that can run independently, and the readme says nothing about which of them start with Windows, which launch on demand, or which are network-facing, so the telemetry sentence cannot be turned into a per-tool judgement from anything here.

Thirty-one utilities, and no column saying which ones are resident

The utilities table names 31 entries, matching the readme's claim of over 30, and they are not the same kind of thing. Some are window and desktop managers such as FancyZones, Workspaces, Always on Top, Window Hopper, and Mouse Without Borders. Some are launchers and shells, PowerToys Run and Command Palette. Some are one-shot context tools you invoke on a selection, Image Resizer, Color Picker, PowerRename, Text Extractor, Crop And Lock, and Screen Ruler. Others touch system configuration directly, Environment Variables, Hosts File Editor, Registry Preview, and File Locksmith. Consequence for a reader: the table has no column for startup behaviour, resident process, or network use, so the common questions, whether the tools are necessary, whether they are safe, and what they cost in memory, cannot be answered from it, and the honest way to use the list is to enable the handful you actually want rather than to reason about all 31 at once.

Editorial conclusion

PowerToys suits a Windows user who wants window management, a launcher, a keyboard remapper, and a set of one-shot context tools without rebuilding anything, and who will install per-user on x64 as the readme recommends. Decide the scope before the first install rather than after, because a winget update respects whatever scope is already present, and installing machine-wide over a per-user copy leaves you with two. Pin a version rather than tracking the Preview channel, since the build component of a tag like v0.101.2712.0 changes every few days and the project is still at 0.x. Read DATA_AND_PRIVACY.md before deploying it on a managed machine, since the readme's only privacy sentence is that the application logs basic diagnostic data, with the field list kept elsewhere. And if you intend to contribute, note that most contributions require signing a Contributor License Agreement even though the project itself is MIT. For system requirements, the readme defers to Microsoft's installation documentation rather than stating them.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes