Help test experimental Windows sandbox

[ae-openai]

Hi folks, we have more Windows improvements coming your way, and we'd love help testing.

If you use the CLI on native windows, you can enable a highly experimental filesystem and network sandbox. Once it's stable, Codex agent mode will run more securely and safely, with far fewer approvals.

The current biggest caveat is that does not prevent file writes, deletions, or creations in any directory where the Everyone SID already has write permissions (for example, world-writable folders).

Various commands that you'd expect to succeed may fail, and we'd love your help identifying those and any other rough edges.

Run in PowerShell with

codex `
--enable enable_experimental_windows_sandbox `
--sandbox workspace-write `
--ask-for-approval on-request

Docs (minimal so far) here: https://github.com/openai/codex/blob/main/docs/sandbox.md#platform-sandboxing-details

Happy testing and thank you!

[dusancv22]

I'm getting this conda.exe - application error each time codex tries to call the command I'm guessing.
"The application was unable to start correctly (0x0000142) Click OK to close the application."
Running on Windows 10 64bit.

[iceweasel-oai]

hey @dusancv22 are you still seeing this? If so, can you type /feedback in the CLI and send it over to us so we can diagnose? Thanks!

[dusancv22]

Yeah, now, that error is gone in 0.55 version, but now I just realized that it doesn't want to edit the files on its own.
It just gives me the code for me to manually modify it.
I used /feedback to report it:
ID 019a5e34-2bbe-78c3-b280-3808d95398fc

EDIT:
The tool calling is working, but it's still going through PowerShell, not sure if that should be different or not.

[wbdb]

I think participation would be greater if the documentation also described how to configure it:

https://developers.openai.com/codex/windows#windows-experimental-sandbox

config.toml

approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[features]
elevated_windows_sandbox = true

[Janksuu]

[Windows] Sandbox field report (runtime + source verification, codex-cli 0.101.0)
Verified against public openai/codex main at commit 021e39b on 2026-02-20.

Environment
OS: Windows 11 Pro, DisplayVersion 25H2
Codex CLI: codex-cli 0.101.0
Test scope: CLI runtime checks + public source verification only
Runtime observations (local)

1. Windows sandbox command path works:

codex sandbox windows --full-auto -- cmd /c echo SANDBOX_OK
Exact output:

SANDBOX_OK
2) Current feature listing on this install:

experimental_windows_sandbox removed false
elevated_windows_sandbox removed false

Public source checkpoints

1. Feature flags are marked removed:
   experimental_windows_sandbox / elevated_windows_sandbox
   

   codex/codex-rs/core/src/features.rs

   Lines 538 to 547 in 021e39b

   	id: Feature::WindowsSandbox,
   	key: "experimental_windows_sandbox",
   	stage: Stage::Removed,
   	default_enabled: false,
   	},
   	FeatureSpec {
   	id: Feature::WindowsSandboxElevated,
   	key: "elevated_windows_sandbox",
   	stage: Stage::Removed,
   	default_enabled: false,

2. Current config model uses windows.sandbox with Elevated / Unelevated:
   WindowsSandboxModeToml

   codex/codex-rs/core/src/config/types.rs

   Lines 33 to 41 in 021e39b

   	pub enum WindowsSandboxModeToml {
   	Elevated,
   	Unelevated,
   	}
   	#[derive(Serialize, Deserialize, Debug, Clone, Default, PartialEq, Eq, JsonSchema)]
   	#[schemars(deny_unknown_fields)]
   	pub struct WindowsToml {
   	pub sandbox: Option<WindowsSandboxModeToml>,

   
   Mapping to runtime level in WindowsSandboxLevel::from_config

   codex/codex-rs/core/src/windows_sandbox.rs

   Lines 31 to 47 in 021e39b

   	fn from_config(config: &Config) -> WindowsSandboxLevel {
   	match config.permissions.windows_sandbox_mode {
   	Some(WindowsSandboxModeToml::Elevated) => WindowsSandboxLevel::Elevated,
   	Some(WindowsSandboxModeToml::Unelevated) => WindowsSandboxLevel::RestrictedToken,
   	None => Self::from_features(&config.features),
   	}
   	}
   	fn from_features(features: &Features) -> WindowsSandboxLevel {
   	if features.enabled(Feature::WindowsSandboxElevated) {
   	return WindowsSandboxLevel::Elevated;
   	}
   	if features.enabled(Feature::WindowsSandbox) {
   	WindowsSandboxLevel::RestrictedToken
   	} else {
   	WindowsSandboxLevel::Disabled
   	}

3. App-server persists windows.sandbox overrides in multiple flows:
   

   codex/codex-rs/app-server/src/codex_message_processor.rs

   Lines 1862 to 1879 in 021e39b

   	// Persist Windows sandbox mode.
   	// TODO: persist default config in general.
   	let mut request_overrides = request_overrides.unwrap_or_default();
   	if cfg!(windows) {
   	match WindowsSandboxLevel::from_config(&self.config) {
   	WindowsSandboxLevel::Elevated => {
   	request_overrides
   	.insert("windows.sandbox".to_string(), serde_json::json!("elevated"));
   	}
   	WindowsSandboxLevel::RestrictedToken => {
   	request_overrides.insert(
   	"windows.sandbox".to_string(),
   	serde_json::json!("unelevated"),
   	);
   	}
   	WindowsSandboxLevel::Disabled => {}
   	}
   	}

   
   

   codex/codex-rs/app-server/src/codex_message_processor.rs

   Lines 3286 to 3301 in 021e39b

   	// Persist Windows sandbox mode.
   	let mut cli_overrides = cli_overrides.unwrap_or_default();
   	if cfg!(windows) {
   	match WindowsSandboxLevel::from_config(&self.config) {
   	WindowsSandboxLevel::Elevated => {
   	cli_overrides
   	.insert("windows.sandbox".to_string(), serde_json::json!("elevated"));
   	}
   	WindowsSandboxLevel::RestrictedToken => {
   	cli_overrides.insert(
   	"windows.sandbox".to_string(),
   	serde_json::json!("unelevated"),
   	);
   	}
   	WindowsSandboxLevel::Disabled => {}
   	}

   
   

   codex/codex-rs/app-server/src/codex_message_processor.rs

   Lines 4248 to 4264 in 021e39b

   	// Persist Windows sandbox mode.
   	let mut request_overrides = request_overrides.unwrap_or_default();
   	if cfg!(windows) {
   	match WindowsSandboxLevel::from_config(&self.config) {
   	WindowsSandboxLevel::Elevated => {
   	request_overrides.insert(
   	"windows.sandbox".to_string(),
   	serde_json::json!("elevated"),
   	);
   	}
   	WindowsSandboxLevel::RestrictedToken => {
   	request_overrides.insert(
   	"windows.sandbox".to_string(),
   	serde_json::json!("unelevated"),
   	);
   	}
   	WindowsSandboxLevel::Disabled => {}

   
   

   codex/codex-rs/app-server/src/codex_message_processor.rs

   Lines 4438 to 4454 in 021e39b

   	// Persist Windows sandbox mode.
   	let mut cli_overrides = cli_overrides.unwrap_or_default();
   	if cfg!(windows) {
   	match WindowsSandboxLevel::from_config(&self.config) {
   	WindowsSandboxLevel::Elevated => {
   	cli_overrides.insert(
   	"windows.sandbox".to_string(),
   	serde_json::json!("elevated"),
   	);
   	}
   	WindowsSandboxLevel::RestrictedToken => {
   	cli_overrides.insert(
   	"windows.sandbox".to_string(),
   	serde_json::json!("unelevated"),
   	);
   	}
   	WindowsSandboxLevel::Disabled => {}

4. Elevated setup/reporting surfaces are present:
   setup_error.json path/reporting

   codex/codex-rs/windows-sandbox-rs/src/setup_error.rs

   Lines 150 to 151 in 021e39b

   	pub fn setup_error_path(codex_home: &Path) -> PathBuf {
   	codex_home.join(".sandbox").join("setup_error.json")

   
   Sandbox users group (CodexSandboxUsers) and provisioning flow

   codex/codex-rs/windows-sandbox-rs/src/sandbox_users.rs

   Line 46 in 021e39b

   pub const SANDBOX_USERS_GROUP: &str = "CodexSandboxUsers";

   codex/codex-rs/windows-sandbox-rs/src/sandbox_users.rs

   Lines 64 to 76 in 021e39b

   	offline_username: &str,
   	online_username: &str,
   	log: &mut File,
   	) -> Result<()> {
   	ensure_sandbox_users_group(log)?;
   	super::log_line(
   	log,
   	&format!("ensuring sandbox users offline={offline_username} online={online_username}"),
   	)?;
   	let offline_password = random_password();
   	let online_password = random_password();
   	ensure_sandbox_user(offline_username, &offline_password, log)?;
   	ensure_sandbox_user(online_username, &online_password, log)?;

5. Two TODOs still in active Windows path:
   Runner invocation mechanism TODO

   codex/codex-rs/windows-sandbox-rs/src/elevated_impl.rs

   Line 295 in 021e39b

   // TODO(iceweasel) - use a different mechanism for invoking the runner.

   
   ExecExpiration support TODO in Windows capture path

   codex/codex-rs/core/src/exec.rs

   Lines 356 to 358 in 021e39b

   	// TODO(iceweasel-oai): run_windows_sandbox_capture should support all
   	// variants of ExecExpiration, not just timeout.
   	let timeout_ms = expiration.timeout_ms();

   
   Practical takeaway
   From this external view: core Windows sandbox architecture appears implemented, and current bottleneck looks like rollout/hardening confidence rather than missing foundations.

[laffo16]

Having a tough time reasoning about Windows sandboxing and I think approval_policy naming is part of it.

I initially read 'approval_policy = "never"' as "auto-deny / block anything that would need approval".
But it actually means "never prompt" (best-effort run within whatever sandbox constraints are in effect).

Could you consider:

• Renaming / aliasing 'never' to something clearer like 'skip' / 'ignore' / 'no-prompts', and/or
• Adding an explicit 'auto-deny' mode that refuses anything that would trigger an approval prompt (no prompts)?

-- Update

What I eventually found is that this wasn’t an approval_policy = "never" issue at all - it was [features].unified_exec.

I was running with:

• sandbox_mode = "workspace-write" (so writes should be limited to the workspace / writable roots)
• [windows] sandbox = "elevated" (Windows sandbox pipeline enabled)
• approval_policy = "never" (no prompts)

Yet I could still write to C:\temp\Test\..., which is outside the workspace (with shell_tool: exec_command). First I sanity-checked the obvious: the directory ACLs weren’t “wide open” - C:\temp\Test was writable by normal users (e.g. Authenticated Users / my user), and importantly it was not relying on an Everyone:(M) permission edge-case.

Then the key clue: the process identity. When I did a whoami inside the tool call that created the file, it ran as my normal login (domain\login), not the expected Windows sandbox identity (e.g. domain\codexsandboxonline / ...offline). That meant the command wasn’t actually being executed under the Windows sandboxed token, so it wasn’t surprising that writes to C:\temp\Test succeeded.

After disabling unified_exec and restarting, the behavior changed immediately: whoami became the Codex sandboxed account, and attempts to write C:\temp\Test\... started failing with “Access is denied” (which is what I originally expected from workspace-write).

So the underlying issue here was my configuration mistake: I had enabled [features].unified_exec = true, and on Windows that can cause exec_command / command execution to bypass the Windows sandboxed identity (at least in the version I tested), effectively breaking the guarantees I assumed I had from sandbox_mode = "workspace-write" + [windows] sandbox = "elevated".

Takeaway / warning for others: if you care about Windows sandboxing semantics, be very cautious enabling unified_exec - verify with a simple whoami + “write outside workspace” test after enabling it, because it can change which Windows token / user your commands actually run under.