How I Sandbox AI Coding Agents on Windows 11 with WSL2

I've been using ChatGPT Plus for a few years now and, as of February 2026, it's become a regular part of my workflow for research, writing, and speeding up day-to-day coding. When I first heard Codex was available to me as part of that subscription, I was already leaning hard on ChatGPT Plus to prep for my Azure & DevOps Podcast appearance (I wrote about that prep here). What grabbed my attention was the agentic workflow: give it a goal and let it act on a real codebase.

My first real run was Codex Cloud in June 2025. It got me to a working Eleventy blog fast (this one), but the loop was fundamentally asynchronous: submit task, wait a few minutes, then wait again for CI to spin up a preview in Azure Static Web Apps. That workflow is great for bigger, batched changes, but it felt heavy for the tight inner loop of "try, run, tweak, repeat".

ChatGPT Plus also unlocks Codex tools like the Codex CLI and the Codex IDE extension. This post uses Codex as the concrete example, but the sandboxing approach is the point.

How do you use an AI coding agent locally on Windows 11 with Full Access without taking on unnecessary risk?

Answer: run the whole workflow inside a WSL2 Linux environment and treat that Linux filesystem as the sandbox boundary.

I'm a .NET developer, so the smoke test in this guide is a .NET 10 Web API, but you can swap in whatever stack you use day to day.

Why this guide uses the VS Code Codex extension

I still prefer the CLI for most day-to-day work, but the extension is the simplest way to demonstrate the local sandbox + Full Access workflow end-to-end.

In the IDE, Codex feels like a personal pair programmer instead of a queued job:

• Local code workflows (edit, run, debug in seconds)
• Inline diffs and quick iteration
• Agent logs (useful for learning and understanding decisions)
• Easier to explore new concepts by generating runnable examples

If you're learning or iterating quickly, that tighter feedback loop matters.

Why a sandbox matters (especially for Full Access)

Codex in VS Code has two permission modes:

• Default permissions: Codex automatically runs commands in a sandbox.
• Full Access: can run arbitrary shell commands as your current user, and read/write any file that user can access.

Full Access is powerful enough to:

• Modify files outside the folder you opened in VS Code
• Install packages and tools
• Create background processes
• Delete files (rm -rf, Remove-Item -Recurse, etc.)

Git won't save you from system-level changes. Git is set up per repo at the repo root, not as a magic "version control for your whole machine." If an agent changes something outside your project folder (home directory files, shell profiles, random config files), you won't see it in git status, and undoing it is a lot harder than reverting a commit.

So the goal is not "trust the agent more". It's "make the blast radius small".

Why WSL2 is a good safety boundary on Windows 11

WSL2 gives you a real Linux environment with its own filesystem under:

/home/<user>/...

If you keep your projects in the Linux filesystem and run Codex there, Full Access actions are largely contained to that environment. Under the hood, WSL2 is a lightweight VM with its own Linux kernel and its own disk image. In practice that means:

• Linux tools run as Linux tools, not Windows shims
• Your repo lives on an ext4 filesystem (inside the distro), not on NTFS
• Most of the time, the agent is only touching Linux paths unless you explicitly point it somewhere else

Important caveat: WSL can also access your Windows filesystem. If you open or work on a repo that lives on the Windows side, you weaken the sandbox boundary. For the cleanest separation, keep the project under your Linux home directory (/home/<user>/...).

Beyond safety, WSL2 is also a great .NET dev target:

• Run and debug ASP.NET Core apps inside Linux
• Build/compile in a Linux environment (closer to many production targets)
• Use the integrated VS Code terminal inside WSL
• Install VS Code extensions into WSL so they run where your code runs

Setup: WSL2 + Ubuntu + VS Code + Codex (example: .NET 10)

This is the follow-along recipe that got me from "Windows machine" to "safe Codex Full Access sandbox".

1) Install WSL2 + Ubuntu

From PowerShell:

wsl --install -d Ubuntu-24.04

If Ubuntu-24.04 isn't available on your machine, run wsl --list --online and pick an Ubuntu distro from the list.

Launch Ubuntu and create a Linux username + password when prompted.

2) Install Git inside WSL

Git is a baseline dependency for basically any dev workflow, so I install it immediately in a fresh WSL distro.

sudo apt update
sudo apt install -y git

3) Install .NET 10 in Ubuntu 24.04

If sudo apt install dotnet-sdk-10.0 works for your setup, prefer that. I used the install script here because I could not get .NET 10 from my default Ubuntu feeds at the time.

At the time of this setup, .NET 10 wasn't available to me via the default Ubuntu repos on 24.04, so I used Microsoft's dotnet-install.sh script.

wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh
chmod +x dotnet-install.sh
./dotnet-install.sh --channel 10.0

Verify the SDK was installed:

~/.dotnet/dotnet --version

4) Add .NET to your PATH (so tools can find it)

When you install via dotnet-install.sh, the SDK goes into ~/.dotnet, which is not on PATH by default. If you skip this, things like dotnet new, dotnet run, and IDE tooling won't reliably find the SDK.

echo 'export PATH="$HOME/.dotnet:$PATH"' >> ~/.bashrc
echo 'export DOTNET_ROOT="$HOME/.dotnet"' >> ~/.bashrc
source ~/.bashrc
dotnet --version

If you installed .NET via a system package, this step is often unnecessary because dotnet is already on PATH (often under /usr/bin).

5) Create a dedicated Codex sandbox folder (Linux filesystem)

mkdir -p ~/codex-sandbox
cd ~/codex-sandbox

This matters. Keep AI-driven work here.

6) Open VS Code in WSL mode

From the same directory:

code .

In VS Code, confirm the status bar shows WSL: Ubuntu-24.04 (or whatever Ubuntu distro name you installed).

7) Install the required extensions in WSL

Install the Codex extension (OpenAI) and C# Dev Kit into the WSL environment (VS Code will prompt you to "Install in WSL").

8) Sign in and open the Codex chat

Open the Codex chat panel and sign in with ChatGPT.

9) Enable Full Access mode

After signing in, switch the mode to Full Access.

When Full Access is enabled, Codex can run shell commands and modify files inside your WSL environment. Because your workspace lives inside Linux, that power is contained within your sandbox instead of your Windows system.

Sanity check: run a .NET 10 app inside WSL

Now that Codex is installed and Full Access is enabled, put it to work and verify your WSL environment can create and run an ASP.NET Core (.NET 10) workload end-to-end.

In the Codex chat, ask it to create a new Web API and run it. For example:

Create a new .NET 10 Web API named TestApi10 in this workspace.
Run it.

After it starts, tell me:
- which localhost URL to open from Windows
- which endpoint should return JSON

If you'd rather run it yourself, these are the commands it will typically use:

dotnet new webapi -n TestApi10
cd TestApi10
dotnet run

You'll see output like:

Now listening on: http://localhost:<port>

Open it from Windows. On Windows 11, WSL2 typically forwards localhost ports automatically. If it opens as 127.0.0.1 (or VS Code opens the link via its remote port-forwarding plumbing instead of using the literal hostname shown), that's normal.

One gotcha: the root path / may return 404 depending on the template. The default endpoint is often:

http://localhost:<port>/weatherforecast

At this point, with Full Access enabled, Codex can safely generate projects, refactor code, run commands, and fix build errors inside your sandbox.

Daily workflow: open VS Code directly in your sandbox

From your Windows host machine, you can open VS Code directly into your WSL sandbox with this one-liner:

wsl -d Ubuntu-24.04 --cd ~/codex-sandbox -- code .

This command:

• Starts the distro
• Changes to your project folder
• Opens VS Code in WSL mode

Guardrails I recommend (so Full Access stays boring)

• Keep repos in ~/codex-sandbox/....
• Before enabling Full Access, confirm VS Code shows WSL: Ubuntu-24.04 (or whatever Ubuntu distro name you installed).

Closing thoughts

Codex is at its best when you let it do real work: generate code, run builds, fix errors, and iterate. The trick is doing that safely. For me, WSL2 is the simplest way to safely turn on "Full Access" without putting my Windows environment at risk. Once that boundary is in place, it becomes a legitimate learning lab for .NET 10 and anything else I want to explore.

Technically, what's happening is straightforward: WSL2 gives you a Linux VM with its own filesystem and process space; VS Code connects to it via Remote - WSL; and extensions like Codex run in that Linux context. By keeping your workspace in /home/<user>/... (the Linux filesystem), you get the practical benefits of a sandbox without having to containerize everything.

This WSL sandbox setup is the foundation that made me comfortable actually using Full Access day-to-day.