Windows: unified_exec PTY path bypasses Windows sandbox and can run unsandboxed despite workspace-write + network_access = false

[Azreal42]

What version of Codex CLI is running?

codex-cli 0.114.0

What subscription do you have?

business

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal

What issue are you seeing?

On Windows, when unified_exec is enabled and the session uses exec_command, commands can run outside the Windows sandbox even when the session is configured with:

• sandbox_mode = "workspace-write"
• [sandbox_workspace_write] network_access = false
• [windows] sandbox = "elevated"

This is not just a status/UI issue. In practice, commands can execute as the normal user and reach the network.
(and according to documentation the feature is considered stable even if not activated by default on windows)

What steps can reproduce the bug?

Config:

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

[windows]
sandbox = "elevated"

[sandbox_workspace_write]
network_access = false

[features]
unified_exec = true

Steps:

1. Start a fresh Codex TUI session on Windows.
2. Ask Codex to run a command via the normal shell tool path, for example:
   • curl.exe https://developers.openai.com/codex/config-reference/
   • or whoami
3. Observe the result.

What is the expected behavior?

When sandboxing is active on Windows with network disabled:

• the command should run as the sandbox user, e.g. CodexSandboxOffline
• network access should be blocked

Additional information

Actual

Observed during investigation:

• the rollout shows the tool call is exec_command
• whoami returns the normal user account instead of CodexSandboxOffline
• ~/.codex/.sandbox/sandbox.log does not get a fresh entry
• networked commands can succeed unexpectedly

Root cause

The Windows sandbox is applied in the classic exec path, but not in the unified exec PTY spawn path.

Relevant code:

• Tool selection prefers unified exec when enabled:
  • codex-rs/core/src/tools/spec.rs
• Unified exec builds sandbox metadata, but then spawns directly via PTY:
  • codex-rs/core/src/tools/runtimes/unified_exec.rs
  • codex-rs/core/src/unified_exec/process_manager.rs
• The PTY path on Windows ends up calling plain CreateProcessW:
  • codex-rs/utils/pty/src/win/psuedocon.rs
• The actual Windows sandbox runner is only used in the classic exec path:
  • codex-rs/core/src/exec.rs

In other words, unified exec appears to compute the right sandbox intent, but does not enforce it on Windows.

Suggested fixes

One of:

1. Route Windows unified exec through the Windows sandbox runner.
2. If that is not supported for PTY sessions yet, hard-refuse unified exec on Windows whenever a sandbox is required.

Notes

This is a security/safety issue, not only a UX issue, because the configured sandbox policy can appear active while the actual process runs outside it.