What does Windows-native mean for Codex?

It means the Codex app can run the agent natively on Windows using PowerShell and the native Windows sandbox instead of forcing the agent to run inside WSL2. WSL2 is still available when your workflow needs Linux-native tooling.

Is Codex safe to run on a Windows PC?

Codex is designed to use sandboxing and approvals by default, but no local agent should be treated as risk-free. Keep default permissions, avoid full access unless you understand the risk, and review destructive or system-level actions.

What does the Codex Windows sandbox do?

OpenAI says the native Windows sandbox blocks filesystem writes outside the working folder and prevents network access without explicit approval. The elevated sandbox uses dedicated lower-privilege sandbox users, filesystem permission boundaries, firewall rules, and local policy changes.

Should I let Codex clean Windows bloatware or change update settings?

Only with caution. Use Codex to audit, draft a plan, and explain changes first. For registry edits, update policy changes, service changes, or bloatware removal, create a restore point or backup and approve each risky action deliberately.

Can Codex build a Hyper-V security lab?

The video demonstrates a local Hyper-V lab with Kali and Ubuntu. That kind of workflow should stay local, authorized, and defensive. Do not use agent-built security tooling against systems you do not own or have permission to test.

Codex on Windows Is Native Now: PowerShell, Sandboxes, and Safer PC Agents

The most interesting part of Codex on Windows is not that OpenAI shipped another desktop app. It is that Codex is no longer visiting Windows through a Linux side door.

The Windows app can run the agent natively in PowerShell, use Windows-native sandboxing, and still give you modern Codex surfaces: parallel agent threads, worktrees, automations, Git functionality, an in-app browser, artifact previews, plugins, and skills.

That changes the conversation for Windows users. If the agent lives in PowerShell, understands Windows paths, sees the filesystem the way you do, can use `winget`, can work with Hyper-V, and is constrained by Windows security primitives, then Windows starts to look less like the awkward platform for AI tooling and more like a serious local agent workstation again.

Video source: Codex on Windows, PowerShell, sandbox users, ACLs, firewall rules, bloatware cleanup, Hyper-V, and the question of whether Windows-native agents make the PC interesting again.

Source note

The video is sponsored commentary and a hands-on demo. The factual spine of this post comes from OpenAI's Codex Windows docs, OpenAI's engineering post on the Windows sandbox, and the Codex sandboxing and approvals documentation.

The video says OpenAI built the sandbox in more than 15,000 lines of Rust. I could not verify the exact line count or language from the official pages I checked. The official, source-backed claim is still strong: OpenAI says Windows did not provide one out-of-the-box primitive that matched a safe autonomous coding agent, so the Codex team implemented its own Windows sandbox using a composition of Windows security tools.

The featured power user in the video is Peter Steinberger, who is now at OpenAI.

Why Windows-native matters

Windows users have had AI tooling, but often with a catch. Run it in WSL2. Pretend the Windows filesystem is a Linux project. Lose some integration. Accept that many agent tools were designed around macOS and Linux first.

WSL2 is excellent when your work is Linux-native. But if your real job is Windows administration, .NET, Active Directory, PowerShell, Hyper-V, Visual Studio, Windows services, enterprise desktops, or a weird vendor application that only runs on Windows, WSL is not your home. It is a neighboring apartment.

Mode	Best for	Tradeoff
Windows-native Codex	PowerShell, Windows paths, Windows tools, local app workflows, enterprise PC work	Needs Windows sandbox setup and careful permissions
WSL2 Codex	Linux-native repos, Linux package managers, Unix shells, server-style workflows	Less direct Windows integration
Full access	Rare cases where you intentionally want no sandbox boundary	High risk of destructive actions and data loss

OpenAI's Windows docs say the Codex app uses the Windows-native agent by default, meaning commands run in PowerShell. You can still configure WSL2, but Windows-native is the important default shift.

For a Windows sysadmin, that matters. An agent that lives in PowerShell can reason inside the same command surface used for system inventory, logs, services, packages, Hyper-V, permissions, and enterprise scripts.

The sandbox is the story

Letting an AI agent run local commands on your PC is useful and terrifying for the same reason: it can act.

OpenAI's docs define the sandbox as the boundary that lets Codex act autonomously without giving it unrestricted access to your machine. The sandbox decides what Codex can do technically, while approvals decide when it must stop and ask before crossing a boundary.

On Windows, the native sandbox is especially interesting because Windows did not hand OpenAI one perfect tool. OpenAI's engineering write-up says the team evaluated AppContainer, Windows Sandbox, and Mandatory Integrity Control labels, but each missed the shape of the problem.

The final design uses Windows building blocks instead:

SIDs: security identifiers that can appear in ACLs and give the sandbox an identity.
ACLs: filesystem permission boundaries that define where the sandbox can read, write, execute, or delete.
Restricted tokens: process tokens that narrow what spawned commands can modify.
Dedicated sandbox users: OpenAI describes `CodexSandboxOffline` and `CodexSandboxOnline` in the elevated design.
Windows Firewall rules: used to block outbound access for the offline sandbox user.
Setup and runner binaries: `codex-windows-sandbox-setup.exe` for elevated setup work and `codex-command-runner.exe` for restricted command execution.

OpenAI's Windows docs simplify the practical version: when Codex runs natively on Windows, agent mode uses a Windows sandbox to block filesystem writes outside the working folder and prevent network access without explicit approval.

That does not mean "nothing can go wrong." It means the agent has a real OS-level boundary, and that boundary is visible enough for a serious user to reason about.

What the video demonstrated

1. PowerShell as the default command language

The video starts with a simple task: count files in a directory. Codex runs PowerShell. That sounds small until you remember how much Windows automation already lives there.

For Windows people, PowerShell is not just a shell. It is the management plane.

2. Sandbox users and ACLs are visible

The demo uses `icacls` to inspect folder permissions and shows Codex sandbox identities appearing around the project folder. The official OpenAI write-up explains why: the sandbox uses SIDs and ACLs so the agent can write where it is supposed to write without being able to casually modify everything else.

That is the sane pattern for local agents: broad enough to do useful work, narrow enough to avoid accidental system-wide damage.

3. Network access is blocked by default

In the video, a `curl` request fails until permission is granted. This aligns with OpenAI's approvals and security docs: local Codex defaults include no network access, and Codex asks for approval to run commands that need the network.

For agent safety, this is huge. A local command can do damage, but a local command with network access can also exfiltrate data or pull in untrusted code. Default-off network access is the right posture.

4. Cleanup tasks can be useful, but need review

The video shows Codex cleaning a Downloads folder, organizing a desktop, stripping Windows distractions, and trying to stop Windows Update from reversing changes.

This is where I get cautious. Cleaning obvious trash inside a folder is one thing. Changing Windows Update behavior, registry settings, startup policies, services, or security configuration is another.

The right workflow is:

Ask Codex to audit first.
Ask for a plain-English plan.
Ask which changes are reversible.
Create a restore point or backup.
Approve risky changes one by one.
Keep a log of every command it ran.

5. Hyper-V labs are a great use case if they stay local

The video also asks Codex to spin up a Hyper-V hacking lab with Kali Linux and Ubuntu. Microsoft documents Hyper-V as an optional Windows feature for creating and running virtual machines, and it can be useful for security learning.

The caveat is not optional: keep it authorized, local, and defensive. A lab for learning, testing intentionally vulnerable apps, or practicing internal defensive workflows is legitimate. Pointing agent-generated security tooling at real third-party systems is not.

6. Automations make PC maintenance tempting

Codex automations are also part of the story. The video uses an automation to keep checking whether Windows changes are being reversed. That is powerful, but it should be treated like scheduled infrastructure, not a casual chat.

Any recurring Windows automation should have:

a narrow scope;
a log file;
a dry-run mode when possible;
a stop condition;
a human-readable summary;
a rollback plan.

A safer setup checklist

If you want to try Codex on Windows, I would not start by saying "clean my PC" or "fix Windows Update." Start smaller.

Use Windows 11 if possible. OpenAI docs recommend Windows 11 as the best baseline. Recent Windows 10 is best effort.
Install via Microsoft Store or `winget`. OpenAI documents `winget install Codex -s msstore` as the command-line install path.
Keep default permissions first. Full access removes important boundaries and can lead to data loss.
Use the elevated Windows sandbox when available. OpenAI says `elevated` is the preferred native Windows sandbox, with `unelevated` as fallback.
Put work in a dedicated folder. Treat the project folder as the agent's workbench.
Use read-only mode for inspection. Let Codex inspect before it edits.
Approve network access deliberately. Do not let agent-spawned commands access the internet by habit.
Use rules for specific exceptions. Prefer targeted rules over broad access.
Log risky changes. If it touches registry, policies, services, startup items, security settings, or Hyper-V networking, keep a record.
Do not disable updates blindly. Windows Update is annoying, but it is also part of your security posture.

A good first prompt:

I want to use Codex safely on this Windows machine.
First, inspect this project folder only.
Do not change system settings.
Do not use the network.
Explain what you can safely do inside this folder,
what would require approval, and what I should not automate.

A good second prompt:

Audit my Downloads folder and propose a cleanup plan.
Do not delete anything yet.
Group files into: safe to remove, needs review, keep.
Explain your reasoning and wait for approval.

Who should care

This is not only for people who like tweaking Windows.

Windows sysadmins: Codex can become a PowerShell-native assistant for scripts, logs, inventory, policies, and documentation.
.NET and Windows developers: the agent can work closer to your real toolchain instead of through Linux assumptions.
Security learners: local Hyper-V labs and intentionally vulnerable apps become easier to scaffold, with the usual authorization caveats.
Technical operators: repeatable PC maintenance, cleanup, reporting, and app setup can become documented workflows.
Small businesses: a Windows office full of messy folders, exports, reports, and admin tasks can use agent workflows without moving everything to a different OS.

The bigger pattern is the same one I keep coming back to on JQ AI SYSTEMS: the agent only becomes useful when the workflow has boundaries. Codex on Windows is exciting because OpenAI is taking those boundaries seriously at the OS level.

CTA: Do not give an AI full access to your PC because it feels smart. Give it a workspace, default permissions, narrow tasks, logs, and explicit approvals.

Sources

Windows-native agents are not automatically safe. But they are becoming real. The question is no longer whether AI can run on your PC. The question is whether you have the boundaries to let it help.