Desktop app
The desktop app is a window over the same engine. It runs the bundled windowsweep.ps1 with --json --no-color and reads its section list from --list --json. It reimplements no cleanup logic: the chokepoint, the protected lists and every refusal are the ones the command line enforces. The two differ in what leaves the machine, and that has three answers.
What it adds over the command line
Nothing to the deletion behaviour. Everything to what you can see while it happens.
The catalogue becomes a table you can filter. A run shows the engine's own log as it arrives, beside a table of what each section reclaimed; sections that ask you to choose files, folders or programs get a picker. Most controls in Settings map to a flag the engine already has, so anything you set there you can also type.
What it does not do
It never raises its own privileges. Eight sections need Windows to ask your permission first, and a machine-wide program uninstall in section 26 may need it too. Ask for an admin section, and a second, elevated window runs only that work and writes its own report, while this one waits unelevated. It does not remove the deep-section gate.
What leaves the machine
Three answers, because three different things are running.
The engine sends nothing, ever. No network calls at all, and a self-test check fails the build if one appears.
The window sends usage and crash reports, to improve the product for everyone. There is no switch. The first-run screen is a notice with one Continue. Four destinations - product analytics, behaviour analytics, session replay with every piece of text masked, and crash reports with file paths stripped out. In 1.1.0 no destination was configured in the build, so nothing left the machine. From 1.2.0 all four are, and the reports are sent from the first launch - though until 1.3.2 the window's own security policy refused two of them, the session replay and the crash reports, so only the two analytics destinations received anything.
Two requests run without asking, and neither carries anything this app knows about you. On every start the app fetches latest.json from this repository's releases; on a machine with no WebView2, the installer downloads it from Microsoft.
Never sent: a file path, a folder name, a drive label, your user name, your machine name, or the contents of anything. A run summary is a count and a number of bytes.
Sign-in and sync
Optional, Google, and it opens your normal browser rather than a window inside the app, so you can see the address bar. What it uploads, in full:
| Your settings | Each run summary |
|---|---|
| your preferences, and when you last changed them | date and duration |
| the developer answer | mode, dry-run, elevated |
| your email address and display name | the section numbers it ran |
| a last-seen timestamp | bytes reclaimed, bytes estimated, and an id |
In 1.1.0 and 1.2.0 this was dormant, because Google was not enabled on the backend project. From 1.3.0 it is on, but 1.3.0 and 1.3.1 refused every sign-in at its last step; from 1.3.2 it completes.
Install it
Download the .msi or the .exe installer from Releases. The .exe installs for the current user and asks for no administrator rights; the .msi installs for every user, so Windows asks once. The engine ships inside the app: no separate PowerShell setup, and no Node.
Windows may warn you the first time you install this
The installer is not signed with a paid code-signing certificate, so Microsoft SmartScreen shows "Windows protected your PC" on first run. That is a statement about the certificate, not about the file.
Choose More info and then Run anyway. You can verify what you downloaded first: every release publishes a SHA-256 checksum for each installer, and a minisign signature the app's own updater checks. Neither is a code-signing certificate - they prove the file is the one that was built, not who built it. The source is public.
This note is here rather than hidden because meeting that dialog unexplained is worse than reading about it in advance.
Updates
The signed updater checks on the splash screen and again when the window resumes or reconnects. An available update is offered as Later or Install and restart. A published release record adds a separate gate: an urgent release blocks an older build immediately with its reason and an Update button; a normal release is announced at once and becomes required from the next start. A record is checked on start and when the window resumes or reconnects, and a broadcast signals publication. If the network is unavailable, the app carries on unless a normal release was already announced on an earlier start. A failed update offers the release page and support links.
Where it writes
Each run gets its own folder under %LOCALAPPDATA%\com.aoneahsan.windowsweep\runs\, holding that run's report and log. An elevated run writes a second report beside the first, because two windows each write their own.
See also: Safety model · Admin sections and elevation · Sections 0-29
Last Updated: 2026-11-03