## Why `ReadOnlyAccess` was a transitional legacy shape on `SandboxPolicy`: `FullAccess` meant the historical read-only/workspace-write modes could read the full filesystem, while `Restricted` tried to carry partial readable roots. The partial-read model now belongs in `FileSystemSandboxPolicy` and `PermissionProfile`, so keeping it on `SandboxPolicy` makes every legacy projection reintroduce lossy read-root bookkeeping and creates unnecessary noise in the rest of the permissions migration. This PR makes the legacy policy model narrower and explicit: `SandboxPolicy::ReadOnly` and `SandboxPolicy::WorkspaceWrite` represent the old full-read sandbox modes only. Split readable roots, deny-read globs, and platform-default/minimal read behavior stay in the runtime permissions model. ## What changed - Removes `ReadOnlyAccess` from `codex_protocol::protocol::SandboxPolicy`, including the generated `access` and `readOnlyAccess` API fields. - Updates legacy policy/profile conversions so restricted filesystem reads are represented only by `FileSystemSandboxPolicy` / `PermissionProfile` entries. - Keeps app-server v2 compatible with legacy `fullAccess` read-access payloads by accepting and ignoring that no-op shape, while rejecting legacy `restricted` read-access payloads instead of silently widening them to full-read legacy policies. - Carries Windows sandbox platform-default read behavior with an explicit override flag instead of depending on `ReadOnlyAccess::Restricted`. - Refreshes generated app-server schema/types and updates tests/docs for the simplified legacy policy shape. ## Verification - `cargo check -p codex-app-server-protocol --tests` - `cargo check -p codex-windows-sandbox --tests` - `cargo test -p codex-app-server-protocol sandbox_policy_` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19449). * #19395 * #19394 * #19393 * #19392 * #19391 * __->__ #19449
codex-linux-sandbox
This crate is responsible for producing:
- a
codex-linux-sandboxstandalone 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-execCLI can check if its arg0 iscodex-linux-sandboxand, if so, execute as if it werecodex-linux-sandbox - this should also be true of the
codexmultitool CLI
- the
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 vendored bubblewrap path compiled into this
binary.
Codex also surfaces a startup warning when bwrap is missing so users know it
is falling back to the vendored 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_modeconfigs remain supported. -
Bubblewrap is the default filesystem sandbox.
-
If
bwrapis present onPATHoutside the current working directory, the helper uses it. -
If
bwrapis present but too old to support--argv0, the helper uses a no---argv0compatibility path for the inner re-exec. -
If
bwrapis missing, the helper falls back to the vendored bubblewrap path. -
If
bwrapis 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
cwdresolution. -
Split-only filesystem policies that do not round-trip through the legacy
SandboxPolicymodel stay on bubblewrap so nested read-only or denied carveouts are preserved. -
When bubblewrap is active, the helper applies
PR_SET_NO_NEW_PRIVSand 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, resolvedgitdir:, 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 = writekeeps/repowritable, denies/repo/a, and reopens/repo/a/bas 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 constructionUsers can cap the scan depth per permissions profile:
[permissions.workspace.filesystem] glob_scan_max_depth = 2 [permissions.workspace.filesystem.":project_roots"] "**/*.env" = "none" -
When bubblewrap is active, symlink-in-path and non-existent protected paths inside writable roots are blocked by mounting
/dev/nullon the symlink or first missing component. -
When bubblewrap is active, the helper explicitly isolates the user namespace via
--unshare-userand 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-netplus 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
/procvia--proc /procby default, but you can skip this in restrictive container environments with--no-proc.
Notes
- The CLI surface still uses legacy names like
codex debug landlock.