DEV Community: Windows Mode

Microsoft's New Copilot Code Lets Anyone Ship Internal Apps. What Should Developers Do About It?

Windows Mode — Wed, 11 Nov 2026 08:08:30 +0000

On 25 September 2026 Microsoft rebuilt its work Copilot app around three tabs: Home, Code and Autopilot. Code is the one developers should pay attention to, because it is built for people who are not developers, and the things it produces will still end up running inside your company.

I went through Microsoft's announcement, the Copilot pricing post and the related Microsoft 365 message center notice. Everything below comes from those sources. Where something is still preview or private preview, I say so.

TL;DR

Code turns a plain-language description into an app, tracker, dashboard, automation or workflow. Microsoft says it is powered by the same underlying technology as GitHub Copilot.
It runs in a sandboxed environment and can be hosted inside your Microsoft 365 tenant.
Hosting comes from Copilot Managed Runtime, which is in preview and which Microsoft says it is opening up to third-party and pro-code developers.
Autopilot (previously called Scout) is a cloud-hosted agent with its own identity, memory, computer and workspace in your tenant. It is in private preview.
Cowork, Code and Autopilot run on usage-based billing with Copilot Credits. In enterprise tenants they stay off until an admin creates a spending policy.
Microsoft says developers keep using GitHub Copilot for their day-to-day work.

What Code actually is

Microsoft frames Code as a new unit of knowledge work, next to the document, the spreadsheet and the deck. You describe what you want and Copilot "chooses an approach and builds it". The examples Microsoft gives fall into three shapes:

Persistent desktop widgets for quick reference.
Interactive dashboards for exploring data and testing outcomes.
Cloud-hosted internal apps you can share with your team.

The announcement says Code is grounded in Microsoft IQ, so what you build can use the context of your work, and that plugins sync automatically. Fabric IQ, which brings in data such as Power BI semantic models, is generally available in Chat and Cowork, with Code integration "coming through the Frontier program soon".

On timing, Microsoft said Code would roll out to its Frontier early access program at the end of September, with broad availability in the following weeks, and a preview for Microsoft 365 Premium and Pro subscribers later in 2026.

Copilot Managed Runtime is the part that matters to devs

The prompt box gets the attention, but the hosting layer is the real platform move. Microsoft describes Copilot Managed Runtime as "hosting infrastructure that lets code run safely right inside your company's Microsoft 365 environment". It is governed by IT, while users can share an app with teammates, connect it to live data and open it from anywhere.

Three details from the announcement stand out:

The same runtime backs apps built in Cowork, Code and Copilot Studio.
Microsoft says it is opening it up to third-party and pro-code developers.
It is in preview now and will also be reachable inside Code.

Microsoft has not published, in these posts, what languages, frameworks, deployment model or limits the runtime supports for pro-code use. I could not confirm any of that, so I am not guessing. If you are on a platform team, this is the thing to watch at Ignite (17 to 20 November 2026, San Francisco and online), where Microsoft says more Copilot news is coming.

Autopilot: an agent with its own identity

Autopilot is the always-on piece. You give it a name, a role and a goal, and it watches channels, follows up on threads, runs recurring work and picks projects back up days later without a prompt. Microsoft says it lives in your tenant with "its own identity, memory, computer and workspace", shows up in Teams, Outlook, chats, channels and documents, and works with "permissions, audit and governance behind it".

For anyone who has built integrations, that sentence raises the obvious questions: what scopes does that identity get, who owns it, and how do you review what it did? The announcement does not answer those in detail. Autopilot is in private preview, so this is the moment to ask your Microsoft 365 admins how they plan to handle it, before it becomes another service account nobody remembers creating.

The billing model, in developer terms

Microsoft split Copilot pricing into two parts:

	What it covers	How it is billed
User subscription license (USL)	Chat, Copilot in Word, Excel, PowerPoint, Outlook and Teams, model selection, and Auto	Per user, per month, with fair use limits
Usage-based billing (UBB)	Cowork, Code, Autopilot, long-running agent work, and frontier models	Copilot Credits, on top of the USL

Auto weighs accuracy, speed and cost on each request and routes it to a suitable model. Heavy USL users get a warning first, then a choice to switch to Auto at no extra cost or move to credits.

The guardrail that matters most: Microsoft says that for enterprise customers, UBB services stay off until an admin creates a spending policy in the Microsoft 365 admin center, and nothing is billed before that. Policies can set tenant and group budgets, per-user caps inside group policies and alert thresholds. Microsoft also says spending policies can be managed programmatically through the Microsoft Graph API, and that usage can be mapped to Azure subscriptions or resource groups. The message center notice says UBB begins rolling out in Copilot in Q4 2026.

If you already think in FinOps terms for Azure, this will feel familiar. The new part is that the people generating the spend may be in finance or sales, not engineering.

What I would do as a developer or platform team

None of this needs a migration today. These are low-cost steps that save pain later:

Find out if your tenant is in Frontier, Microsoft's early access program. If it is, Code may already be visible to colleagues.
Talk to IT about the spending policy before it exists. Ask for a pilot group, a per-user cap and alerts rather than a tenant-wide default.
Decide where "citizen-built" apps live. If a Code dashboard becomes business-critical, who owns it, who fixes it, and does it ever move to a real repo?
Treat Autopilot identities like service principals. Ask for least privilege, an owner and an audit trail from day one.
Watch Managed Runtime for pro-code support. If it opens up the way Microsoft suggests, it could become another hosting target inside Microsoft 365, next to the Azure services you already use.

The honest take

Most of this is preview or private preview, and the developer story for Managed Runtime is still thin on details. But the direction is clear. Microsoft wants small internal tools to be built by the people who need them, in Copilot, and run inside the tenant. GitHub Copilot stays the tool for developers, and Code is aimed at everyone else.

For developers, that can be a relief, because fewer tickets come in asking for a quick dashboard. It can also be a headache, because more unreviewed apps end up touching live company data.

Your turn

If your colleagues can describe a dashboard and get a working, shareable app in your Microsoft 365 tenant, does that take load off your team, or create a new pile of shadow IT you will end up maintaining? And if you are in the Frontier program, what has Code built for you so far?

Originally published on WindowsMode.

Your Linux Dev Laptop Can Now Report to Defender: What the Preview Actually Needs

Windows Mode — Wed, 04 Nov 2026 08:03:37 +0000

If your company protects Windows PCs with Microsoft Defender for Endpoint, your Ubuntu or Fedora laptop may soon get the same agent. Microsoft added Linux desktop support in public preview in September 2026, and it uses the same mdatp agent that already runs on Linux servers.

We went through the Microsoft Learn pages and the Microsoft Security announcement to see what that means for developers and the admins who manage their machines. Everything below comes from those sources, and where something is still preview, we say so.

TL;DR

It is a public preview, not general availability.
There is no separate desktop agent. Same packages, same deployment methods, same features as on Linux servers.
Desktops need Defender for Endpoint Plan 2, or Microsoft 365 E5 or E7.
Support depends on the distro and kernel, not on the desktop environment. GNOME, KDE and others are all fine.
Onboarding is one script. Verifying it takes two mdatp commands.

Why developers should care

A developer laptop holds source code, cloud credentials, SSH keys and access to CI/CD. Microsoft's own announcement makes the same point: a compromised workstation is a foothold in the pipelines that build and ship your software. Until now, many security teams could see the Linux servers but not the Linux laptops.

If you are the person who runs Linux at work, this is the change that may land on your machine next. If you are the person who manages those machines, it removes a blind spot.

What you need before you start

Microsoft's prerequisites page lists these requirements:

License: Defender for Endpoint Plan 2, Microsoft 365 E5 or Microsoft 365 E7 for desktops. Servers use a different set of licenses, such as Defender for Servers.
Distro: one on the supported list. Ubuntu LTS 16.04 to 26.04 and Fedora 33 to 44 are listed for x64. RHEL, Debian, SUSE, Oracle Linux, Rocky, AlmaLinux and others are listed too. Anything not listed is unsupported.
Kernel: 3.10.0-327 or later.
Hardware: at least 1 CPU core, 1 GB of RAM and 2 GB of free disk space.
systemd must be your init system.
Network: outbound HTTPS to the Defender endpoints. PAC, WPAD and authenticated proxies are not supported, and neither is SSL inspection.

Defender decides whether a device is a server or a workstation from signals such as OS metadata, licensing details and virtual desktop indicators. If the signals are unclear, the device is classified as a server. After onboarding, check the device inventory to confirm your laptop shows up as a workstation.

Onboarding with the Defender deployment tool

Microsoft recommends the Defender deployment tool for new installs. It installs the agent and onboards the device in one step. Note that the page for this tool is itself labeled preview.

In the Microsoft Defender portal, go to Settings > Endpoints > Device management > Onboarding.
Pick Linux as the operating system.
Under Defender deployment tool, select Download package.

The package is specific to your tenant, so do not reuse it across tenants. Then on the machine:

unzip GatewayLinuxDefenderDeploymentTool.zip
chmod +x defender_deployment_tool.sh
sudo bash defender_deployment_tool.sh

This installs the latest agent from the production channel and onboards the device. Microsoft says it can take 5 to 20 minutes before the device appears in the inventory.

The tool also has a few flags that are worth knowing. All of these are from Microsoft's documentation:

# Check prerequisites without installing
sudo ./defender_deployment_tool.sh --pre-req

# Check that the required URLs are reachable
sudo ./defender_deployment_tool.sh --connectivity-test

# Remove Defender
sudo ./defender_deployment_tool.sh --remove

It also needs outbound access to msdefender.download.prss.microsoft.com on port 443, and either wget or curl installed. Its built-in checks stop the install if memory is under 1 GB, free disk is under 2 GB or glibc is older than 2.17.

Verify it worked

mdatp health --field org_id
mdatp health --field healthy

The first should return your organization ID. The second should return true. Right after the first start, healthy can be false while the agent downloads its first antimalware definitions. That can take a few minutes.

Other deployment routes

If you manage many machines, Microsoft says all existing methods work for desktops. That includes the installer script (mde_installer.sh from Microsoft's public GitHub repo), manual package install with dnf install mdatp on RHEL-family distros, and configuration management tools such as Ansible, Chef, Puppet and SaltStack.

What the agent does

Because it is the same agent, you get the Linux feature set:

Antivirus with real-time and on-demand scans, plus passive mode for running next to another antivirus product.
Endpoint detection and response, with the device timeline and advanced hunting.
Response actions such as live response and device isolation.
Vulnerability management and security settings management.

Antivirus exclusions and settings can be managed centrally from the Defender or Intune portal.

Gotchas worth knowing

Other fanotify-based security tools. Running Defender next to another one is not supported and can cause system hangs. Use passive mode if you must. fapolicyd on RHEL and Fedora is the documented exception.
Device isolation needs iptables and ip6tables, or the nft versions.
Fedora 45 is not on the list yet. The documented range stops at Fedora 44.
Amazon Linux 2 on ARM64 is marked as retiring on 31 October 2026.
It is preview. Microsoft can change it before general availability, so start with a pilot group instead of the whole fleet.

One more thing for WSL users

Microsoft's what's new page also lists a Defender plug-in for WSL containers (WSLc) as generally available. It brings WSL container activity into device inventory, alerts, incidents, the device timeline and advanced hunting. That is a separate feature from Linux desktop support, but it is relevant if you do most of your Linux work inside Windows.

Your turn

If your employer runs Defender on your Linux machine, do you want to know it is there, and what would you want admins to tell developers before it is rolled out? And if you have tried the preview, what broke first?

Originally published on WindowsMode.

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

Microsoft's New Copilot Code Lets Anyone Ship Internal Apps. What Should Developers Do About It?

TL;DR

What Code actually is

Copilot Managed Runtime is the part that matters to devs

Autopilot: an agent with its own identity

The billing model, in developer terms

What I would do as a developer or platform team

The honest take

Your turn

Your Linux Dev Laptop Can Now Report to Defender: What the Preview Actually Needs

TL;DR

Why developers should care

What you need before you start

Onboarding with the Defender deployment tool

Verify it worked

Other deployment routes

What the agent does

Gotchas worth knowing

One more thing for WSL users

Your turn

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 `>`