mirror of https://github.com/openai/codex.git synced 2026-05-29 23:40:29 +00:00

Files

Michael Bolin 986c60467b windows-sandbox: pass workspace roots to runner (#24108 )

## Why

#23813 switches the Windows sandbox runner path to `PermissionProfile`,
but it still left one runtime anchor for resolving symbolic
`:workspace_roots` entries. That is not enough once a turn has multiple
effective workspace roots: exact entries and deny globs under
`:workspace_roots` need to be materialized for every runtime root before
the command runner chooses token mode or builds ACL plans.

## What Changed

- Replaces the Windows runner/setup `permission_profile_cwd` plumbing
with `workspace_roots: Vec<AbsolutePathBuf>`.
- Resolves Windows-local `PermissionProfile` data with
`materialize_project_roots_with_workspace_roots(...)` instead of the
single-cwd helper.
- Threads `Config::effective_workspace_roots()` through core execution,
unified exec, TUI setup/read-grant flows, app-server setup, app-server
`command/exec`, and `debug sandbox` on Windows.
- Preserves those workspace roots through the zsh-fork escalation
executor instead of rebuilding them from `sandbox_policy_cwd`.
- Makes `ExecRequest::new(...)` and the remaining
`build_exec_request(...)` helper path take
`windows_sandbox_workspace_roots` explicitly so new call sites cannot
silently fall back to `vec![cwd]`.
- Clarifies the `debug sandbox` non-Windows comment: remaining
cwd-dependent resolution still uses `sandbox_policy_cwd`, while
`:workspace_roots` entries are already materialized from config roots.
- Updates elevated runner IPC `SpawnRequest` to send `workspace_roots`
and bumps the framed IPC protocol version to `3` for the payload shape
change.
- Adds Windows-local resolver coverage for expanding exact and glob
`:workspace_roots` entries across multiple roots, plus core helper
coverage proving explicit roots are preserved.

## Verification

- `cargo check -p codex-windows-sandbox -p codex-core -p codex-tui -p
codex-cli -p codex-app-server`
- `cargo test -p codex-windows-sandbox`
- `cargo test -p codex-core windows_sandbox`
- `cargo test -p codex-core unix_escalation`
- `cargo test -p codex-app-server windows_sandbox`
- `cargo test -p codex-tui windows_sandbox`
- `cargo test -p codex-cli debug_sandbox`
- `just test -p codex-core unified_exec`
- `just test -p codex-core
build_exec_request_preserves_windows_workspace_roots`
- `env -u CODEX_NETWORK_PROXY_ACTIVE -u
CODEX_NETWORK_ALLOW_LOCAL_BINDING just test -p codex-app-server --lib
command_exec`
- `just test -p codex-windows-sandbox`
- `just test -p codex-exec sandbox`
- `just fix -p codex-core -p codex-app-server -p codex-windows-sandbox`

A local macOS cross-check with `cargo check --target
x86_64-pc-windows-msvc ...` did not reach crate Rust code because native
dependencies require Windows SDK headers (`windows.h` / `assert.h`) in
this environment; Windows CI remains the real target validation.

Two local targeted filters compile but do not run assertions on macOS:
`env -u CODEX_NETWORK_PROXY_ACTIVE -u CODEX_NETWORK_ALLOW_LOCAL_BINDING
just test -p codex-app-server --lib command_exec_processor` matched zero
tests, and `just test -p codex-linux-sandbox landlock` matched zero
tests because the landlock suite is Linux-only.

2026-05-28 15:26:55 -07:00

src

runtime: use install context for bundled bwrap (#23634 )

2026-05-20 08:24:43 -07:00

tests

windows-sandbox: pass workspace roots to runner (#24108 )

2026-05-28 15:26:55 -07:00

BUILD.bazel

linux-sandbox: use standalone bundled bwrap (#21255 )

2026-05-05 17:14:29 -07:00

build.rs

linux-sandbox: use standalone bundled bwrap (#21255 )

2026-05-05 17:14:29 -07:00

Cargo.toml

runtime: use install context for bundled bwrap (#23634 )

2026-05-20 08:24:43 -07:00

README.md

cli: infer host sandbox backend (#24102 )

2026-05-22 10:23:59 -07:00

README.md

codex-linux-sandbox

This crate is responsible for producing:

a codex-linux-sandbox standalone executable for Linux that is bundled with the Node.js version of the Codex CLI
a lib crate that exposes the business logic of the executable as run_main() so that
- the codex-exec CLI can check if its arg0 is codex-linux-sandbox and, if so, execute as if it were codex-linux-sandbox
- this should also be true of the codex multitool CLI

On Linux, Codex prefers the first bwrap found on PATH outside the current working directory whenever it is available. If bwrap is present but too old to support --argv0, the helper keeps using system bubblewrap and switches to a no---argv0 compatibility path for the inner re-exec. If bwrap is missing, the helper falls back to the bundled codex-resources/bwrap binary shipped with Codex. Codex also surfaces a startup warning when bwrap is missing so users know it is falling back to the bundled helper. Codex surfaces the same startup warning path when bubblewrap cannot create user namespaces. WSL2 follows the normal Linux bubblewrap path. WSL1 is not supported for bubblewrap sandboxing because it cannot create the required user namespaces, so Codex rejects sandboxed shell commands that would enter the bubblewrap path.

Current Behavior

Legacy SandboxPolicy / sandbox_mode configs remain supported.
Bubblewrap is the default filesystem sandbox.
If bwrap is present on PATH outside the current working directory, the helper uses it.
If bwrap is present but too old to support --argv0, the helper uses a no---argv0 compatibility path for the inner re-exec.
If bwrap is missing, the helper falls back to the bundled codex-resources/bwrap path.
If bwrap is missing, Codex also surfaces a startup warning instead of printing directly from the sandbox helper.
If bubblewrap cannot create user namespaces, Codex surfaces a startup warning instead of waiting for a runtime sandbox failure.
WSL2 uses the normal Linux bubblewrap path.
WSL1 is not supported for bubblewrap sandboxing; Codex rejects sandboxed shell commands that would require the bubblewrap path before invoking bwrap.
Legacy Landlock + mount protections remain available as an explicit legacy fallback path.
Set features.use_legacy_landlock = true (or CLI -c use_legacy_landlock=true) to force the legacy Landlock fallback.
The legacy Landlock fallback is used only when the split filesystem policy is sandbox-equivalent to the legacy model after cwd resolution.
Split-only filesystem policies that do not round-trip through the legacy SandboxPolicy model stay on bubblewrap so nested read-only or denied carveouts are preserved.
When bubblewrap is active, the helper applies PR_SET_NO_NEW_PRIVS and a seccomp network filter in-process.
When bubblewrap is active, the filesystem is read-only by default via --ro-bind / /.
When bubblewrap is active, writable roots are layered with --bind <root> <root>.
When bubblewrap is active, protected subpaths under writable roots (for example .git, resolved gitdir:, and .codex) are re-applied as read-only via --ro-bind.
When bubblewrap is active, overlapping split-policy entries are applied in path-specificity order so narrower writable children can reopen broader read-only or denied parents while narrower denied subpaths still win. For example, /repo = write, /repo/a = none, /repo/a/b = write keeps /repo writable, denies /repo/a, and reopens /repo/a/b as writable again.

When bubblewrap is active, unreadable glob entries are expanded before launching the sandbox and matching files are masked in bubblewrap:

Prefer:   rg --files --hidden --no-ignore --glob <pattern> -- <search-root>
Fallback: internal globset walker when rg is not installed
Failure:  any other rg failure aborts sandbox construction

Users can cap the scan depth per permissions profile:

[permissions.workspace.filesystem]
glob_scan_max_depth = 2

[permissions.workspace.filesystem.":workspace_roots"]
"**/*.env" = "none"

When bubblewrap is active, symlink-in-path and non-existent protected paths inside writable roots are blocked by mounting /dev/null on the symlink or first missing component.
When bubblewrap is active, the helper explicitly isolates the user namespace via --unshare-user and the PID namespace via --unshare-pid.
When bubblewrap is active and network is restricted without proxy routing, the helper also isolates the network namespace via --unshare-net.
In managed proxy mode, the helper uses --unshare-net plus an internal TCP->UDS->TCP routing bridge so tool traffic reaches only configured proxy endpoints.
In managed proxy mode, after the bridge is live, seccomp blocks new AF_UNIX/socketpair creation for the user command.
When bubblewrap is active, it mounts a fresh /proc via --proc /proc by default, but you can skip this in restrictive container environments with --no-proc.

Notes

The CLI surface is codex sandbox; the host OS selects the sandbox backend.