Add Unblock-File step to README for ZIP users (prevents GUI launch)

[se681268]

Checklist

• I have searched for existing issues/discussions and didn't find any similar ones.
• I haven't used any other scripts, tools or programs that might have caused this issue.

Windows version

win11 23H2

Script mode/options

without any options

Describe the issue

When users download the Win11Debloat ZIP archive directly from GitHub (via browser) and extract it, Windows adds a "Mark of the Web" (Zone.Identifier) to all extracted files. This causes PowerShell to prompt a security warning for every single .ps1 file the script tries to load via dot-sourcing.

GUI depends on loading multiple script files, these prompts interrupt the initialization – the script cannot complete the load and falls back to CLI mode instead of showing the graphical interface.

A simple fix is to run(under the extracted folder):

Get-ChildItem -Path . -Recurse -File | Unblock-File

This removes the block in one step and allows the GUI to start normally.

Please consider adding this command to the README (under "Usage" or a new "Troubleshooting" section). It would make the tool more beginner-friendly.

Thank you for your work!

Steps to reproduce

Download the latest Win11Debloat ZIP from the Releases page using a browser.

Extract the ZIP to a folder.

Open PowerShell as Administrator and navigate to the extracted folder.

Run .\Win11Debloat.ps1 (or Run.bat).

Error output

No response

Additional context

No response

[HetCreep]

Confirmed the mechanism against the current code, with one clarification on when it bites:

• Run.bat should NOT hit this -- it launches PowerShell with -ExecutionPolicy Bypass at both layers, and Bypass suppresses Mark-of-the-Web prompts entirely. The failure path is running .\Win11Debloat.ps1 directly in a shell whose policy is RemoteSigned (or stricter), where every dot-sourced .ps1 carrying the Zone.Identifier stream gets blocked.
• The official install path (irm "https://debloat.raphi.re/" | iex) also doesn't hit it -- Expand-Archive does not propagate the Zone.Identifier stream to extracted files. It's specifically the browser-download + Explorer-extract route that marks every file.
• A side effect worth noting for the maintainer: when the GUI scripts fail to load for this reason, the fallback at Win11Debloat.ps1 prints "Unable to load WPF GUI (not supported in this environment), falling back to CLI mode" -- which points the user at the wrong cause entirely (they'll think their machine lacks WPF, when their files are just blocked). That message masking the real error is arguably why this took a bug report to surface.

Beyond the README note (which is a good idea), a code-level option: since the main script demonstrably does run in this scenario (it gets far enough to fall back to CLI), a one-liner at startup would self-heal the whole folder before any dot-sourcing:

Get-ChildItem -Path $PSScriptRoot -Recurse -File | Unblock-File -ErrorAction SilentlyContinue

That fixes it for everyone without requiring them to find a troubleshooting section -- several PowerShell projects ship exactly this. Whether to take the docs route, the code route, or both is of course the maintainer's call.

Immediate workaround for anyone hitting this now: either run the one-liner from the issue body in the extracted folder, launch via Run.bat, or use the official irm | iex install path.

[se681268]

Thank you for the detailed analysis.

In my case, the shell's execution policy is set to allow all scripts (Unrestricted). I launched the script via Run.bat, and the first security warning asked whether to run Win11Debloat.ps1. After I chose "Run once", the script proceeded to execute a series of dot‑sourced .ps1 files one by one – each of them triggered a separate security warning, and I had to press R for every single file.

There was no fallback to CLI mode, no "Unable to load WPF GUI" message appeared on the console, and I couldn't find any relevant error in the logs. The script just kept running through the steps, with no interactive menu and no indication that something was wrong – until I realized something was off about the repeated warnings.

After running Get-ChildItem -Path . -Recurse -File | Unblock-File on the entire folder, everything worked perfectly and the GUI launched as expected.

I hope this additional context helps. Please let me know if there's any other detail I can provide.

Thank you for your work on this great tool!

[HetCreep]

Thanks -- this is a genuinely useful correction, and it changes two things in my earlier analysis:

1. Your prompts are the Unrestricted behavior, and they explain why Run.bat didn't protect you. The per-file "Do you want to run this software? [R] Run once" warning is exactly what the Unrestricted policy does with internet-zone (Mark-of-the-Web) files -- unlike Bypass, which suppresses warnings entirely. Run.bat does pass -ExecutionPolicy Bypass, so the fact that you still got warnings means something overrode it -- and the one thing that overrides a command-line -ExecutionPolicy is a policy set at Group Policy scope (MachinePolicy or UserPolicy). If you're curious, Get-ExecutionPolicy -List will show it: an Unrestricted under MachinePolicy or UserPolicy confirms it (many "enable scripts" guides set it that way via GPO/registry without mentioning the side effect).

2. I'll retract the "falls back to CLI with a wrong message" detail for your variant. In your case every file did run (you pressed R each time), so nothing failed outright -- the damage was the interrupted load sequence, with no error surfaced anywhere. Different path from what I described, same root cause, and arguably worse: nothing at all told you what was wrong.

Net effect for the maintainer: this case strengthens the argument for the code-level self-unblock over a docs-only fix -- a GPO-scoped policy defeats Run.bat's Bypass, and no README note anticipates that. Unblock-File removes the Zone.Identifier stream itself, which works regardless of which policy scope is in force -- exactly matching your result (one sweep, permanently fixed).

[se681268]

Thank you for the thorough analysis – this clarifies everything perfectly.

I can confirm that running Get-ExecutionPolicy -List shows Unrestricted under MachinePolicy. Your explanation about the GPO‑scoped policy overriding -ExecutionPolicy Bypass makes perfect sense, and I fully agree that a code‑level self‑unblock would be a robust fix for cases like mine.

I appreciate your detailed suggestions, and I'm happy to test any changes if needed. Please let me know if you require any additional logs or information.

Thanks again!

[HetCreep]

PR is up: #724 -- one Unblock-File sweep at startup (before any dot-sourcing), so it works regardless of policy scope. Since you offered: if you get a chance to test it on the affected machine, the quickest way is to download the ZIP fresh with a browser, extract with Explorer as before, replace Win11Debloat.ps1 with the version from the PR branch, and launch -- with your MachinePolicy=Unrestricted setup you'd previously get per-file prompts, and with the patch the sweep should clear them all after the first prompt for the main script itself. Your GPO-scoped machine covers exactly the scenario I can't reproduce locally.