Automating a Fresh Windows Install with Claude Code, PowerShell and WinGet

The idea is sound and worth stealing. The script itself hasn't been published, so some caution is in order.

What the script reportedly does​

Brown's usual routine has three parts. He installs a browser (Brave), installs everyday apps, then turns off Windows defaults he dislikes and strips out what he considers bloat. He had put off scripting it because the work meant hunting down WinGet package IDs, registry values and PowerShell commands.

He gave Claude Code a plain list of preferences grouped into apps, Explorer tweaks, features to disable, and a nicer terminal. Claude returned one sectioned PowerShell script. Sections can be commented out, and the script reportedly checks state before changing anything, so a re-run should be harmless. A summary at the end lists what it did. Brown says Claude looked up package IDs and registry values online, and that he asked it to cite sources for what it wrote.

According to the write-up, the script covers these areas:

• Apps via WinGet: Notepad++, Brave, 7-Zip, VLC, Everything, VS Code, PowerToys and about a dozen more.
• Registry tweaks: system-wide dark mode, hidden files and known file extensions visible, Explorer opening to This PC, and a confirmation prompt before deleting to the Recycle Bin.
• Debloat: Copilot, Recall, Bing results in Start, widgets and Start recommendations.
• Finishing touches: terminal settings and a WSL install. WSL needs a reboot, so the script uses a RunOnce entry to resume. Ubuntu then opens for the user to finish setup.

The article shows only a short sample, so the full app list, registry paths and removal commands can't be checked. That also means the "safe to re-run" claim can't be checked. It is the author's description, not something PowerShell guarantees.

What the WinGet loop actually does​

The sample loop calls winget install -e --id <id> --silent --accept-package-agreements --accept-source-agreements for each package. Microsoft's documentation confirms the options work as Brown describes:

• -e / --exact makes the query an exact, case-sensitive match instead of the default substring search. Pairing it with --id is Microsoft's own recommended way to pin down a single package.
• --silent suppresses installer UI. --accept-package-agreements handles the package's own license prompt, and --accept-source-agreements handles the terms for the WinGet source itself.
• Microsoft notes that package agreements don't cover optional components or bundled software an installer may offer. So "silent" doesn't guarantee zero interaction.

Exact matching protects you from typos and look-alike names. It doesn't prove a package is trustworthy. Check the IDs against the repository before you run anything.

The reboot trick: WSL and RunOnce​

Microsoft's WSL documentation says the one-command install needs Windows 10 version 2004 (build 19041) or later, or Windows 11. You run wsl --install from an elevated PowerShell. That enables the required features and installs Ubuntu by default, and a restart may be needed. On first launch the distro unpacks and asks you to create a Linux username and password. That account is separate from your Windows login, which is why Brown's script stops there for his input.

There is a gotcha. Microsoft says wsl --install only works if WSL isn't installed at all. If you see the help text instead, run wsl --list --online and then wsl --install -d <DistroName>. A script meant to be re-run should handle that case.

Microsoft describes RunOnce as a registry key that runs a command once at logon and then removes it. Three details matter for anyone copying the approach:

• The machine-wide RunOnce key only runs when a member of the Administrators group logs on after the reboot.
• By default the value is deleted before the command runs. If your resume step fails, it won't retry on the next boot.
• Prefixing the value name with ! defers deletion until the command finishes, which gives you a retry.

Brown doesn't say which hive or failure handling his script uses, so don't assume his version is robust on this point.

A caution on the debloat section​

Recall is on Brown's removal list, but the article doesn't say how it was removed or on what hardware. Microsoft's Recall documentation says it's a Copilot+ PC feature. It's disabled and removed by default on managed devices, and it requires user opt-in before snapshots are saved. On a non-Copilot+ machine there may be nothing to remove. A generic registry tweak isn't guaranteed to do anything there, and the script's summary may simply report success.

The same applies to the other debloat items. Windows updates can change or retire those settings, as Brown himself warns, so read the logs after each run.

How to test an AI-written setup script safely​

Brown's advice to treat AI output like any script from a forum is sensible. A practical routine:

1. Read every line. PowerShell is plain text, so check each registry path and package ID against official documentation.
2. Keep sections independent so you can comment out anything you don't understand.
3. Test in Windows Sandbox first. Microsoft says it's a disposable, hypervisor-isolated environment that is wiped when closed. It's supported on Pro, Enterprise, Pro Education/SE and Education, but not Home.
4. Remember that Sandbox networking is on by default. Microsoft warns this can expose untrusted apps to the internal network, and it can be turned off in the configuration file.
5. Keep a recovery path, such as a restore point or image, and review the logs afterward.

Sandbox is a useful first test, not proof of safety. A pristine Sandbox won't behave exactly like a host that has been through Windows Update, so a clean pass there doesn't guarantee a clean run on real hardware.

Is there a more "official" route?​

Yes, and it's worth knowing about. Microsoft offers WinGet Configuration, a YAML-based approach where, a configuration file lists the packages, tools, dependencies and settings needed for the desired machine state. The winget configure command starts the process. Microsoft pitches it as unattended setup, using Windows Package Manager and PowerShell DSC. It requires WinGet v1.6.2631 or later. Microsoft's configure documentation also tells users to confirm a configuration file is safe and trustworthy before running it, which is the same warning Brown gives about scripts.

A declarative file describes the end state and lets the tooling work out how to get there. An imperative script like Brown's gives you direct control over odd registry edits and reboot sequencing. In my view (general industry knowledge, not from his article), a hybrid is reasonable: WinGet Configuration for apps and standard settings, and a script for the unusual tweaks.

Bottom line​

The real value here isn't the 20-minute number. It's that AI is good at the tedious research behind a setup script, such as package IDs, registry values and command syntax. It isn't a replacement for review. The sample WinGet loop matches Microsoft's documented behavior, and the WSL and RunOnce approach is plausible. The rest of the script, including what the "checks before changing" logic does and how Recall is handled, can't be verified from what's public.

If you try this yourself, prompt for sections and citations, read the output line by line, run it in Sandbox, and check the logs.