What is actually safe to delete?

This is the script's own help header, taken straight out of the file above when this page was built. It documents every switch, including the ones that delete. The file is Authenticode-signed, so the signature block sits at the end.

<#
.SYNOPSIS
    Report what is eating a Windows system drive, and how confident you can be about reclaiming
    each part of it. REPORTS BY DEFAULT - it deletes only when you pass -Apply.

.DESCRIPTION
    Space analysers (WizTree, TreeSize) tell you WHERE the bytes are, and they are excellent at it.
    Cleanup scripts DELETE things, and there are a dozen good ones on GitHub. Neither answers the
    question in between, which is the one that actually stops people:

        "Which of this is safe to remove, and what does removing it cost me?"

    Worked example from the machine this was written on. The Windows Installer cache is 6.5 GB. Of
    that, 403 MB is genuinely orphaned; deleting the other 6 GB breaks repair and uninstall for 143
    installed products, and the user finds out weeks later with "the feature you are trying to use
    is on a network resource that is unavailable". A size report cannot tell those apart. A cleanup
    script that empties the folder is actively dangerous. Only a tool that checks each file against
    the installer database can say which 403 MB is which.

    So every finding carries a CONFIDENCE and a stated COST:

      safe     - regenerated on demand, or already dead. Removing it loses nothing.
      caution  - reclaimable, but you give something up, and the something is named.
      leave    - in use. Listed so you know why the space is not available to you.

    WHY A SIGNED SCRIPT AND NOT AN EXE. The best-known tool for the installer-cache half of this is
    an unsigned binary from around 2012. You are being asked to let an unsigned executable delete
    files from C:\Windows\Installer on faith. A signed script is strictly more auditable: you can
    read exactly what it is about to do before you run it. Nothing here needs compiled code.

    WHY NOT JUST cleanmgr /sagerun. The built-in needs a registry preset configured per machine
    before it will run unattended, emits nothing you can parse, and its target list is not
    inspectable - you cannot read it and know what it is about to delete. This is a readable script
    that names every target, its size, and what removing it costs you, before anything is removed.

    INVARIANTS. These are boundaries, not preferences, and they hold whatever switches you pass:

      * USER DATA IS NEVER TOUCHED. Not Downloads, Documents, Desktop, Pictures, or anything
        OneDrive-backed. Deleting a user's Downloads folder is the single most hated behaviour in
        the consumer-cleanup category and this tool does not have that code path at all. The only
        user-profile paths it will ever remove from are AppData\Local\Temp and application caches
        that the application rebuilds on next launch.
      * NOTHING IS DELETED WITHOUT -Apply. The default run reports.
      * IT REFUSES TO RUN DURING AN INSTALL. See -IgnoreActiveInstalls; a cleanup that races a
        patch cycle is how you manufacture a support ticket.
      * NOTHING IS UPLOADED. The JSON is written to your disk and read in your browser.
      * IT NEVER REBOOTS ANYTHING. If the component store needs a restart to finish, it says so and
        exits 3010 for your RMM to act on.

.PARAMETER OutFile
    Where to write the JSON snapshot. Defaults to disk-reclaim.json on your Desktop.

.PARAMETER Gui
    Show a results window instead of console output. Still read-only.

.PARAMETER Quick
    Skip the slow checks (per-profile sizing, component-store analysis). Seconds instead of minutes.

.PARAMETER StaleProfileDays
    A local profile unused for this many days is reported. Default 90.

.PARAMETER Category
    Only run these categories: temp, updates, caches, installer, dumps, images, profiles, system.
    Default is all of them.

.EXAMPLE
    powershell -ExecutionPolicy RemoteSigned -File safe-to-delete.ps1
.EXAMPLE
    powershell -ExecutionPolicy RemoteSigned -File safe-to-delete.ps1 -Gui
.EXAMPLE
    powershell -ExecutionPolicy RemoteSigned -File safe-to-delete.ps1 -Quick -Category temp,updates
#>

That's the first 72 lines of 1,848. Read the rest on GitHub, or open the raw file - it's the same bytes you'd download.

Because the decisions worth making aren’t safe by default. Take the Windows Installer cache: most of it’s still doing a job, and deleting the wrong part breaks repair and uninstall for software that’s still installed. A script that just empties the folder frees space today and hands you a support ticket later. This tells you which part is orphaned and which part has to stay.

Not unless you pass -Apply. A plain run reads, reports, and writes one JSON file, and that’s the default. -Apply removes the SAFE rows only; the ones with a stated cost need -IncludeCaution on top, and the ones marked in-use can’t be removed at all. It refuses to run while an install or a patch cycle is in progress, and it never touches Documents, Desktop, Downloads or anything OneDrive is syncing.

A plain-text log next to the JSON, one line per file with the full path and its size, plus a line for every file it couldn’t remove and why. It appends, so each run adds to the history rather than erasing the last one. Six weeks later, when someone asks what happened to a file, that log is the answer and you read it in Notepad. Turn it off with -NoRemovalLog.

Because you can read it before you run it. The best-known tool for the installer-cache half of this is an unsigned binary, and you’re asked to let it delete files out of C:\Windows\Installer on faith. Nothing here needs compiled code. It’s also Authenticode-signed and timestamped, so you can check who published it with Get-AuthenticodeSignature and Windows will check it for you under RemoteSigned - the timestamp means the signature keeps validating after the certificate expires.

No. The JSON stays on your disk and this page reads it in your browser.

Yes, for the full picture. Only an administrator can read the servicing store, shadow copy storage and the installer database. It still runs without, and says on the report that the numbers are low.

Delivery Optimization, which lives in two separate places. Panther setup logs. The kernel memory dump. Volume shadow copies. The page file, which has an ACL that defeats a plain file check, so plenty of tools report it as absent. And the orphaned part of the installer cache. It also tells you to skip two popular ones: clearing Prefetch buys you nothing and slows boot, and a WinSxS cleanup with /ResetBase can’t be undone.