77 Commits

• fix: fix comment linter lint violations in Linux-only code (#16118)

  https://github.com/openai/codex/pull/16071 took care of this for
  Windows, so this takes care of things for Linux.
  
  We don't touch the CI jobs in this PR because
  https://github.com/openai/codex/pull/16106 is going to be the real fix
  there (including a major speedup!).

  Michael Bolin · 2026-03-28 11:09:41 -07:00
  65f631c3d6
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• chore: move bwrap config helpers into dedicated module (#15898)

  ## Summary
  - move the bwrap PATH lookup and warning helpers out of config/mod.rs
  - move the related tests into a dedicated bwrap_tests.rs file
  
  ## Validation
  - git diff --check
  - skipped heavier local tests per request
  
  Follow-up to #15791.

  viyatb-oai · 2026-03-26 15:15:59 -07:00
  b52abff279
• 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: resolve bwrap from trusted PATH entry (#15791)

  ## Summary
  - resolve system bwrap from PATH instead of hardcoding /usr/bin/bwrap
  - skip PATH entries that resolve inside the current workspace before
  launching the sandbox helper
  - keep the vendored bubblewrap fallback when no trusted system bwrap is
  found
  
  ## Validation
  - cargo test -p codex-core bwrap --lib
  - cargo test -p codex-linux-sandbox
  - just fix -p codex-core
  - just fix -p codex-linux-sandbox
  - just fmt
  - just argument-comment-lint
  - cargo clean

  viyatb-oai · 2026-03-26 12:13:51 -07:00
  b6050b42ae
• fix: fix old system bubblewrap compatibility without falling back to vendored bwrap (#15693)

  Fixes #15283.
  
  ## Summary
  Older system bubblewrap builds reject `--argv0`, which makes our Linux
  sandbox fail before the helper can re-exec. This PR keeps using system
  `/usr/bin/bwrap` whenever it exists and only falls back to vendored
  bwrap when the system binary is missing. That matters on stricter
  AppArmor hosts, where the distro bwrap package also provides the policy
  setup needed for user namespaces.
  
  For old system bwrap, we avoid `--argv0` instead of switching binaries:
  - pass the sandbox helper a full-path `argv0`,
  - keep the existing `current_exe() + --argv0` path when the selected
  launcher supports it,
  - otherwise omit `--argv0` and re-exec through the helper's own
  `argv[0]` path, whose basename still dispatches as
  `codex-linux-sandbox`.
  
  Also updates the launcher/warning tests and docs so they match the new
  behavior: present-but-old system bwrap uses the compatibility path, and
  only absent system bwrap falls back to vendored.
  
  ### Validation
  
  1. Install Ubuntu 20.04 in a VM
  2. Compile codex and run without bubblewrap installed - see a warning
  about falling back to the vendored bwrap
  3. Install bwrap and verify version is 0.4.0 without `argv0` support
  4. run codex and use apply_patch tool without errors
  
  <img width="802" height="631" alt="Screenshot 2026-03-25 at 11 48 36 PM"
  src="https://github.com/user-attachments/assets/77248a29-aa38-4d7c-9833-496ec6a458b8"
  />
  <img width="807" height="634" alt="Screenshot 2026-03-25 at 11 47 32 PM"
  src="https://github.com/user-attachments/assets/5af8b850-a466-489b-95a6-455b76b5050f"
  />
  <img width="812" height="635" alt="Screenshot 2026-03-25 at 11 45 45 PM"
  src="https://github.com/user-attachments/assets/438074f0-8435-4274-a667-332efdd5cb57"
  />
  <img width="801" height="623" alt="Screenshot 2026-03-25 at 11 43 56 PM"
  src="https://github.com/user-attachments/assets/0dc8d3f5-e8cf-4218-b4b4-a4f7d9bf02e3"
  />
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  viyatb-oai · 2026-03-25 23:51:39 -07:00
  937cb5081d
• fix: fall back to vendored bubblewrap when system bwrap lacks --argv0 (#15338)

  ## Why
  
  Fixes [#15283](https://github.com/openai/codex/issues/15283), where
  sandboxed tool calls fail on older distro `bubblewrap` builds because
  `/usr/bin/bwrap` does not understand `--argv0`. The upstream [bubblewrap
  v0.9.0 release
  notes](https://github.com/containers/bubblewrap/releases/tag/v0.9.0)
  explicitly call out `Add --argv0`. Flipping `use_legacy_landlock`
  globally works around that compatibility bug, but it also weakens the
  default Linux sandbox and breaks proxy-routed and split-policy cases
  called out in review.
  
  The follow-up Linux CI failure was in the new launcher test rather than
  the launcher logic: the fake `bwrap` helper stayed open for writing, so
  Linux would not exec it. This update also closes the user-visibility gap
  from review by surfacing the same startup warning when `/usr/bin/bwrap`
  is present but too old for `--argv0`, not only when it is missing.
  
  ## What Changed
  
  - keep `use_legacy_landlock` default-disabled
  - teach `codex-rs/linux-sandbox/src/launcher.rs` to fall back to the
  vendored bubblewrap build when `/usr/bin/bwrap` does not advertise
  `--argv0` support
  - add launcher tests for supported, unsupported, and missing system
  `bwrap`
  - write the fake `bwrap` test helper to a closed temp path so the
  supported-path launcher test works on Linux too
  - extend the startup warning path so Codex warns when `/usr/bin/bwrap`
  is missing or too old to support `--argv0`
  - mirror the warning/fallback wording across
  `codex-rs/linux-sandbox/README.md` and `codex-rs/core/README.md`,
  including that the fallback is the vendored bubblewrap compiled into the
  binary
  - cite the upstream `bubblewrap` release that introduced `--argv0`
  
  ## Verification
  
  - `bazel test --config=remote --platforms=//:rbe
  //codex-rs/linux-sandbox:linux-sandbox-unit-tests
  --test_filter=launcher::tests::prefers_system_bwrap_when_help_lists_argv0
  --test_output=errors`
  - `cargo test -p codex-core system_bwrap_warning`
  - `cargo check -p codex-exec -p codex-tui -p codex-tui-app-server -p
  codex-app-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-23 09:46:51 -07:00
  d1088158b8
• core: add a full-buffer exec capture policy (#15254)
  Michael Bolin · 2026-03-20 02:38:12 +00:00
  a3e59e9e85
• fix(linux-sandbox): prefer system /usr/bin/bwrap when available (#14963)

  ## Problem
  Ubuntu/AppArmor hosts started failing in the default Linux sandbox path
  after the switch to vendored/default bubblewrap in `0.115.0`.
  
  The clearest report is in
  [#14919](https://github.com/openai/codex/issues/14919), especially [this
  investigation
  comment](https://github.com/openai/codex/issues/14919#issuecomment-4076504751):
  on affected Ubuntu systems, `/usr/bin/bwrap` works, but a copied or
  vendored `bwrap` binary fails with errors like `bwrap: setting up uid
  map: Permission denied` or `bwrap: loopback: Failed RTM_NEWADDR:
  Operation not permitted`.
  
  The root cause is Ubuntu's `/etc/apparmor.d/bwrap-userns-restrict`
  profile, which grants `userns` access specifically to `/usr/bin/bwrap`.
  Once Codex started using a vendored/internal bubblewrap path, that path
  was no longer covered by the distro AppArmor exception, so sandbox
  namespace setup could fail even when user namespaces were otherwise
  enabled and `uidmap` was installed.
  
  ## What this PR changes
  - prefer system `/usr/bin/bwrap` whenever it is available
  - keep vendored bubblewrap as the fallback when `/usr/bin/bwrap` is
  missing
  - when `/usr/bin/bwrap` is missing, surface a Codex startup warning
  through the app-server/TUI warning path instead of printing directly
  from the sandbox helper with `eprintln!`
  - use the same launcher decision for both the main sandbox execution
  path and the `/proc` preflight path
  - document the updated Linux bubblewrap behavior in the Linux sandbox
  and core READMEs
  
  ## Why this fix
  This still fixes the Ubuntu/AppArmor regression from
  [#14919](https://github.com/openai/codex/issues/14919), but it keeps the
  runtime rule simple and platform-agnostic: if the standard system
  bubblewrap is installed, use it; otherwise fall back to the vendored
  helper.
  
  The warning now follows that same simple rule. If Codex cannot find
  `/usr/bin/bwrap`, it tells the user that it is falling back to the
  vendored helper, and it does so through the existing startup warning
  plumbing that reaches the TUI and app-server instead of low-level
  sandbox stderr.
  
  ## Testing
  - `cargo test -p codex-linux-sandbox`
  - `cargo test -p codex-app-server --lib`
  - `cargo test -p codex-tui-app-server
  tests::embedded_app_server_start_failure_is_returned`
  - `cargo clippy -p codex-linux-sandbox --all-targets`
  - `cargo clippy -p codex-app-server --all-targets`
  - `cargo clippy -p codex-tui-app-server --all-targets`

  viyatb-oai · 2026-03-17 23:05:34 +00:00
  0d1539e74c
• 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
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• Use a private desktop for Windows sandbox instead of Winsta0\Default (#14400)

  ## Summary
  - launch Windows sandboxed children on a private desktop instead of
  `Winsta0\Default`
  - make private desktop the default while keeping
  `windows.sandbox_private_desktop=false` as the escape hatch
  - centralize process launch through the shared
  `create_process_as_user(...)` path
  - scope the private desktop ACL to the launching logon SID
  
  ## Why
  Today sandboxed Windows commands run on the visible shared desktop. That
  leaves an avoidable same-desktop attack surface for window interaction,
  spoofing, and related UI/input issues. This change moves sandboxed
  commands onto a dedicated per-launch desktop by default so the sandbox
  no longer shares `Winsta0\Default` with the user session.
  
  The implementation stays conservative on security with no silent
  fallback back to `Winsta0\Default`
  
  If private-desktop setup fails on a machine, users can still opt out
  explicitly with `windows.sandbox_private_desktop=false`.
  
  ## Validation
  - `cargo build -p codex-cli`
  - elevated-path `codex exec` desktop-name probe returned
  `CodexSandboxDesktop-*`
  - elevated-path `codex exec` smoke sweep for shell commands, nested
  `pwsh`, jobs, and hidden `notepad` launch
  - unelevated-path full private-desktop compatibility sweep via `codex
  exec` with `-c windows.sandbox=unelevated`

  iceweasel-oai · 2026-03-13 10:13:39 -07:00
  6b3d82daca
• 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
• fix: follow up on linux sandbox review nits (#14440)

  ## Summary
  - address the follow-up review nits from #13996 in a separate PR
  - make the approvals test command a raw string and keep the
  managed-network path using env proxy routing
  - inline `--apply-seccomp-then-exec` in the Linux sandbox inner command
  builder
  - remove the bubblewrap-specific sandbox metric tag path and drop the
  `use_legacy_landlock` shim from `sandbox_tag`/`TurnMetadataState::new`
  - restore the `Feature` import that `origin/main` currently still needs
  in `connectors.rs`
  
  ## Testing
  - `cargo test -p codex-linux-sandbox`
  - focused `codex-core` tests were rerun/started, but the final
  verification pass was interrupted when I pushed at request

  viyatb-oai · 2026-03-11 23:59:50 -07:00
  e99e8e4a6b
• refactor: make bubblewrap the default Linux sandbox (#13996)

  ## Summary
  - make bubblewrap the default Linux sandbox and keep
  `use_legacy_landlock` as the only override
  - remove `use_linux_sandbox_bwrap` from feature, config, schema, and
  docs surfaces
  - update Linux sandbox selection, CLI/config plumbing, and related
  tests/docs to match the new default
  - fold in the follow-up CI fixes for request-permissions responses and
  Linux read-only sandbox error text

  viyatb-oai · 2026-03-11 23:31:18 -07:00
  04892b4ceb
• fix(protocol): preserve legacy workspace-write semantics (#13957)

  ## Summary
  This is a fast follow to the initial `[permissions]` structure.
  
  - keep the new split-policy carveout behavior for narrower non-write
  entries under broader writable roots
  - preserve legacy `WorkspaceWrite` semantics by using a cwd-aware bridge
  that drops only redundant nested readable roots when projecting from
  `SandboxPolicy`
  - route the legacy macOS seatbelt adapter through that same legacy
  bridge so redundant nested readable roots do not become read-only
  carveouts on macOS
  - derive the legacy bridge for `command_exec` using the sandbox root cwd
  rather than the request cwd so policy derivation matches later sandbox
  enforcement
  - add regression coverage for the legacy macOS nested-readable-root case
  
  ## Examples
  ### Legacy `workspace-write` on macOS
  A legacy `workspace-write` policy can redundantly list a nested readable
  root under an already-writable workspace root.
  
  For example, legacy config can effectively mean:
  - workspace root (`.` / `cwd`) is writable
  - `docs/` is also listed in `readable_roots`
  
  The new shared split-policy helper intentionally treats a narrower
  non-write entry under a broader writable root as a carveout for real
  `[permissions]` configs. Without this fast follow, the unchanged macOS
  seatbelt legacy adapter could project that legacy shape into a
  `FileSystemSandboxPolicy` that treated `docs/` like a read-only carveout
  under the writable workspace root. In practice, legacy callers on macOS
  could unexpectedly lose write access inside `docs/`, even though that
  path was writable before the `[permissions]` migration work.
  
  This change fixes that by routing the legacy seatbelt path through the
  cwd-aware legacy bridge, so:
  - legacy `workspace-write` keeps `docs/` writable when `docs/` was only
  a redundant readable root
  - explicit `[permissions]` entries like `'.' = 'write'` and `'docs' =
  'read'` still make `docs/` read-only, which is the new intended
  split-policy behavior
  
  ### Legacy `command_exec` with a subdirectory cwd
  `command_exec` can run a command from a request cwd that is narrower
  than the sandbox root cwd.
  
  For example:
  - sandbox root cwd is `/repo`
  - request cwd is `/repo/subdir`
  - legacy policy is still `workspace-write` rooted at `/repo`
  
  Before this fast follow, `command_exec` derived the legacy bridge using
  the request cwd, but the sandbox was later built using the sandbox root
  cwd. That mismatch could miss redundant legacy readable roots during
  projection and accidentally reintroduce read-only carveouts for paths
  that should still be writable under the legacy model.
  
  This change fixes that by deriving the legacy bridge with the same
  sandbox root cwd that sandbox enforcement later uses.
  
  ## Verification
  - `just fmt`
  - `cargo test -p codex-core
  seatbelt_legacy_workspace_write_nested_readable_root_stays_writable`
  - `cargo test -p codex-core test_sandbox_config_parsing`
  - `cargo clippy -p codex-core -p codex-app-server --all-targets -- -D
  warnings`
  - `cargo clean`

  viyatb-oai · 2026-03-09 18:43:27 -07:00
  b0cbc25a48
• 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
• linux-sandbox: plumb split sandbox policies through helper (#13449)

  ## Why
  
  The Linux sandbox helper still only accepted the legacy `SandboxPolicy`
  payload.
  
  That meant the runtime could compute split filesystem and network
  policies, but the helper would immediately collapse them back to the
  compatibility projection before applying seccomp or staging the
  bubblewrap inner command.
  
  ## What changed
  
  - added hidden `--file-system-sandbox-policy` and
  `--network-sandbox-policy` flags alongside the legacy `--sandbox-policy`
  flag so the helper can migrate incrementally
  - updated the core-side Landlock wrapper to pass the split policies
  explicitly when launching `codex-linux-sandbox`
  - added helper-side resolution logic that accepts either the legacy
  policy alone or a complete split-policy pair and normalizes that into
  one effective configuration
  - switched Linux helper network decisions to use `NetworkSandboxPolicy`
  directly
  - added `FromStr` support for the split policy types so the helper can
  parse them from CLI JSON
  
  ## Verification
  
  - added helper coverage in `linux-sandbox/src/linux_run_main_tests.rs`
  for split-policy flags and policy resolution
  - added CLI argument coverage in `core/src/landlock.rs`
  - verified the current PR state with `just clippy`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13449).
  * #13453
  * #13452
  * #13451
  * __->__ #13449
  * #13448
  * #13445
  * #13440
  * #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 19:40:10 -08:00
  07a30da3fb
• sandboxing: plumb split sandbox policies through runtime (#13439)

  ## Why
  
  `#13434` introduces split `FileSystemSandboxPolicy` and
  `NetworkSandboxPolicy`, but the runtime still made most execution-time
  sandbox decisions from the legacy `SandboxPolicy` projection.
  
  That projection loses information about combinations like unrestricted
  filesystem access with restricted network access. In practice, that
  means the runtime can choose the wrong platform sandbox behavior or set
  the wrong network-restriction environment for a command even when config
  has already separated those concerns.
  
  This PR carries the split policies through the runtime so sandbox
  selection, process spawning, and exec handling can consult the policy
  that actually matters.
  
  ## What changed
  
  - threaded `FileSystemSandboxPolicy` and `NetworkSandboxPolicy` through
  `TurnContext`, `ExecRequest`, sandbox attempts, shell escalation state,
  unified exec, and app-server exec overrides
  - updated sandbox selection in `core/src/sandboxing/mod.rs` and
  `core/src/exec.rs` to key off `FileSystemSandboxPolicy.kind` plus
  `NetworkSandboxPolicy`, rather than inferring behavior only from the
  legacy `SandboxPolicy`
  - updated process spawning in `core/src/spawn.rs` and the platform
  wrappers to use `NetworkSandboxPolicy` when deciding whether to set
  `CODEX_SANDBOX_NETWORK_DISABLED`
  - kept additional-permissions handling and legacy `ExternalSandbox`
  compatibility projections aligned with the split policies, including
  explicit user-shell execution and Windows restricted-token routing
  - updated callers across `core`, `app-server`, and `linux-sandbox` to
  pass the split policies explicitly
  
  ## Verification
  
  - added regression coverage in `core/tests/suite/user_shell_cmd.rs` to
  verify `RunUserShellCommand` does not inherit
  `CODEX_SANDBOX_NETWORK_DISABLED` from the active turn
  - added coverage in `core/src/exec.rs` for Windows restricted-token
  sandbox selection when the legacy projection is `ExternalSandbox`
  - updated Linux sandbox coverage in
  `linux-sandbox/tests/suite/landlock.rs` to exercise the split-policy
  exec path
  - verified the current PR state with `just clippy`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13439).
  * #13453
  * #13452
  * #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * __->__ #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 02:30:21 +00:00
  22ac6b9aaa
• 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
• Revert "Ensure shell command skills trigger approval (#12697)" (#12721)

  This reverts commit daf0f03ac8.
  
  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Celia Chen · 2026-02-25 22:49:53 +00:00
  b6d20748e0
• Ensure shell command skills trigger approval (#12697)

  Summary
  - detect skill-invoking shell commands based on the original command
  string, request approvals when needed, and cache positive decisions per
  session
  - keep implicit skill invocation emitted after approval and keep skill
  approval decline messaging centralized to the shell handler
  - expand and adjust skill approval tests to cover shell-based skill
  scripts while matching the new detection expectations
  
  Testing
  - Not run (not requested)

  pakrym-oai · 2026-02-24 12:13:20 -08:00
  daf0f03ac8
• 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
• Refactor network approvals to host/protocol/port scope (#12140)

  ## Summary
  Simplify network approvals by removing per-attempt proxy correlation and
  moving to session-level approval dedupe keyed by (host, protocol, port).
  Instead of encoding attempt IDs into proxy credentials/URLs, we now
  treat approvals as a destination policy decision.
  
  - Concurrent calls to the same destination share one approval prompt.
  - Different destinations (or same host on different ports) get separate
  prompts.
  - Allow once approves the current queued request group only.
  - Allow for session caches that (host, protocol, port) and auto-allows
  future matching requests.
  - Never policy continues to deny without prompting.
  
  Example:
  - 3 calls: 
    - a.com (line 443)
    - b.com (line 443)
    - a.com (line 443)
  => 2 prompts total (a, b), second a waits on the first decision.
  - a.com:80 is treated separately from a.com line 443
  
  ## Testing
  - `just fmt` (in `codex-rs`)
  - `cargo test -p codex-core tools::network_approval::tests`
  - `cargo test -p codex-core` (unit tests pass; existing
  integration-suite failures remain in this environment)

  viyatb-oai · 2026-02-20 10:39:55 -08:00
  e8afaed502
• 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(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• build(linux-sandbox): always compile vendored bubblewrap on Linux; remove CODEX_BWRAP_ENABLE_FFI (#11498)

  ## Summary
  This PR removes the temporary `CODEX_BWRAP_ENABLE_FFI` flag and makes
  Linux builds always compile vendored bubblewrap support for
  `codex-linux-sandbox`.
  
  ## Changes
  - Removed `CODEX_BWRAP_ENABLE_FFI` gating from
  `codex-rs/linux-sandbox/build.rs`.
  - Linux builds now fail fast if vendored bubblewrap compilation fails
  (instead of warning and continuing).
  - Updated fallback/help text in
  `codex-rs/linux-sandbox/src/vendored_bwrap.rs` to remove references to
  `CODEX_BWRAP_ENABLE_FFI`.
  - Removed `CODEX_BWRAP_ENABLE_FFI` env wiring from:
    - `.github/workflows/rust-ci.yml`
    - `.github/workflows/bazel.yml`
    - `.github/workflows/rust-release.yml`
  
  ---------
  
  Co-authored-by: David Zbarsky <zbarsky@openai.com>

  viyatb-oai · 2026-02-11 21:30:41 -08:00
  923f931121
• 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
• deflake linux-sandbox NoNewPrivs timeout (#11245)

  Deflake `codex-linux-sandbox::all
  suite::landlock::test_no_new_privs_is_enabled`.
  
  CI has intermittently failed with `Sandbox(Timeout)` (exit 124) because
  the sandboxed
  `grep '^NoNewPrivs:' /proc/self/status` can run close to the short
  timeout budget.
  
  This updates only this test to use `LONG_TIMEOUT_MS`, which removes the
  near-threshold timeout
  behavior while keeping the rest of the suite unchanged.
  
  Refs (previous failures):
  - PR:
  https://github.com/openai/codex/actions/runs/21836764823/job/63009902779
  - PR:
  https://github.com/openai/codex/actions/runs/21837427251/job/63012470353
  - main:
  https://github.com/openai/codex/actions/runs/21830746538/job/62988079964
  
  Validation:
  - Local: `cd codex-rs && cargo test -p codex-linux-sandbox` (non-Linux
  runs 0 tests)

  Josh McKinney · 2026-02-10 03:03:58 +00:00
  34c88d10ea
• feat: include NetworkConfig through ExecParams (#11105)

  This PR adds the following field to `Config`:
  
  ```rust
  pub network: Option<NetworkProxy>,
  ```
  
  Though for the moment, it will always be initialized as `None` (this
  will be addressed in a subsequent PR).
  
  This PR does the work to thread `network` through to `execute_exec_env()`, `process_exec_tool_call()`, and `UnifiedExecRuntime.run()` to ensure it is available whenever we span a process.

  Michael Bolin · 2026-02-09 03:32:17 +00:00
  383b45279e
• fix(linux-sandbox): block io_uring syscalls in no-network seccomp policy (#10814)

  ## Summary
  
  - Add seccomp deny rules for `io_uring` syscalls in the Linux sandbox
  network policy.
  - Specifically deny:
    - `SYS_io_uring_setup`
    - `SYS_io_uring_enter`
    - `SYS_io_uring_register`

  viyatb-oai · 2026-02-06 11:00:54 -08:00
  8896ca0ee6
• 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
• Inject CODEX_THREAD_ID into the terminal environment (#10096)

  Inject CODEX_THREAD_ID (when applicable) into the terminal environment
  so that the agent (and skills) can refer to the current thread / session
  ID.
  
  Discussion:
  https://openai.slack.com/archives/C095U48JNL9/p1769542492067109

  Max Johnson · 2026-02-03 11:31:12 -08:00
  66b196a725
• 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
• remove sandbox globals. (#9797)

  Threads sandbox updates through OverrideTurnContext for active turn
  Passes computed sandbox type into safety/exec

  iceweasel-oai · 2026-01-27 11:04:23 -08:00
  c40ad65bd8
• revert: remove pre-Landlock bind mounts apply (#9300)

  **Description**
  
  This removes the pre‑Landlock read‑only bind‑mount step from the Linux
  sandbox so filesystem restrictions rely solely on Landlock again.
  `mounts.rs` is kept in place but left unused. The linux‑sandbox README
  is updated to match the new behavior and manual test expectations.

  viyatb-oai · 2026-01-15 09:47:57 -08:00
  55bda1a0f2
• fix: fallback to Landlock-only when user namespaces unavailable and set PR_SET_NO_NEW_PRIVS early (#9250)

  fixes https://github.com/openai/codex/issues/9236
  
  ### Motivation
  - Prevent sandbox setup from failing when unprivileged user namespaces
  are denied so Landlock-only protections can still be applied.
  - Ensure `PR_SET_NO_NEW_PRIVS` is set before installing seccomp and
  Landlock restrictions to avoid kernel `EPERM`/`LandlockRestrict`
  ordering issues.
  
  ### Description
  - Add `is_permission_denied` helper that detects `EPERM` /
  `PermissionDenied` from `CodexErr` to drive fallback logic.
  - In `apply_read_only_mounts` skip read-only bind-mount setup and return
  `Ok(())` when `unshare_user_and_mount_namespaces()` fails with
  permission-denied so Landlock rules can still be installed.
  - Add `set_no_new_privs()` and call it from
  `apply_sandbox_policy_to_current_thread` before installing seccomp
  filters and Landlock rules when disk or network access is restricted.

  viyatb-oai · 2026-01-14 22:24:34 -08:00
  2259031d64
• fix: correct linux sandbox uid/gid mapping after unshare (#9234)

  fixes https://github.com/openai/codex/issues/9233
  ## Summary
  - capture effective uid/gid before unshare for user namespace maps
  - pass captured ids into uid/gid map writer
  
  ## Testing
  - just fmt
  - just fix -p codex-linux-sandbox
  - cargo test -p codex-linux-sandbox

  viyatb-oai · 2026-01-14 15:35:53 -08:00
  e59e7d163d
• feat: add support for read-only bind mounts in the linux sandbox (#9112)

  ### Motivation
  
  - Landlock alone cannot prevent writes to sensitive in-repo files like
  `.git/` when the repo root is writable, so explicit mount restrictions
  are required for those paths.
  - The sandbox must set up any mounts before calling Landlock so Landlock
  can still be applied afterwards and the two mechanisms compose
  correctly.
  
  ### Description
  
  - Add a new `linux-sandbox` helper `apply_read_only_mounts` in
  `linux-sandbox/src/mounts.rs` that: unshares namespaces, maps uids/gids
  when required, makes mounts private, bind-mounts targets, and remounts
  them read-only.
  - Wire the mount step into the sandbox flow by calling
  `apply_read_only_mounts(...)` before network/seccomp and before applying
  Landlock rules in `linux-sandbox/src/landlock.rs`.

  viyatb-oai · 2026-01-14 08:30:46 -08:00
  e1447c3009
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• refactoring with_escalated_permissions to use SandboxPermissions instead (#7750)

  helpful in the future if we want more granularity for requesting
  escalated permissions:
  e.g when running in readonly sandbox, model can request to escalate to a
  sandbox that allows writes

  zhao-oai · 2025-12-10 17:18:48 +00:00
  e0fb3ca1db
• fix: allow sendmsg(2) and recvmsg(2) syscalls in our Linux sandbox (#7779)

  This changes our default Landlock policy to allow `sendmsg(2)` and
  `recvmsg(2)` syscalls. We believe these were originally denied out of an
  abundance of caution, but given that `send(2)` nor `recv(2)` are allowed
  today [which provide comparable capability to the `*msg` equivalents],
  we do not believe allowing them grants any privileges beyond what we
  already allow.
  
  Rather than using the syscall as the security boundary, preventing
  access to the potentially hazardous file descriptor in the first place
  seems like the right layer of defense.
  
  In particular, this makes it possible for `shell-tool-mcp` to run on
  Linux when using a read-only sandbox for the Bash process, as
  demonstrated by `accept_elicitation_for_prompt_rule()` now succeeding in
  CI.

  Michael Bolin · 2025-12-09 09:24:01 -08:00
  a7e3e37da8
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874