24 Commits

• test: branch on target OS instead of runner flavor (#29712)

  ## Why
  
  Core tests should branch on the executor's operating system, not on
  runner details such as Docker or Wine. This keeps platform behavior
  stable as new test backends are added and reserves Wine-specific skips
  for actual runner debt.
  
  ## What
  
  - Add `TestTargetOs` and target/host-aware skip helpers while keeping
  `TestEnvironment` internal.
  - Replace topology enum access with remote predicates and a narrow
  Docker accessor.
  - Migrate OS-semantic Wine skips, preserve runner-specific gaps, and
  document the skip taxonomy.
  
  ## Validation
  
  - `just test -p core_test_support`
  - `just test -p codex-core
  remote_test_env_can_connect_and_use_filesystem`
  - `bazel test //codex-rs/core:core-all-wine-exec-test
  --test_output=errors` reached test execution; unrelated existing
  view-image, path, and timing failures remain.
  - `just test -p codex-core` and `just test` reached broad test
  execution; this checkout has unrelated helper, sandbox, and timing
  failures.

  Adam Perry @ OpenAI · 2026-06-23 14:27:13 -07:00
  9a79536e6b
• Run core integration tests against a Wine-backed Windows executor (#28401)

  ## Why
  
  We want to exercise a linux app-server against a windows exec-server
  without having to repeat every test case. This approach has slight
  precedent in the remote docker test setup.
  
  ## What
  
  Run the shared `codex-core` integration suite against Windows
  exec-server behavior from Linux. This makes cross-OS path and shell
  regressions visible while keeping unsupported cases owned by individual
  tests.
  
  - Add `local`, `docker`, and `wine-exec` test environment selection with
  legacy Docker compatibility.
  - Extend `codex_rust_crate` to generate a sharded Wine-exec variant
  using a cross-built Windows server and pinned Bazel Wine/PowerShell
  runtimes.
  - Teach remote-aware helpers about Windows paths and track temporary
  incompatibilities with source-local `skip_if_wine_exec!` calls and
  follow-up reasons.

  Adam Perry @ OpenAI · 2026-06-16 00:38:41 +00:00
  1fe89de576
• cli: infer host sandbox backend (#24102)

  ## Why
  
  `codex sandbox` previously required an OS subcommand like `linux`,
  `macos`, or `windows`, even though the command can only run the sandbox
  backend available on the current host. That made the CLI imply a
  cross-OS choice that does not exist.
  
  ## What changed
  
  - Collapse `codex sandbox <os>` into `codex sandbox [COMMAND]...` by
  wiring the `sandbox` parser directly to the host-specific backend args
  with `cfg`.
  - Keep the existing backend runners for Seatbelt, Linux sandbox, and
  Windows restricted token.
  - Rename the public Windows debug sandbox runner to
  `run_command_under_windows_sandbox` for clarity.
  - Update the Rust sandbox docs and related README references to describe
  host OS selection and avoid pointing readers at legacy `sandbox_mode`
  config.
  
  ## Arg0 compatibility
  
  The `codex-linux-sandbox` helper path is still handled before normal CLI
  parsing. `arg0_dispatch()` checks whether the executable basename is
  `codex-linux-sandbox` and directly calls
  `codex_linux_sandbox::run_main()`, so removing the `sandbox linux`
  parser branch does not affect the arg0 helper flow.
  
  ## Verification
  
  - `cargo test -p codex-cli`
  - `cargo test -p codex-arg0`
  - `just fix -p codex-cli`

  Michael Bolin · 2026-05-22 10:23:59 -07:00
  c0b16cfc6b
• linux-sandbox: use standalone bundled bwrap (#21255)

  **Summary**
  - Add `codex-bwrap`, a standalone `bwrap` binary built from the existing
  vendored bubblewrap sources.
  - Remove the linked vendored bwrap path from `codex-linux-sandbox`;
  runtime now prefers system `bwrap` and falls back to bundled
  `codex-resources/bwrap`.
  - Add bundled SHA-256 verification with missing/all-zero digest as the
  dev-mode skip value, then exec the verified file through
  `/proc/self/fd`.
  - Keep `launcher.rs` focused on choosing and dispatching the preferred
  launcher. Bundled lookup, digest verification, and bundled exec now live
  in `linux-sandbox/src/bundled_bwrap.rs`; Bazel runfiles lookup lives in
  `linux-sandbox/src/bazel_bwrap.rs`; shared argv/fd exec helpers live in
  `linux-sandbox/src/exec_util.rs`.
  - Teach Bazel tests to surface the Bazel-built `//codex-rs/bwrap:bwrap`
  through `CARGO_BIN_EXE_bwrap`; `codex-linux-sandbox` only honors that
  fallback in debug Bazel runfiles environments so release/user runtime
  lookup stays tied to `codex-resources/bwrap`.
  - Allow `codex-exec-server` filesystem helpers to preserve just the
  Bazel bwrap/runfiles variables they need in debug Bazel builds, since
  those helpers intentionally rebuild a small environment before spawning
  `codex-linux-sandbox`.
  - Verify the Bazel bwrap target in Linux release CI with a build-only
  check. Running `bwrap --version` is too strong for GitHub runners
  because bubblewrap still attempts namespace setup there.
  
  **Verification**
  - Latest update: `cargo test -p codex-linux-sandbox`
  - Latest update: `just fix -p codex-linux-sandbox`
  - `cargo check --target x86_64-unknown-linux-gnu -p codex-linux-sandbox`
  could not run locally because this macOS machine does not have
  `x86_64-linux-gnu-gcc`; GitHub Linux Bazel CI is expected to cover the
  Linux-only modules.
  - Earlier in this PR: `cargo test -p codex-bwrap`
  - Earlier in this PR: `cargo test -p codex-exec-server`
  - Earlier in this PR: `cargo check --release -p codex-exec-server`
  - Earlier in this PR: `just fix -p codex-linux-sandbox -p
  codex-exec-server`
  - Earlier in this PR: `bazel test --nobuild
  //codex-rs/linux-sandbox:linux-sandbox-all-test
  //codex-rs/core:core-all-test
  //codex-rs/exec-server:exec-server-file_system-test
  //codex-rs/app-server:app-server-all-test` (analysis completed; Bazel
  then refuses to run tests under `--nobuild`)
  - Earlier in this PR: `bazel build --nobuild //codex-rs/bwrap:bwrap`
  - Prior to this update: `just bazel-lock-update`, `just
  bazel-lock-check`, and YAML parse check for
  `.github/workflows/bazel.yml`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21255).
  * #21257
  * #21256
  * __->__ #21255

  Michael Bolin · 2026-05-05 17:14:29 -07:00
  26f355b67b
• permissions: remove legacy read-only access modes (#19449)

  ## 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

  Michael Bolin · 2026-04-24 17:16:58 -07:00
  789f387982
• Route apply_patch through the environment filesystem (#17674)

  ## Summary
  - route apply_patch runtime execution through the selected Environment
  filesystem instead of the local self-exec path
  - keep the standalone apply_patch command surface intact while restoring
  its launcher/test/docs contract
  - add focused apply_patch filesystem sandbox regression coverage
  
  ## Validation
  - remote devbox Bazel run in progress
  - passed: //codex-rs/apply-patch:apply-patch-unit-tests
  --test_filter=test_read_file_utf8_with_context_reports_invalid_utf8
  - in progress / follow-up: focused core and exec Bazel test slices on
  dev
  
  ## Follow-up under review
  - remote pre-verification and approval/retry behavior still need
  explicit scrutiny for delete/update flows
  - runtime sandbox-denial classification may need a tighter assertion
  path than rendered stderr matching
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-14 12:49:02 -07:00
  c24124b37d
• fix(sandboxing): reject WSL1 bubblewrap sandboxing (#17559)

  ## Summary
  
  - detect WSL1 before Codex probes or invokes the Linux bubblewrap
  sandbox
  - fail early with a clear unsupported-operation message when a command
  would require bubblewrap on WSL1
  - document that WSL2 follows the normal Linux bubblewrap path while WSL1
  is unsupported
  
  ## Why
  
  Codex 0.115.0 made bubblewrap the default Linux sandbox. WSL1 cannot
  create the user namespaces that bubblewrap needs, so shell commands
  currently fail later with a raw bwrap namespace error. This makes the
  unsupported environment explicit and keeps non-bubblewrap paths
  unchanged.
  
  The WSL detection reads /proc/version, lets an explicit WSL<version>
  marker decide WSL1 vs WSL2+, and only treats a bare Microsoft marker as
  WSL1 when no explicit WSL version is present.
  
  addresses https://github.com/openai/codex/issues/16076
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-12 14:08:14 -07:00
  cb870a169a
• fix: support split carveouts in windows elevated sandbox (#14568)

  ## Summary
  - preserve legacy Windows elevated sandbox behavior for existing
  policies
  - add elevated-only support for split filesystem policies that can be
  represented as readable-root overrides, writable-root overrides, and
  extra deny-write carveouts
  - resolve those elevated filesystem overrides during sandbox transform
  and thread them through setup and policy refresh
  - keep failing closed for explicit unreadable (`none`) carveouts and
  reopened writable descendants under read-only carveouts
  - for explicit read-only-under-writable-root carveouts, materialize
  missing carveout directories during elevated setup before applying the
  deny-write ACL
  - document the elevated vs restricted-token support split in the core
  README
  
  ## Example
  Given a split filesystem policy like:
  
  ```toml
  ":root" = "read"
  ":cwd" = "write"
  "./docs" = "read"
  "C:/scratch" = "write"
  ```
  
  the elevated backend now provisions the readable-root overrides,
  writable-root overrides, and extra deny-write carveouts during setup and
  refresh instead of collapsing back to the legacy workspace-only shape.
  
  If a read-only carveout under a writable root is missing at setup time,
  elevated setup creates that carveout as an empty directory before
  applying its deny-write ACE; otherwise the sandboxed command could
  create it later and bypass the carveout. This is only for explicit
  policy carveouts. Best-effort workspace protections like `.codex/` and
  `.agents/` still skip missing directories.
  
  A policy like:
  
  ```toml
  "/workspace" = "write"
  "/workspace/docs" = "read"
  "/workspace/docs/tmp" = "write"
  ```
  
  still fails closed, because the elevated backend does not reopen
  writable descendants under read-only carveouts yet.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-09 17:34:52 -07:00
  b976e701a8
• fix: warn when bwrap cannot create user namespaces (#15893)

  ## Summary
  - add a Linux startup warning when system `bwrap` is present but cannot
  create user namespaces
  - keep the Linux-specific probe, sandbox-policy gate, and stderr
  matching in `codex-sandboxing`
  - polish the missing-`bwrap` warning to point users at the sandbox
  prerequisites and OS package-manager install path
  
  ## Details
  - probes system `bwrap` with `--unshare-user`, `--unshare-net`, and a
  minimal bind before command execution
  - detects known bubblewrap setup failures for `RTM_NEWADDR`,
  `RTM_NEWLINK`, uid-map permission denial, and `No permissions to create
  a new namespace`
  - preserves the existing suppression for sandbox-bypassed policies such
  as `danger-full-access` and `external-sandbox`
  - updates the Linux sandbox docs to call out the user-namespace
  requirement
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-06 19:19:35 -07:00
  806e5f7c69
• permissions: remove macOS seatbelt extension profiles (#15918)

  ## Why
  
  `PermissionProfile` should only describe the per-command permissions we
  still want to grant dynamically. Keeping
  `MacOsSeatbeltProfileExtensions` in that surface forced extra macOS-only
  approval, protocol, schema, and TUI branches for a capability we no
  longer want to expose.
  
  ## What changed
  
  - Removed the macOS-specific permission-profile types from
  `codex-protocol`, the app-server v2 API, and the generated
  schema/TypeScript artifacts.
  - Deleted the core and sandboxing plumbing that threaded
  `MacOsSeatbeltProfileExtensions` through execution requests and seatbelt
  construction.
  - Simplified macOS seatbelt generation so it always includes the fixed
  read-only preferences allowlist instead of carrying a configurable
  profile extension.
  - Removed the macOS additional-permissions UI/docs/test coverage and
  deleted the obsolete macOS permission modules.
  - Tightened `request_permissions` intersection handling so explicitly
  empty requested read lists are preserved only when that field was
  actually granted, avoiding zero-grant responses being stored as active
  permissions.

  Michael Bolin · 2026-03-26 17:12:45 -07:00
  e6e2999209
• 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: support split carveouts in windows restricted-token sandbox (#14172)

  ## Summary
  - keep legacy Windows restricted-token sandboxing as the supported
  baseline
  - support the split-policy subset that restricted-token can enforce
  directly today
  - support full-disk read, the same writable root set as legacy
  `WorkspaceWrite`, and extra read-only carveouts under those writable
  roots via additional deny-write ACLs
  - continue to fail closed for unsupported split-only shapes, including
  explicit unreadable (`none`) carveouts, reopened writable descendants
  under read-only carveouts, and writable root sets that do not match the
  legacy workspace roots
  
  ## Example
  Given a filesystem policy like:
  
  ```toml
  ":root" = "read"
  ":cwd" = "write"
  "./docs" = "read"
  ```
  
  the restricted-token backend can keep the workspace writable while
  denying writes under `docs` by layering an extra deny-write carveout on
  top of the legacy workspace-write roots.
  
  A policy like:
  
  ```toml
  "/workspace" = "write"
  "/workspace/docs" = "read"
  "/workspace/docs/tmp" = "write"
  ```
  
  still fails closed, because the unelevated backend cannot reopen the
  nested writable descendant safely.
  
  ## Stack
  -> fix: support split carveouts in windows restricted-token sandbox
  #14172
  fix: support split carveouts in windows elevated sandbox #14568

  viyatb-oai · 2026-03-24 22:54:18 -07:00
  95ba762620
• 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
• feat: support restricted ReadOnlyAccess in elevated Windows sandbox (#14610)

  ## Summary
  - support legacy `ReadOnlyAccess::Restricted` on Windows in the elevated
  setup/runner backend
  - keep the unelevated restricted-token backend on the legacy full-read
  model only, and fail closed for restricted read-only policies there
  - keep the legacy full-read Windows path unchanged while deriving
  narrower read roots only for elevated restricted-read policies
  - honor `include_platform_defaults` by adding backend-managed Windows
  system roots only when requested, while always keeping helper roots and
  the command `cwd` readable
  - preserve `workspace-write` semantics by keeping writable roots
  readable when restricted read access is in use in the elevated backend
  - document the current Windows boundary: legacy `SandboxPolicy` is
  supported on both backends, while richer split-only carveouts still fail
  closed instead of running with weaker enforcement
  
  ## Testing
  - `cargo test -p codex-windows-sandbox`
  - `cargo check -p codex-windows-sandbox --tests --target
  x86_64-pc-windows-msvc`
  - `cargo clippy -p codex-windows-sandbox --tests --target
  x86_64-pc-windows-msvc -- -D warnings`
  - `cargo test -p codex-core windows_restricted_token_`
  
  ## Notes
  - local `cargo test -p codex-windows-sandbox` on macOS only exercises
  the non-Windows stubs; the Windows-targeted compile and clippy runs
  provide the local signal, and GitHub Windows CI exercises the runtime
  path

  viyatb-oai · 2026-03-17 19:08:50 -07:00
  d950543e65
• 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: 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
• feat: Add additional macOS Sandbox Permissions for Launch Services, Contacts, Reminders (#14155)

  Add additional macOS Sandbox Permissions levers for the following:
  
  - Launch Services
  - Contacts
  - Reminders

  Leo Shimonaka · 2026-03-11 12:33:09 -07:00
  889b4796fc
• [feat] add seatbelt permission files (#11639)

  Add seatbelt permission extension abstraction as permission files for
  seatbelt profiles. This should complement our current sandbox policy

  Celia Chen · 2026-02-12 23:30:22 +00:00
  dfd1e199a0
• 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
• docs: align sandbox defaults, dedupe sections and improve getting started guide (#5357)

  Tightened the docs so the sandbox guide matches reality, noted the new
  tools.view_image toggle next to web search, and linked the README to the
  getting-started guide which now owns the familiar tips (backtrack, --cd,
  --add-dir, etc.).

  Thibault Sottiaux · 2025-10-19 16:41:10 -07:00
  2d9ee9dbe9
• add codex sandbox {linux|macos} (#4782)

  ## Summary
  - add a `codex sandbox` subcommand with macOS and Linux targets while
  keeping the legacy `codex debug` aliases
  - update documentation to highlight the new sandbox entrypoints and
  point existing references to the new command
  - clarify the core README about the linux sandbox helper alias
  
  ## Testing
  - just fmt
  - just fix -p codex-cli
  - cargo test -p codex-cli
  
  
  ------
  https://chatgpt.com/codex/tasks/task_i_68e2e00ca1e8832d8bff53aa0b50b49e

  Fouad Matin · 2025-10-05 15:51:57 -07:00
  77a8b7fdeb
• fix: support special --codex-run-as-apply-patch arg (#1702)

  This introduces some special behavior to the CLIs that are using the
  `codex-arg0` crate where if `arg1` is `--codex-run-as-apply-patch`, then
  it will run as if `apply_patch arg2` were invoked. This is important
  because it means we can do things like:
  
  ```
  SANDBOX_TYPE=landlock # or seatbelt for macOS
  codex debug "${SANDBOX_TYPE}" -- codex --codex-run-as-apply-patch PATCH
  ```
  
  which gives us a way to run `apply_patch` while ensuring it adheres to
  the sandbox the user specified.
  
  While it would be nice to use the `arg0` trick like we are currently
  doing for `codex-linux-sandbox`, there is no way to specify the `arg0`
  for the underlying command when running under `/usr/bin/sandbox-exec`,
  so it will not work for us in this case.
  
  Admittedly, we could have also supported this via a custom environment
  variable (e.g., `CODEX_ARG0`), but since environment variables are
  inherited by child processes, that seemed like a potentially leakier
  abstraction.
  
  This change, as well as our existing reliance on checking `arg0`, place
  additional requirements on those who include `codex-core`. Its
  `README.md` has been updated to reflect this.
  
  While we could have just added an `apply-patch` subcommand to the
  `codex` multitool CLI, that would not be sufficient for the standalone
  `codex-exec` CLI, which is something that we distribute as part of our
  GitHub releases for those who know they will not be using the TUI and
  therefore prefer to use a slightly smaller executable:
  
  https://github.com/openai/codex/releases/tag/rust-v0.10.0
  
  To that end, this PR adds an integration test to ensure that the
  `--codex-run-as-apply-patch` option works with the standalone
  `codex-exec` CLI.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1702).
  * #1705
  * #1703
  * __->__ #1702
  * #1698
  * #1697

  Michael Bolin · 2025-07-28 09:26:44 -07:00
  d76f96ce79
• feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)

  As stated in `codex-rs/README.md`:
  
  Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
  run it. For a number of users, this runtime requirement inhibits
  adoption: they would be better served by a standalone executable. As
  maintainers, we want Codex to run efficiently in a wide range of
  environments with minimal overhead. We also want to take advantage of
  operating system-specific APIs to provide better sandboxing, where
  possible.
  
  To that end, we are moving forward with a Rust implementation of Codex
  CLI contained in this folder, which has the following benefits:
  
  - The CLI compiles to small, standalone, platform-specific binaries.
  - Can make direct, native calls to
  [seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
  [landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
  order to support sandboxing on Linux.
  - No runtime garbage collection, resulting in lower memory consumption
  and better, more predictable performance.
  
  Currently, the Rust implementation is materially behind the TypeScript
  implementation in functionality, so continue to use the TypeScript
  implmentation for the time being. We will publish native executables via
  GitHub Releases as soon as we feel the Rust version is usable.

  Michael Bolin · 2025-04-24 13:31:40 -07:00
  31d0d7a305