16 Commits

• Protect first-time project .codex creation across Linux and macOS sandboxes (#15067)

  ## Problem
  
  Codex already treated an existing top-level project `./.codex` directory
  as protected, but there was a gap on first creation.
  
  If `./.codex` did not exist yet, a turn could create files under it,
  such as `./.codex/config.toml`, without going through the same approval
  path as later modifications. That meant the initial write could bypass
  the intended protection for project-local Codex state.
  
  ## What this changes
  
  This PR closes that first-creation gap in the Unix enforcement layers:
  
  - `codex-protocol`
  - treat the top-level project `./.codex` path as a protected carveout
  even when it does not exist yet
  - avoid injecting the default carveout when the user already has an
  explicit rule for that exact path
  - macOS Seatbelt
  - deny writes to both the exact protected path and anything beneath it,
  so creating `./.codex` itself is blocked in addition to writes inside it
  - Linux bubblewrap
  - preserve the same protected-path behavior for first-time creation
  under `./.codex`
  - tests
  - add protocol regressions for missing `./.codex` and explicit-rule
  collisions
  - add Unix sandbox coverage for blocking first-time `./.codex` creation
    - tighten Seatbelt policy assertions around excluded subpaths
  
  ## Scope
  
  This change is intentionally scoped to protecting the top-level project
  `.codex` subtree from agent writes.
  
  It does not make `.codex` unreadable, and it does not change the product
  behavior around loading project skills from `.codex` when project config
  is untrusted.
  
  ## Why this shape
  
  The fix is pointed rather than broad:
  - it preserves the current model of “project `.codex` is protected from
  writes”
  - it closes the security-relevant first-write hole
  - it avoids folding a larger permissions-model redesign into this PR
  
  ## Validation
  
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-sandboxing seatbelt`
  - `cargo test -p codex-exec --test all
  sandbox_blocks_first_time_dot_codex_creation -- --nocapture`
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  rreichel3-oai · 2026-03-26 16:06:53 -04:00
  86764af684
• fix(linux-sandbox): ignore missing writable roots (#14890)

  ## Summary
  - skip nonexistent `workspace-write` writable roots in the Linux
  bubblewrap mount builder instead of aborting sandbox startup
  - keep existing writable roots mounted normally so mixed Windows/WSL
  configs continue to work
  - add unit and Linux integration regression coverage for the
  missing-root case
  
  ## Context
  This addresses regression A from #14875. Regression B will be handled in
  a separate PR.
  
  The old bubblewrap integration added `ensure_mount_targets_exist` as a
  preflight guard because bubblewrap bind targets must exist, and failing
  early let Codex return a clearer error than a lower-level mount failure.
  
  That policy turned out to be too strict once bubblewrap became the
  default Linux sandbox: shared Windows/WSL or mixed-platform configs can
  legitimately contain a well-formed writable root that does not exist on
  the current machine. This PR keeps bubblewrap's existing-target
  requirement, but changes Codex to skip missing writable roots instead of
  treating them as fatal configuration errors.

  viyatb-oai · 2026-03-17 00:21:00 -07:00
  603b6493a9
• fix: canonicalize symlinked Linux sandbox cwd (#14849)

  ## Problem
  On Linux, Codex can be launched from a workspace path that is a symlink
  (for example, a symlinked checkout or a symlinked parent directory).
  
  Our sandbox policy intentionally canonicalizes writable/readable roots
  to the real filesystem path before building the bubblewrap mounts. That
  part is correct and needed for safety.
  
  The remaining bug was that bubblewrap could still inherit the helper
  process's logical cwd, which might be the symlinked alias instead of the
  mounted canonical path. In that case, the sandbox starts in a cwd that
  does not exist inside the sandbox namespace even though the real
  workspace is mounted. This can cause sandboxed commands to fail in
  symlinked workspaces.
  
  ## Fix
  This PR keeps the sandbox policy behavior the same, but separates two
  concepts that were previously conflated:
  
  - the canonical cwd used to define sandbox mounts and permissions
  - the caller's logical cwd used when launching the command
  
  On the Linux bubblewrap path, we now thread the logical command cwd
  through the helper explicitly and only add `--chdir <canonical path>`
  when the logical cwd differs from the mounted canonical path.
  
  That means:
  - permissions are still computed from canonical paths
  - bubblewrap starts the command from a cwd that definitely exists inside
  the sandbox
  - we do not widen filesystem access or undo the earlier symlink
  hardening
  
  ## Why This Is Safe
  This is a narrow Linux-only launch fix, not a policy change.
  
  - Writable/readable root canonicalization stays intact.
  - Protected metadata carveouts still operate on canonical roots.
  - We only override bubblewrap's inherited cwd when the logical path
  would otherwise point at a symlink alias that is not mounted in the
  sandbox.
  
  ## Tests
  - kept the existing protocol/core regression coverage for symlink
  canonicalization
  - added regression coverage for symlinked cwd handling in the Linux
  bubblewrap builder/helper path
  
  Local validation:
  - `just fmt`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-core
  normalize_additional_permissions_canonicalizes_symlinked_write_paths`
  - `cargo clippy -p codex-linux-sandbox -p codex-protocol -p codex-core
  --tests -- -D warnings`
  - `cargo build --bin codex`
  
  ## Context
  This is related to #14694. The earlier writable-root symlink fix
  addressed the mount/permission side; this PR fixes the remaining
  symlinked-cwd launch mismatch in the Linux sandbox path.

  viyatb-oai · 2026-03-16 22:39:18 -07:00
  db7e02c739
• fix: reopen writable linux carveouts under denied parents (#14514)

  ## Summary
  - preserve Linux bubblewrap semantics for `write -> none -> write`
  filesystem policies by recreating masked mount targets before rebinding
  narrower writable descendants
  - add a Linux runtime regression for `/repo = write`, `/repo/a = none`,
  `/repo/a/b = write` so the nested writable child is exercised under
  bubblewrap
  - document the supported legacy Landlock fallback and the split-policy
  bubblewrap behavior for overlapping carveouts
  
  ## Example
  Given a split filesystem policy like:
  
  ```toml
  "/repo" = "write"
  "/repo/a" = "none"
  "/repo/a/b" = "write"
  ```
  
  this PR keeps `/repo` writable, masks `/repo/a`, and still reopens
  `/repo/a/b` as writable again under bubblewrap.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-linux-sandbox`
  - `cargo clippy -p codex-linux-sandbox --tests -- -D warnings`

  viyatb-oai · 2026-03-13 01:36:06 +00:00
  f194d4b115
• fix: preserve split filesystem semantics in linux sandbox (#14173)

  ## Stack
  
     fix: fail closed for unsupported split windows sandboxing #14172
  -> fix: preserve split filesystem semantics in linux sandbox #14173
     fix: align core approvals with split sandbox policies #14171
     refactor: centralize filesystem permissions precedence #14174
  
  ## Summary
  ## Summary
  - Preserve Linux split filesystem carveouts in bubblewrap by applying
  mount masks in the right order, so narrower rules still win under
  broader writable roots.
  - Preserve unreadable ancestors of writable roots by masking them first
  and then rebinding the narrower writable descendants.
  - Stop rejecting legacy-plus-split Linux configs that are
  sandbox-equivalent after `cwd` resolution by comparing semantics instead
  of raw legacy structs.
  - Fail closed when callers provide partial split policies, mismatched
  legacy-plus-split policies, or force `--use-legacy-landlock` for
  split-only shapes that legacy Landlock cannot enforce.
  - Add Linux regressions for overlapping writable, read-only, and denied
  paths, and document the supported split-policy enforcement path.
  
  ## Example
  Given a split filesystem policy like:
  
  ```toml
  [permissions.dev.filesystem]
  ":root" = "read"
  "/code" = "write"
  "/code/.git" = "read"
  "/code/secrets" = "none"
  "/code/secrets/tmp" = "write"
  ```
  
  this PR makes Linux enforce the intended result under bubblewrap:
  
  - `/code` stays writable
  - `/code/.git` stays read-only
  - `/code/secrets` stays denied
  - `/code/secrets/tmp` can still be reopened as writable if explicitly
  allowed
  
  Before this, Linux could lose one of those carveouts depending on mount
  order or legacy-policy fallback. This PR keeps the split-policy
  semantics intact and rejects configurations that legacy Landlock cannot
  represent safely.

  viyatb-oai · 2026-03-12 10:56:32 -07:00
  774965f1e8
• linux-sandbox: honor split filesystem policies in bwrap (#13453)

  ## Why
  
  After `#13449`, the Linux helper could receive split filesystem and
  network policies, but the bubblewrap mount builder still reconstructed
  filesystem access from the legacy `SandboxPolicy`.
  
  That loses explicit unreadable carveouts under writable roots, and it
  also mishandles `Root` read access paired with explicit deny carveouts.
  In those cases bubblewrap could still expose paths that the split
  filesystem policy intentionally blocked.
  
  ## What changed
  
  - switched bubblewrap mount generation to consume
  `FileSystemSandboxPolicy` directly at the implementation boundary;
  legacy `SandboxPolicy` configs still flow through the existing
  `FileSystemSandboxPolicy::from(&sandbox_policy)` bridge before reaching
  bwrap
  - kept the Linux helper and preflight path on the split filesystem
  policy all the way into bwrap
  - re-applied explicit unreadable carveouts after readable and writable
  mounts so blocked subpaths still win under bubblewrap
  - masked denied directories with `--tmpfs` plus `--remount-ro` and
  denied files with `--ro-bind-data`, preserving the backing fd until exec
  - added comments in the unreadable-root masking block to explain why the
  mount order and directory/file split are intentional
  - updated Linux helper call sites and tests for the split-policy bwrap
  path
  
  ## Verification
  
  - added protocol coverage for root carveouts staying scoped
  - added core coverage that root-write plus deny carveouts still requires
  a platform sandbox
  - added bwrap unit coverage for reapplying blocked carveouts after
  writable binds
  - added Linux integration coverage for explicit split-policy carveouts
  under bubblewrap
  - validated the final branch state with `cargo test -p
  codex-linux-sandbox`, `cargo clippy -p codex-linux-sandbox --all-targets
  -- -D warnings`, and the PR CI reruns
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13453).
  * __->__ #13453
  * #13452
  * #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 23:46:52 -08:00
  dcc4d7b634
• fix(linux-sandbox): always unshare bwrap userns (#13624)

  ## Summary
  - always pass `--unshare-user` in the Linux bubblewrap argv builders
  - stop relying on bubblewrap's auto-userns behavior, which is skipped
  for `uid 0`
  - update argv expectations in tests and document the explicit user
  namespace behavior
  
  The installed Codex binary reproduced the same issue with:
  - `codex -c features.use_linux_sandbox_bwrap=true sandbox linux -- true`
  - `bwrap: Creating new namespace failed: Operation not permitted`
  
  This happens because Codex asked bubblewrap for mount/pid/network
  namespaces without explicitly asking for a user namespace. In a
  root-inside-container environment without ambient `CAP_SYS_ADMIN`, that
  fails. Adding `--unshare-user` makes bubblewrap create the user
  namespace first and then the remaining namespaces succeed.

  viyatb-oai · 2026-03-05 21:57:40 +00:00
  9950b5e265
• Feat: Preserve network access on read-only sandbox policies (#13409)

  ## Summary
  
  `PermissionProfile.network` could not be preserved when additional or
  compiled permissions resolved to
  `SandboxPolicy::ReadOnly`, because `ReadOnly` had no network_access
  field. This change makes read-only + network
  enabled representable directly and threads that through the protocol,
  app-server v2 mirror, and permission-
    merging logic.
  
  ## What changed
  
  - Added `network_access: bool` to `SandboxPolicy::ReadOnly` in the core
  protocol and app-server v2 protocol.
  - Kept backward compatibility by defaulting the new field to false, so
  legacy read-only payloads still
      deserialize unchanged.
  - Updated `has_full_network_access()` and sandbox summaries to respect
  read-only network access.
    - Preserved PermissionProfile.network when:
        - compiling skill permission profiles into sandbox policies
        - normalizing additional permissions
        - merging additional permissions into existing sandbox policies
  - Updated the approval overlay to show network in the rendered
  permission rule when requested.
    - Regenerated app-server schema fixtures for the new v2 wire shape.

  Celia Chen · 2026-03-04 02:41:57 +00:00
  e6773f856c
• feat(linux-sandbox): support restricted ReadOnlyAccess in bwrap (#12369)

  ## Summary
  Implements Linux bubblewrap support for restricted `ReadOnlyAccess`
  (introduced in #11387) by honoring `readable_roots` and
  `include_platform_defaults` instead of failing closed.
  
  ## What changed
  - Added a Linux platform-default read allowlist for common
  system/runtime paths (e.g. /usr, /etc, /lib*, Nix store roots).
  - Updated the bwrap filesystem mount builder to support restricted read
  access:
    - Full-read policies still use `--ro-bind / /`
  - Restricted-read policies now start from` --tmpfs `/ and add scoped
  `--ro-bind` mounts
  - Preserved existing writable-root and protected-subpath behavior
  (`.git`, `.codex`, etc.).
  
  `ReadOnlyAccess::Restricted` was already modeled in protocol, but Linux
  bwrap still returned `UnsupportedOperation` for restricted read access.
  This closes that gap for the active Linux filesystem backend.
  
  
  ## Notes
  Legacy Linux Landlock fallback still fail-closes for restricted read
  access (unchanged).

  viyatb-oai · 2026-02-27 15:25:50 -08:00
  a39d76dc45
• feat(linux-sandbox): implement proxy-only egress via TCP-UDS-TCP bridge (#11293)

  ## Summary
  - Implement Linux proxy-only routing in `codex-rs/linux-sandbox` with a
  two-stage bridge: host namespace `loopback TCP proxy endpoint -> UDS`,
  then bwrap netns `loopback TCP listener -> host UDS`.
  - Add hidden `--proxy-route-spec` plumbing for outer-to-inner stage
  handoff.
  - Fail closed in proxy mode when no valid loopback proxy endpoints can
  be routed.
  - Introduce explicit network seccomp modes: `Restricted` (legacy
  restricted networking) and `ProxyRouted` (allow INET/INET6 for routed
  proxy access, deny `AF_UNIX` and `socketpair`).
  - Enforce that proxy bridge/routing is bwrap-only by validating
  `--apply-seccomp-then-exec` requires `--use-bwrap-sandbox`.
  - Keep landlock-only flows unchanged (no proxy bridge behavior outside
  bwrap).
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-21 18:16:34 +00:00
  b3202cbd58
• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• fix(linux-sandbox): mount /dev in bwrap sandbox (#12081)

  ## Summary
  - Updates the Linux bubblewrap sandbox args to mount a minimal `/dev`
  using `--dev /dev` instead of only binding `/dev/null`. tools needing
  entropy (git, crypto libs, etc.) can fail.
  
  - Changed mount order so `--dev /dev` is added before writable-root
  `--bind` mounts, preserving writable `/dev/*` submounts like `/dev/shm`
  
  ## Why
  Fixes sandboxed command failures when reading `/dev/urandom` (and
  similar standard device-node access).
  
  
  Fixes https://github.com/openai/codex/issues/12056

  viyatb-oai · 2026-02-18 23:27:32 -08:00
  4fe99b086f
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• feat(sandbox): enforce proxy-aware network routing in sandbox (#11113)

  ## Summary
  - expand proxy env injection to cover common tool env vars
  (`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`/`NO_PROXY` families +
  tool-specific variants)
  - harden macOS Seatbelt network policy generation to route through
  inferred loopback proxy endpoints and fail closed when proxy env is
  malformed
  - thread proxy-aware Linux sandbox flags and add minimal bwrap netns
  isolation hook for restricted non-proxy runs
  - add/refresh tests for proxy env wiring, Seatbelt policy generation,
  and Linux sandbox argument wiring

  viyatb-oai · 2026-02-10 07:44:21 +00:00
  3391e5ea86
• feat(linux-sandbox): add bwrap support (#9938)

  ## Summary
  This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
  curent Linux sandbox path relies on in-process restrictions (including
  Landlock). Bubblewrap gives us a more uniform filesystem isolation
  model, especially explicit writable roots with the option to make some
  directories read-only and granular network controls.
  
  This is behind a feature flag so we can validate behavior safely before
  making it the default.
  
  - Added temporary rollout flag:
    - `features.use_linux_sandbox_bwrap`
  - Preserved existing default path when the flag is off.
  - In Bubblewrap mode:
  - Added internal retry without /proc when /proc mount is not permitted
  by the host/container.

  viyatb-oai · 2026-02-04 11:13:17 -08:00
  ae4de43ccc
• feat(linux-sandbox): vendor bubblewrap and wire it with FFI (#10413)

  ## Summary
  
  Vendor Bubblewrap into the repo and add minimal build plumbing in
  `codex-linux-sandbox` to compile/link it.
  
  ## Why
  
  We want to move Linux sandboxing toward Bubblewrap, but in a safe
  two-step rollout:
  1) vendoring/build setup (this PR),  
  2) runtime integration (follow-up PR).
  
  ## Included
  
  - Add `codex-rs/vendor/bubblewrap` sources.
  - Add build-time FFI path in `codex-rs/linux-sandbox`.
  - Update `build.rs` rerun tracking for vendored files.
  - Small vendored compile warning fix (`sockaddr_nl` full init).
  
  follow up in https://github.com/openai/codex/pull/9938

  viyatb-oai · 2026-02-02 23:33:46 -08:00
  f956cc2a02