Windows Developer Config: Microsoft's opinionated Windows dev box setup

What Windows Developer Config actually replaces

Setting up a Windows development machine is usually a manual sequence: install a terminal, install a shell, install Git, install a language runtime, change a dozen OS settings, then enable WSL. Each step is easy. Doing all of them the same way on a second machine is where people drift, and where a new hire spends their first morning in Settings panels instead of a repository.

Windows Developer Config is a Microsoft repository that packages those steps as PowerShell scripts. The README describes the goal plainly: "Go from a fresh Windows install to a fully configured dev box in one command." It is aimed at engineers who provision Windows 11 boxes, and at anyone who wants a single language toolchain without the rest. The repository holds three separate setups, and they are not variations of one script: the Windows Dev Config path uses its own PowerShell scripts, the WSL Comfort path splits work between Windows and the Linux distro, and the Workloads path is built on winget configure. Choosing the wrong one means running more than you need.

One constraint is stated up front rather than buried: the main setup is for a fresh Windows 11 box. The README's own section heading says Windows 11, and the related search phrase about Windows 10 has no matching answer in the README. Treat Windows 11 as the supported target.

How the three setups differ in mechanism

The main Windows Dev Config is a bootstrap script fetched over HTTP and executed directly. It installs dev tools, applies Windows settings, and enables WSL with Ubuntu, including the restart that WSL needs. The README states it is idempotent, so re-running it on an existing machine is intended to be safe, and it does not depend on winget configure at all. The README says this explicitly: Windows Dev Config "doesn't use winget configure and needs none of this."

WSL Comfort works differently. It has a Windows half that handles WSL, the distro, the Cascadia Code Nerd Font, and a themed Windows Terminal profile, and a Linux half that runs inside the distro and configures the shell itself. That split matters because the Linux script, comfort-shell-bootstrap.sh, is standalone: the README says you can copy it onto any Ubuntu host and run it directly. It also supports interactive and non-interactive modes and lets you select individual components rather than taking a fixed bundle.

The Workloads path is the thinnest. Each language ships a configuration.winget file plus a matching install.ps1 shim that applies the configuration and refreshes PATH in the current session. Those workloads depend on winget configure, which the README says must be enabled once with winget configure --enable. The README also warns that when winget is invoked from a non-elevated environment, the Microsoft Visual C++ Redistributable must be installed first, otherwise winget configure fails with an internal error. That is a real prerequisite, not a footnote.

Installing Windows Dev Config and running it once

The README gives a single command to start the full workstation setup. Open any PowerShell window, elevated or not, and run the bootstrap. The -AllowUnsigned switch, per the README, runs the source copy under src/ instead of the signed copy at the repository root.

$url = 'https://raw.githubusercontent.com/microsoft/WindowsDeveloperConfig/main/src/windows-dev-config/bootstrap.ps1'
& ([scriptblock]::Create((irm $url))) -AllowUnsigned

If you are not already elevated, setup requests UAC consent before starting, and requests it again when resuming after the reboot. The README says to expect about 30 minutes on a clean machine. Save your work before running it: the script restarts the machine once, with a 10-second warning, and a scheduled task resumes setup after you sign back in and accept the UAC prompt.

If you only want one toolchain, enable winget configure first and then apply that workload's configuration file. The README gives the TypeScript row as this command, and the same shape applies to the other rows in the table.

winget configure -f .\Workloads\typescript\configuration.winget --accept-configuration-agreements --disable-interactivity

For WSL Comfort, the README shows running the installer script directly. It is interactive by default; -NonInteractive is for unattended runs, and the bootstrap also takes --minimal for a smaller setup.

.\wsl-comfort\install.ps1

What you should see: for the main path, a UAC prompt if you are not elevated, then a long install phase, then the restart warning. For a workload, winget applying the configuration and the shim refreshing PATH so the new tool is usable in the same session.

The restart, the unsigned copy, and other sharp edges

The forced restart is the most consequential behaviour in the repository. Enabling WSL requires a Windows optional feature, and the README is direct about the cost: "It will restart your machine, once." If you are running this on a machine with unsaved work, or on a remote session you cannot easily rejoin, that is the wrong moment. The scheduled task that resumes setup only continues after you sign back in and accept the UAC prompt, so an unattended run still needs a human at the keyboard after the reboot.

The -AllowUnsigned flag deserves a second look. The README explains it as running the source copy under src/ instead of the signed copy at the repository root, which means the command in the quickstart is deliberately the unsigned path. That is a trade-off, not a defect, but it is worth knowing which copy you are executing before you pipe a remote script into a script block. If you want the signed copy, the README's note implies you would fetch from the repository root instead of src/, though it does not print that command.

The workload path has its own failure mode, and the README calls it out: from a non-elevated environment, winget configure fails with an internal error unless the Microsoft Visual C++ Redistributable is installed. The README gives architecture-specific commands for that, winget install Microsoft.VCRedist.2015+.x64 for x64 and winget install Microsoft.VCRedist.2015+.arm64 for ARM64. Install the right one for your machine before blaming the workload configuration.

Finally, the README does not document rollback on the front page. It says full details, including how to undo the settings, live in src/windows-dev-config/README.md. If reversibility matters to you, read that file before running anything.

When a provisioning script is the wrong tool

The Workloads path overlaps with a plain package manager. If you need Node.js LTS and nothing else, winget install OpenJS.NodeJS.LTS does the job without a configuration file, without --accept-configuration-agreements, and without the redistributable prerequisite. The workload exists to keep the toolchain definition in the repository and apply it the same way each time, which is a different goal from installing one package once.

There is also a scope boundary inside the repository itself. Windows Dev Config installs a fixed, opinionated list: Windows Terminal, PowerShell 7, Git, GitHub CLI, GitHub Copilot CLI, VS Code, .NET SDK 10, Python 3.14 with uv, Node.js LTS with nvm, Coreutils for Windows, Windows App CLI, Oh My Posh, and PowerToys, plus a set of Windows settings and WSL with Ubuntu. If your team standardizes on a different editor, a different Python distribution, or a managed endpoint tool that fights the script, the main path is the wrong fit. WSL Comfort is the escape hatch here, because the README says it lets you pick and choose individual components.

A related search phrase asks whether it is good to enable Developer Mode. The README lists Developer Mode among the Windows settings the main setup applies, but it does not argue for or against it. That decision is yours, and the script makes it for you if you run the full path.

Maintenance, licence, and what upgrading costs

The repository is not archived, and the last push was on 2026-09-17. There are no releases listed, so there is no versioned artifact to pin: the quickstart fetches bootstrap.ps1 from the main branch over raw.githubusercontent.com. That is the real upgrade model. Every run pulls whatever is on main at that moment, which means the scripts can change between two runs on two machines with no version number to compare. If you need reproducibility across a fleet, fetch the script once, store it internally, and run your stored copy.

The repository is MIT licensed, which is permissive and places few conditions on reuse. That is a statement about the licence text, not legal advice; if you redistribute the scripts inside a commercial product or a corporate image, have your own counsel read the LICENSE file at the repository root.

Maintenance cost is mostly the OS settings the main path applies. Dark theme, Developer Mode, Sudo, long paths, File Explorer defaults, Start and Search cleanup, Do Not Disturb, widgets off, and Edge policies are all changed on your machine. The README defers the undo instructions to src/windows-dev-config/README.md, so the cost of adopting the full path includes reading that file. The workload path is cheaper to maintain: a configuration.winget file per language is a small surface, and removing a toolchain is a normal uninstall.

What to check before you commit a machine to it

Confirm the target is Windows 11. The README's main section is written for a fresh Windows 11 box, and the README offers no Windows 10 path. Confirm you can afford the restart and that someone will be present to accept the UAC prompt afterwards, because the resume depends on it.

Decide which of the three setups you actually want. Running the full Windows Dev Config to get one language runtime installs a dozen tools and changes OS settings you did not ask about. The Workloads table exists precisely so you can take one row: TypeScript, PHP, .NET, Go, and the others each have their own configuration.winget and install.ps1.

Read src/windows-dev-config/README.md before the first run, not after. It is where the README says the full list of changed settings and their undo steps live. If you are evaluating rather than adopting, run WSL Comfort's Linux half, comfort-shell-bootstrap.sh, on a throwaway Ubuntu host first; the README says it is standalone, so it carries no Windows-side risk.

Editorial conclusion

Adopt it if you provision Windows 11 machines repeatedly and want the same tool list every time, or if you only need one language toolchain through the Workloads folder. Skip it if you are on Windows 10, if you cannot accept a forced restart, or if you need a documented rollback: the README points to src/windows-dev-config/README.md for how to undo settings, but does not spell it out on the front page. Verify first that your machine is Windows 11, that you can run PowerShell, and that you are willing to re-run the script after the reboot.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/WindowsDeveloperConfig on GitHub
4. README