DEV Community: Windows Mode

Before You Pipe Microsoft's One-Line Dev Box Setup into iex, Read What It Changes

Windows Mode — Wed, 28 Oct 2026 08:06:20 +0000

At Build 2026 Microsoft announced two things that matter if you set up Windows machines for coding: Windows Developer Configurations, a one-command setup for a fresh dev box, and Coreutils for Windows, native builds of ls, cp, grep and friends. Both were announced as generally available.

The setup is one line of PowerShell piped into iex. That is convenient, and it is also exactly the kind of command you should read before running on a machine you care about. So we read the repo docs and the scripts. Here is what actually happens, what changes on your machine, and the parts that could surprise you.

TL;DR

irm https://aka.ms/devconfig/standard/setup.ps1 | iex installs about 18 packages with winget, changes Explorer, Start, search and theme settings, installs WSL with Ubuntu, and may restart your PC once.
Standard runs the bootstrap with -Action Partial. Full runs -Action Full and adds Developer Mode, Sudo, widgets off, two Edge policies and Remote Desktop.
The scripts verify Microsoft Authenticode signatures on everything they download, but irm | iex itself does not verify the small wrapper script. You can check it yourself first.
The uninstall script permanently deletes the Ubuntu distro without asking, and it removes the tools it manages even if you had them installed before.
Coreutils for Windows installs with winget install Microsoft.Coreutils. In PowerShell several commands clash with built-in aliases, which matters for scripts.

The one-liners

From the WindowsDeveloperConfig repo:

# Standard experience
irm https://aka.ms/devconfig/standard/setup.ps1 | iex

# Full experience
irm https://aka.ms/devconfig/full/setup.ps1 | iex

# Uninstall (covers both)
irm https://aka.ms/devconfig/standard/uninstall.ps1 | iex

The aka.ms links redirect to setup-standard.ps1, setup-full.ps1 and uninstall.ps1 in the repo. Each wrapper is about 20 lines. It downloads bootstrap.ps1 from a pinned commit, checks that the signer is Microsoft Corporation, and only then runs it with -Action Partial, -Action Full or -Action Uninstall.

The repo is honest about the gap: "irm | iex does not verify the wrapper's own signature; it trusts the HTTPS endpoint." If you want to check the entry script too, download it and look before you run anything:

$f = "$env:TEMP\setup-standard.ps1"
Invoke-WebRequest https://aka.ms/devconfig/standard/setup.ps1 -OutFile $f
Get-AuthenticodeSignature $f | Format-List Status, SignerCertificate
notepad $f

It is short enough to read in a minute, and it is a good habit for any irm | iex install, not just this one.

What gets installed

The Standard setup installs these with winget:

Area	Packages
Shell and terminal	Windows Terminal, Intelligent Terminal, PowerShell 7, Oh My Posh
Source control	Git, GitHub CLI
Editors and AI	VS Code, GitHub Copilot CLI
Runtimes	.NET SDK 10, Python 3.14 + uv, Node.js LTS + nvm for Windows
Cloud	Azure CLI
Utilities	Coreutils for Windows, Windows App CLI, PowerToys, Visual C++ Redistributable

It then sets PowerShell 7 as the default Terminal profile, installs Cascadia Code NF and Cascadia Mono NF for all users, adds a GitHub Copilot profile to the Terminal dropdown, and installs WSL plus Ubuntu with wsl --install -d Ubuntu --no-launch.

Practical numbers from the docs: roughly 30 minutes on a clean machine, about 15 GB of free disk space, up to two UAC prompts, and Windows 11 only. Windows 10 is not supported.

What it changes on your machine

This is the part worth reading twice. Some highlights from the documented registry changes and the "Known limitations" table:

Explorer: file extensions and hidden files shown, full path in the title bar, Explorer opens to This PC, no recent or frequent items in Quick Access.
Start and search: no web results in search, no Start recommendations, no search highlights.
Notifications: Do Not Disturb is turned on globally, not just for quiet hours, until you turn it back off.
Theme: dark mode for apps and the system.
Long paths: LongPathsEnabled set to 1.
Node: both Node.js LTS and nvm for Windows get installed. The docs suggest uninstalling Node.js first if you want nvm to own the PATH entry.
Your PowerShell profile: an Oh My Posh block is added to $PROFILE. If the profile already has other initialization, setup leaves it alone and flags it.
Terminal settings: settings.json is round-tripped through JSON, so comments are lost. A settings.json.bak is written first.

The Full setup adds more:

Developer Mode and Sudo (inline mode).
Widgets turned off through policy.
Two Edge settings written as policy, so Edge will say it is "managed by your organization".
Remote Desktop allowed (fDenyTSConnections set to 0). The docs note the firewall rule is not opened, but it is still a change to the machine's security posture.

What it does not do, per the docs: no telemetry, no sign-ins, no credential changes, no Windows Defender changes. Git and the GitHub CLI are installed but not configured, so you still need git config user.name and gh auth login.

There is also no dry run (-WhatIf) and no switch to skip individual packages. If you want a different package list, the documented path is to clone the repo, edit the files under src\windows-dev-config, and run the unsigned source with -AllowUnsigned.

The restart and the uninstall

WSL needs virtualization, so setup may restart the machine. It warns you and restarts after 10 seconds, so save your work before you start. A scheduled task called WindowsDevConfigResume picks the run up after you sign back in. If nothing happens:

Get-ScheduledTask -TaskName WindowsDevConfigResume

Re-running the original one-liner is safe. Steps that are already done report already OK and are skipped. Logs go to devconfig-log.txt under %ProgramData%\CalmOS.

The uninstall deserves a warning of its own. According to the docs it:

Permanently deletes Ubuntu and its files, without confirmation.
Removes the tools it manages, including copies you had installed before running setup.
Resets settings to defaults rather than restoring what you had before (themes go back to light, for example).

If you have real work inside that Ubuntu distro, export it first:

wsl --export Ubuntu D:\backup\ubuntu.tar

Coreutils for Windows

Coreutils for Windows is a Microsoft-maintained build of the Rust uutils projects (coreutils, findutils and grep), shipped as one multi-call binary. It is MIT licensed and has x64 and ARM64 builds. The current release at the time of writing is v2026.9.3. The Standard setup installs it, or you can install it alone:

winget install Microsoft.Coreutils

Then the usual pipelines work in CMD and PowerShell:

grep -rn "TODO" src | wc -l
find . -name "*.log" -mtime +7

A few things we would want to know before relying on it in scripts:

PowerShell 7.4 or later is required, and 7.6 or later is recommended for ~ support.
Alias clashes. In PowerShell, cat, cp, ls, mv, pwd, rm, sleep, sort, tee and others share names with built-in aliases. The installer hooks into PSReadLine to rewrite what you type interactively, but it does not remove the aliases. Check what a name resolves to with Get-Command ls -All.
Some commands are not shipped because they clash with Windows built-ins or need POSIX features: dir, more, whoami, kill and timeout among them. chmod, chown and uname are dropped too.
No /dev/null. Use NUL, as in find . -name "*.log" > NUL.
CRLF line endings can still trip byte-oriented tools like uniq.
You can turn off individual utilities with coreutils-manager disable <utility name>.

One detail that may confuse you: the Build blog calls Coreutils generally available, but the repo README still says "This project is in preview." Treat it like any young tool and test your scripts before switching a team over.

Our take

For a brand new machine or a throwaway VM, the Standard setup is a sensible default, and the signing and pinned-commit design is better than most irm | iex installers. On a machine you already use every day, we would read the settings list first, skip Full unless you actually want Remote Desktop and Edge policies, and back up WSL before you ever touch the uninstall script.

Have you tried Windows Developer Config or Coreutils for Windows on a real machine yet? Did it save you time, or did it change something you had to undo? And would you trust a one-line setup script on your main dev box, or only on a fresh VM?

We first wrote about the Build 2026 developer announcements on Windows Mode.

Your Agent Should Not Run as You: What Windows Now Offers for Containing AI Agents

Windows Mode — Wed, 21 Oct 2026 08:05:59 +0000

If you run a coding agent on Windows today, its shell commands usually run with your full user rights: your SSH keys, your browser profile, your whole home folder. Microsoft is now putting OS-level boundaries around agents, and a lot of it lands on the developer side first.

We spent some time reading the official docs, the SDK repo and the Microsoft blog posts behind this. Below is our take on what it means if you build or run agents on Windows.

TL;DR

Microsoft Execution Containers (MXC) is an open-source SDK (Rust, .NET, Node) that runs agent workloads inside a policy you define: files, network, UI and the process itself. Microsoft announced it as generally available on 7 October 2026.
Backends differ. Process containers are lightweight. Session containers run the agent under a separate Windows account and session. There are also WSL containers and an experimental MicroVM.
Some agents already use it. GitHub Copilot sandboxes shell commands and local MCP servers with MXC, and you can configure it with /sandbox in the Copilot CLI.
The agent workspace (Settings > System > AI Components > Experimental agentic features) is a separate preview feature that gives agents like Copilot Actions their own account and desktop.
MCP on Windows has an on-device registry (odr.exe) that runs packaged MCP servers in a contained agent session by default. This is still preview.
Still coming: Intune policy for MXC process containers, Entra-based agent identity and Agent 365 controls for local agents.

The problem in one example

Microsoft's own example is a good one. A coding agent is asked to update a website. It needs read and write access to the repo and your build tools. It may need to read the production server config to understand the deployment. It should never change that config.

Without a boundary, the agent may decide that editing the config is the fastest way to finish the task. From the model's point of view that is reasonable. From yours it is an outage.

The core idea in the MXC announcement is that "an agent cannot be its own security authority." The policy lives outside the agent, so neither the model nor the code it writes can grant itself more access.

What MXC actually is

MXC is a library you build into your app or agent harness. You describe the container and its rules, and MXC picks a backend and launches the workload inside it. It covers Windows, Linux and macOS. The microsoft/mxc repo is MIT licensed and publishes SDKs for Rust (mxc-sdk on crates.io), .NET (Microsoft.Mxc.Sdk on NuGet) and Node (@microsoft/mxc-sdk on npm).

The policy has five areas:

Policy area	What it controls
Containment	Which backend runs the workload
Process	Command, arguments, working directory, environment
File system	Read-write paths, read-only paths, denied paths
Network	Inbound and outbound access, including loopback to local services
User interface	Access to the desktop, clipboard and display

This is the Node sample from the repo README. It runs a command with outbound network denied by default:

import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const child = await spawn(request);

Picking a backend

On Windows, the main options are:

Process container. This is the default and the fast one. On Windows it uses AppContainer. It suits coding agents and model-generated scripts where the inner loop needs to stay quick.
Session container (isolation_session in the SDK). This runs the agent under a separate Windows account and session, with its own desktop, clipboard, UI and input. It is Windows only. It fits long-running agents and UI automation, and it is the backend that gives you a distinct identity to audit.
WSL container (wslc). This is for Linux-first toolchains that need Linux packages.
MicroVM. This uses hardware-backed isolation for higher-risk work like running untrusted code. It is marked experimental, as are the Windows Sandbox and Hyperlight backends in the repo.

There is a minimum Windows build. Per the repo's OS version table, process containers need Windows 11 24H2/25H2 build 26100.9278/26200.9278 (August 2026 update) or later. Session containers need 26100.9550/26200.9550 (September 2026 update). On 26H2, both need 26300.9550. If your CI runners or test VMs lag on updates, check this first.

Writing a policy without guessing

This is the part we found most useful. Nobody knows every path an agent will touch before running it, so MXC has three modes:

Enforcement: blocks anything not granted. This is for production.
Learning: still blocks, but records each denial in a JSON activity report.
Permissive: allows everything and records what would have been blocked.

The activity report only works with process containers on Windows. Microsoft's guidance matches what we would do anyway: run in Learning mode, read the denials, and grant only what the workload really needs.

Two things to watch. First, the README warns that the --audit flag on the wxc-exec.exe test executor "turns off all sandbox security" for that run, so never use it on untrusted code. Second, the README says it plainly: "Your application will hit access issues when running in a sandbox, until you've had time to tune your containment rules." Expect a few rounds of tuning.

Microsoft also asks agent developers to plan for organisation policy that is stricter than yours. If a resource is blocked, the agent should explain that and ask for the right access, not fail silently. That is a UX requirement worth building in now.

If you already use GitHub Copilot

The GitHub and Windows post explains how Copilot uses MXC. On Windows it uses the BaseContainer tier of the ProcessContainer backend. With sandboxing on, shell commands, local MCP servers and language servers run inside the process boundary by default.

Two caveats matter for threat modelling:

Copilot's built-in file tools run inside Copilot itself. They are checked against the policy by the agent harness, not by OS process isolation.
Remote MCP servers sit outside the local sandbox.

To check or change your settings, run /sandbox in the Copilot CLI. In the Copilot app, open settings with the gear icon, pick your project and turn on Sandbox new sessions. By default the working directory is read-write and most of the rest of the system is read-only or blocked.

Microsoft lists OpenClaw, OpenAI Codex, Replit, LM Studio and Unsloth AI as also supporting MXC. Claude Code, Manus, Perplexity, Raycast and others "will be releasing support", with no dates given.

The agent workspace is a different thing

It is easy to mix these up. The agent workspace comes from the Experimental agentic features setting, which is used by Copilot Actions. According to Microsoft Support:

It is off by default. Only an admin can turn it on, and then it is on for every user on the device.
It creates separate agent accounts and an agent workspace with its own desktop, apart from the user's session.
Agents can request access to six known folders: Documents, Downloads, Desktop, Music, Pictures and Videos. Agent accounts can also access any folder that all authenticated users can access, such as public user profiles.
On preview builds 26100.7344 and later, you can set file access per agent under Settings > System > AI Components > Agents, with the options Allow always, Ask every time or Never allow.

One small trap: the Windows security book shows the toggle under an extra Agent tools level. Microsoft's own pages show both paths, so search Settings for "agentic" if you cannot find it on your build.

MCP servers and the on-device registry

If you ship an MCP server, this part is for you. MCP on Windows adds the Windows On-Device Agent Registry (ODR). Agents use it to discover MCP servers, and you can inspect it from a terminal on build 26220.7262 or later:

odr mcp list
odr mcp add <path-to-mcpb-manifest-json>
odr mcp remove <server-id>

The containment docs have details that are easy to miss:

Packaged servers registered through ODR run in a separate agent session under a separate agent account. They have no access to your files, settings, credentials or windows unless you grant it.
To run contained, a server must be a binary .exe with package identity (MSIX) and a valid manifest. MCP bundles (.mcpb) currently cannot run contained.
A contained server can still reach the internet. Containment here limits local access, not network access.
File permissions are granted per host app, not per server. If one server used by a host gets access to your files, every server used by that host gets it too.
The "Reduce protections for agent connectors" setting (Settings > System > Advanced > AI components) exists for testing. It does what the name says.

Like the agent workspace, all of this is labelled pre-release.

What is still missing

To be fair about the gaps: per Microsoft, Intune policy for MXC process containers is "soon". Entra support for telling agent activity apart from user activity is "coming soon", and so are Agent 365 controls for on-device agents. If you run agents across a fleet today, you can contain them, but central governance is not fully there yet. For now, plan a pilot rather than a full rollout.

Over to you

How are you sandboxing agents on Windows today: a VM, WSL, Windows Sandbox, a separate user account, or nothing at all? And would you add MXC to your own agent harness, or wait until Intune and Entra support land? Tell us what your setup looks like in the comments.

We first wrote about this on Windows Mode.

Alt+Space Is Our Start Menu Now: A Keyboard-First Windows Dev Setup with Flow Launcher

Windows Mode — Sun, 18 Oct 2026 13:11:55 +0000

Most of our day happens in a terminal, an editor and a browser. The slowest part was everything in between: digging through the Start menu, clicking into File Explorer to find a config file, opening a browser tab just to search GitHub.

We fixed most of that with one tool: Flow Launcher. It is a free, MIT licensed launcher for Windows 10 and 11. You press a hotkey, type, and press Enter. This is how we set it up for development work, and the habits that stuck.

Install it in one line

If you already use a package manager, pick one:

winget install Flow-Launcher.Flow-Launcher

scoop install Flow-Launcher

choco install Flow-Launcher

The project README also lists winget install "Flow Launcher". We prefer the full package ID because it is exact and works well in setup scripts.

There is a normal installer and a portable zip on the GitHub releases page too. Only download from there or flowlauncher.com. Windows may show a SmartScreen warning on first install, and the README mentions this. If you got the file from the official repo, it is fine to continue.

Once installed, press Alt+Space. That is the default hotkey, and you can change it in Settings (Ctrl+I from the search window). We also turned on "start with Windows" straight away.

The built-in keywords worth learning

Flow is plugin based. Most core plugins answer with no prefix at all, so you can just type an app name. A few use an action keyword, and those are the ones that make it feel like a dev tool.

Run shell commands with `>`

> git status
> code .
> wsl --list --verbose
> ipconfig /flushdns

Press Enter to run. Press Ctrl+Shift+Enter to run it as administrator, which saves opening an elevated terminal for one command. You can choose which shell it uses (cmd or PowerShell) in the Shell plugin settings.

Search the web by keyword

The Web Searches plugin ships with keywords for common sites. These are the ones we use every day:

github flow launcher plugin
stackoverflow powershell splatting
gist dotfiles
wiki utf-8

Plain text with no keyword falls back to Google by default, which you can change. You can also add your own searches. We added one for MDN and one for our internal docs by giving each a URL with {q} in it.

Find files and file contents

The Explorer plugin handles files and folders. Typing a path like C:\dev\ lets you browse into folders from the search box. doc: searches inside file contents instead of file names:

doc: connectionString

Small things that add up

b react docs        # browser bookmarks
s environment       # Windows settings, e.g. "Edit environment variables"
kill node           # end a stuck process
128*1024            # calculator, Enter copies the result
?                   # list every plugin's action keyword

kill node alone has saved us a lot of trips to Task Manager when a dev server will not let go of a port.

Make file search fast with Everything

Out of the box, file search uses the Windows Search index. It works, but it skips folders and it is slow on big repos. Flow can use Everything from voidtools instead, which indexes every file name on NTFS drives and returns results almost instantly.

winget install voidtools.Everything

Then open Settings, go to the Explorer plugin and switch the search engine to Everything. If Everything is not running, Flow shows a warning result in file searches, and selecting it can install Everything for you.

After switching, searching for appsettings.Development.json across a dozen repos takes no time at all.

Install plugins from the search box

This is the part we like most. The plugin manager is a plugin itself, with the keyword pm:

pm install github
pm install window walker
pm update
pm uninstall <name>

There is also a visual Plugin Store in Settings if you want to browse first. Plugins can be written in C#, F#, Python or JavaScript. If something you need is missing, writing your own is a real option.

Some community plugins listed in the official README that fit dev work:

GitHub: search repos, issues and pull requests.
Window Walker: switch between open windows by typing their title. This is great with many terminal and editor windows open.
Clipboard+: clipboard history inside Flow.
Colors: preview and convert color codes.

We keep the list short. Every plugin adds results, and too many makes the top result less predictable.

Shortcuts we use without thinking

Keys	What it does
Alt+Space	Open Flow
Enter	Run the top result
Ctrl+Enter	Open the containing folder
Ctrl+Shift+Enter	Run as administrator
Ctrl+Shift+C	Copy the file or folder path
F1	Toggle the preview panel
Ctrl+I	Open settings
Ctrl+F12	Toggle Game Mode (pauses the hotkey)

The preview panel is underrated. Press F1 on a markdown or text file and you get a highlighted preview, so you can check it is the right README.md before opening it.

Tips we actually use

Pin your projects folder. Typing C:\dev\ and then the repo name, then Ctrl+Enter, opens the folder in Explorer. A > code C:\dev\repo command opens it in VS Code.
Lean on fuzzy matching. You rarely need to type a full app name; a few letters or an acronym is usually enough.
Use Dialog Jump. In an Open or Save As dialog, Alt+G jumps to the folder that is open in your file manager. No more navigating the dialog by hand.
Set plugin priority. If Bookmarks keeps beating Programs for a name, raise the priority of the plugin you want in Settings.
Know where your settings live. Type flow user data to open the settings folder (%APPDATA%\FlowLauncher for a normal install). Back it up with your dotfiles.

What we would change

Flow is not perfect. The first run feels busy until you trim plugins, and the default Windows Search index makes file search seem worse than it is. Five minutes in Settings fixes both. Alt+Space can also clash with the window menu in some apps, so pick another hotkey if that bothers you.

Over to you

What is the one launcher keyword or plugin you use every day? If you run Flow, PowerToys Run or something else, we would love to hear what your setup looks like in the comments.

We first wrote about Flow Launcher on Windows Mode.

DEV Community: Windows Mode

Before You Pipe Microsoft's One-Line Dev Box Setup into iex, Read What It Changes

TL;DR

The one-liners

What gets installed

What it changes on your machine

The restart and the uninstall

Coreutils for Windows

Our take

Your Agent Should Not Run as You: What Windows Now Offers for Containing AI Agents

TL;DR

The problem in one example

What MXC actually is

Picking a backend

Writing a policy without guessing

If you already use GitHub Copilot

The agent workspace is a different thing

MCP servers and the on-device registry

What is still missing

Over to you

Alt+Space Is Our Start Menu Now: A Keyboard-First Windows Dev Setup with Flow Launcher

Install it in one line

The built-in keywords worth learning

Run shell commands with >

Search the web by keyword

Find files and file contents

Small things that add up

Make file search fast with Everything

Install plugins from the search box

Shortcuts we use without thinking

Tips we actually use

What we would change

Over to you

Run shell commands with `>`