62 Commits

• permissions: derive legacy exec policies at boundaries (#19737)

  ## Why
  
  After config and requirements store canonical profiles, exec requests
  should not cache a derived `SandboxPolicy`. The cached legacy value can
  drift from the richer profile state, and most execution paths already
  have the filesystem and network runtime policies they need.
  
  ## What Changed
  
  - Removes `sandbox_policy` from `codex_sandboxing::SandboxExecRequest`
  and `codex_core::sandboxing::ExecRequest`.
  - Adds an on-demand `ExecRequest::compatibility_sandbox_policy()` helper
  for the Windows and legacy call sites that still need a `SandboxPolicy`
  projection.
  - Updates Windows filesystem override setup and unified exec policy
  serialization to derive that compatibility policy at the boundary.
  - Updates Unix escalation reruns and direct shell requests to
  reconstruct exec requests from `PermissionProfile` plus runtime
  filesystem/network policy, without carrying a cached legacy policy.
  - Adjusts sandboxing manager tests to assert the effective profile
  rather than the removed legacy field.
  
  ## Verification
  
  - `cargo check -p codex-config -p codex-core -p codex-sandboxing -p
  codex-app-server -p codex-cli -p codex-tui`
  - `cargo test -p codex-sandboxing manager`
  - `cargo test -p codex-core
  exec_server_params_use_env_policy_overlay_contract`
  - `cargo test -p codex-core unix_escalation`
  - `cargo test -p codex-core exec::tests`
  - `cargo test -p codex-core sandboxing::tests`

  Michael Bolin · 2026-04-26 22:11:49 -07:00
  a6ca39c630
• permissions: make runtime config profile-backed (#19606)

  ## Why
  
  This supersedes #19391. During stack repair, GitHub marked #19391 as
  merged into a temporary stack branch rather than into `main`, so the
  runtime-config change needed a fresh PR.
  
  `PermissionProfile` is now the canonical permissions shape after #19231
  because it can distinguish `Managed`, `Disabled`, and `External`
  enforcement while also carrying filesystem rules that legacy
  `SandboxPolicy` cannot represent cleanly. Core config and session state
  still needed to accept profile-backed permissions without forcing every
  profile through the strict legacy bridge, which rejected valid runtime
  profiles such as direct write roots.
  
  The unrelated CI/test hardening that previously rode along with this PR
  has been split into #19683 so this PR stays focused on the permissions
  model migration.
  
  ## What Changed
  
  - Adds `Permissions.permission_profile` and
  `SessionConfiguration.permission_profile` as constrained runtime state,
  while keeping `sandbox_policy` as a legacy compatibility projection.
  - Introduces profile setters that keep `PermissionProfile`, split
  filesystem/network policies, and legacy `SandboxPolicy` projections
  synchronized.
  - Uses a compatibility projection for requirement checks and legacy
  consumers instead of rejecting profiles that cannot round-trip through
  `SandboxPolicy` exactly.
  - Updates config loading, config overrides, session updates, turn
  context plumbing, prompt permission text, sandbox tags, and exec request
  construction to carry profile-backed runtime permissions.
  - Preserves configured deny-read entries and `glob_scan_max_depth` when
  command/session profiles are narrowed.
  - Adds `PermissionProfile::read_only()` and
  `PermissionProfile::workspace_write()` presets that match legacy
  defaults.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19606).
  * #19395
  * #19394
  * #19393
  * #19392
  * __->__ #19606

  Michael Bolin · 2026-04-26 13:29:54 -07:00
  4d7ce3447d
• Add Windows sandbox unified exec runtime support (#15578)

  ## Summary
  
  This is the runtime/foundation half of the Windows sandbox unified-exec
  work.
  
  - add Windows sandbox `unified_exec` session support in
  `windows-sandbox-rs` for both:
    - the legacy restricted-token backend
    - the elevated runner backend
  - extend the PTY/process runtime so driver-backed sessions can support:
    - stdin streaming
    - stdout/stderr separation
    - exit propagation
    - PTY resize hooks
  - add Windows sandbox runtime coverage in `codex-windows-sandbox` /
  `codex-utils-pty`
  
  This PR does **not** enable Windows sandbox `UnifiedExec` for product
  callers yet because hooking this up to app-server comes in the next PR.
  
  Windows sandbox advertising is intentionally kept aligned with `main`,
  so sandboxed Windows callers still fall back to `ShellCommand`.
  
  This PR isolates the runtime/session layer so it can be reviewed
  independently from product-surface enablement.
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  iceweasel-oai · 2026-04-21 10:44:49 -07:00
  8612714aa6
• Build remote exec env from exec-server policy (#17216)

  ## Summary
  - add an exec-server `envPolicy` field; when present, the server starts
  from its own process env and applies the shell environment policy there
  - keep `env` as the exact environment for local/embedded starts, but
  make it an overlay for remote unified-exec starts
  - move the shell-environment-policy builder into `codex-config` so Core
  and exec-server share the inherit/filter/set/include behavior
  - overlay only runtime/sandbox/network deltas from Core onto the
  exec-server-derived env
  
  ## Why
  Remote unified exec was materializing the shell env inside Core and
  forwarding the whole map to exec-server, so remote processes could
  inherit the orchestrator machine's `HOME`, `PATH`, etc. This keeps the
  base env on the executor while preserving Core-owned runtime additions
  like `CODEX_THREAD_ID`, unified-exec defaults, network proxy env, and
  sandbox marker env.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - `cargo test -p codex-exec-server --lib`
  - `cargo test -p codex-core --lib unified_exec::process_manager::tests`
  - `cargo test -p codex-core --lib exec_env::tests`
  - `cargo test -p codex-core --lib exec_env_tests` (compile-only; filter
  matched 0 tests)
  - `cargo test -p codex-config --lib shell_environment` (compile-only;
  filter matched 0 tests)
  - `just bazel-lock-update`
  
  ## Known local validation issue
  - `just bazel-lock-check` is not runnable in this checkout: it invokes
  `./scripts/check-module-bazel-lock.sh`, which is missing.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  jif-oai · 2026-04-13 09:59:08 +01:00
  bacb92b1d7
• 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
• Use AbsolutePathBuf for exec cwd plumbing (#17063)

  ## Summary
  - Carry `AbsolutePathBuf` through tool cwd parsing/resolution instead of
  resolving workdirs to raw `PathBuf`s.
  - Type exec/sandbox request cwd fields as `AbsolutePathBuf` through
  `ExecParams`, `ExecRequest`, `SandboxCommand`, and unified exec runtime
  requests.
  - Keep `PathBuf` conversions at external/event boundaries and update
  existing tests/fixtures for the typed cwd.
  
  ## Validation
  - `cargo check -p codex-core --tests`
  - `cargo check -p codex-sandboxing --tests`
  - `cargo test -p codex-sandboxing`
  - `cargo test -p codex-core --lib tools::handlers::`
  - `just fix -p codex-sandboxing`
  - `just fix -p codex-core`
  - `just fmt`
  
  Full `codex-core` test suite was not run locally; per repo guidance I
  kept local validation targeted.

  pakrym-oai · 2026-04-08 10:54:12 -07:00
  35b5720e8d
• remove temporary ownership re-exports (#16626)

  Stacked on #16508.
  
  This removes the temporary `codex-core` / `codex-login` re-export shims
  from the ownership split and rewrites callsites to import directly from
  `codex-model-provider-info`, `codex-models-manager`, `codex-api`,
  `codex-protocol`, `codex-feedback`, and `codex-response-debug-context`.
  
  No behavior change intended; this is the mechanical import cleanup layer
  split out from the ownership move.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-03 00:33:34 -07:00
  af8a9d2d2b
• extract models manager and related ownership from core (#16508)

  ## Summary
  - split `models-manager` out of `core` and add `ModelsManagerConfig`
  plus `Config::to_models_manager_config()` so model metadata paths stop
  depending on `core::Config`
  - move login-owned/auth-owned code out of `core` into `codex-login`,
  move model provider config into `codex-model-provider-info`, move API
  bridge mapping into `codex-api`, move protocol-owned types/impls into
  `codex-protocol`, and move response debug helpers into a dedicated
  `response-debug-context` crate
  - move feedback tag emission into `codex-feedback`, relocate tests to
  the crates that now own the code, and keep broad temporary re-exports so
  this PR avoids a giant import-only rewrite
  
  ## Major moves and decisions
  - created `codex-models-manager` as the owner for model
  cache/catalog/config/model info logic, including the new
  `ModelsManagerConfig` struct
  - created `codex-model-provider-info` as the owner for provider config
  parsing/defaults and kept temporary `codex-login`/`codex-core`
  re-exports for old import paths
  - moved `api_bridge` error mapping + `CoreAuthProvider` into
  `codex-api`, while `codex-login::api_bridge` temporarily re-exports
  those symbols and keeps the `auth_provider_from_auth` wrapper
  - moved `auth_env_telemetry` and `provider_auth` ownership to
  `codex-login`
  - moved `CodexErr` ownership to `codex-protocol::error`, plus
  `StreamOutput`, `bytes_to_string_smart`, and network policy helpers to
  protocol-owned modules
  - created `codex-response-debug-context` for
  `extract_response_debug_context`, `telemetry_transport_error_message`,
  and related response-debug plumbing instead of leaving that behavior in
  `core`
  - moved `FeedbackRequestTags`, `emit_feedback_request_tags`, and
  `emit_feedback_request_tags_with_auth_env` to `codex-feedback`
  - deferred removal of temporary re-exports and the mechanical import
  rewrites to a stacked follow-up PR so this PR stays reviewable
  
  ## Test moves
  - moved auth refresh coverage from `core/tests/suite/auth_refresh.rs` to
  `login/tests/suite/auth_refresh.rs`
  - moved text encoding coverage from
  `core/tests/suite/text_encoding_fix.rs` to
  `protocol/src/exec_output_tests.rs`
  - moved model info override coverage from
  `core/tests/suite/model_info_overrides.rs` to
  `models-manager/src/model_info_overrides_tests.rs`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-02 23:00:02 -07:00
  6fff9955f1
• fix(core) rm execute_exec_request sandbox_policy (#16422)

  ## Summary
  In #11871 we started consolidating on ExecRequest.sandbox_policy instead
  of passing in a separate policy object that theoretically could differ
  (but did not). This finishes the some parameter cleanup.
  
  This should be a simple noop, since all 3 callsites of this function
  already used a cloned object from the ExecRequest value.
  
  ## Testing
  - [x] Existing tests pass

  Dylan Hurd · 2026-04-01 11:03:48 -04:00
  d3b99ef110
• 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
• Drop sandbox_permissions from sandbox exec requests (#15665)

  ## Summary
  - drop `sandbox_permissions` from the sandboxing `ExecOptions` and
  `ExecRequest` adapter types
  - remove the now-unused plumbing from shell, unified exec, JS REPL, and
  apply-patch runtime call sites
  - default reconstructed `ExecParams` to `SandboxPermissions::UseDefault`
  where the lower-level API still requires the field
  
  ## Testing
  - `just fmt`
  - `just argument-comment-lint`
  - `cargo test -p codex-core` (still running locally; first failures
  observed in `suite::cli_stream::responses_mode_stream_cli`,
  `suite::cli_stream::responses_mode_stream_cli_supports_openai_base_url_config_override`,
  and
  `suite::cli_stream::responses_mode_stream_cli_supports_openai_base_url_env_fallback`)

  pakrym-oai · 2026-03-24 15:42:45 -07:00
  0b619afc87
• Extract sandbox manager and transforms into codex-sandboxing (#15603)

  Extract sandbox manager

  pakrym-oai · 2026-03-24 08:20:57 -07:00
  f49eb8e9d7
• Move sandbox policy transforms into codex-sandboxing (#15599)

  ## Summary
  - move the pure sandbox policy transform helpers from `codex-core` into
  `codex-sandboxing`
  - move the corresponding unit tests with the extracted implementation
  - update `core` and `app-server` callers to import the moved APIs
  directly, without re-exports or proxy methods
  
  ## Testing
  - cargo test -p codex-sandboxing
  - cargo test -p codex-core sandboxing
  - cargo test -p codex-app-server --lib
  - just fix -p codex-sandboxing
  - just fix -p codex-core
  - just fix -p codex-app-server
  - just fmt
  - just argument-comment-lint

  pakrym-oai · 2026-03-23 22:22:44 -07:00
  9deb8ce3fc
• Move macOS sandbox builders into codex-sandboxing (#15593)

  ## Summary
  - move macOS permission merging/intersection logic and tests from
  `codex-core` into `codex-sandboxing`
  - move seatbelt policy builders, permissions logic, SBPL assets, and
  their tests into `codex-sandboxing`
  - keep `codex-core` owning only the seatbelt spawn wrapper and switch
  call sites to import the moved APIs directly
  
  ## Notes
  - no re-exports added
  - moved the seatbelt tests with the implementation so internal helpers
  could stay private
  - local verification is still finishing while this PR is open

  pakrym-oai · 2026-03-23 21:26:35 -07:00
  431af0807c
• Extract landlock helpers into codex-sandboxing (#15592)

  ## Summary
  - add a new `codex-sandboxing` crate for sandboxing extraction work
  - move the pure Linux sandbox argv builders and their unit tests out of
  `codex-core`
  - keep `core::landlock` as the spawn wrapper and update direct callers
  to use `codex_sandboxing::landlock`
  
  ## Testing
  - `cargo test -p codex-sandboxing`
  - `cargo test -p codex-core landlock`
  - `cargo test -p codex-cli debug_sandbox`
  - `just argument-comment-lint`
  
  ## Notes
  - this is step 1 of the move plan aimed at minimizing per-PR diffs
  - no re-exports or no-op proxy methods were added

  pakrym-oai · 2026-03-23 20:56:15 -07:00
  2227248cd6
• core: add a full-buffer exec capture policy (#15254)
  Michael Bolin · 2026-03-20 02:38:12 +00:00
  a3e59e9e85
• 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: move inline codex-rs/core unit tests into sibling files (#14444)

  ## Why
  PR #13783 moved the `codex.rs` unit tests into `codex_tests.rs`. This
  applies the same extraction pattern across the rest of `codex-rs/core`
  so the production modules stay focused on runtime code instead of large
  inline test blocks.
  
  Keeping the tests in sibling files also makes follow-up edits easier to
  review because product changes no longer have to share a file with
  hundreds or thousands of lines of test scaffolding.
  
  ## What changed
  - replaced each inline `mod tests { ... }` in `codex-rs/core/src/**`
  with a path-based module declaration
  - moved each extracted unit test module into a sibling `*_tests.rs`
  file, using `mod_tests.rs` for `mod.rs` modules
  - preserved the existing `cfg(...)` guards and module-local structure so
  the refactor remains structural rather than behavioral
  
  ## Testing
  - `cargo test -p codex-core --lib` (`1653 passed; 0 failed; 5 ignored`)
  - `just fix -p codex-core`
  - `cargo fmt --check`
  - `cargo shear`

  Michael Bolin · 2026-03-12 08:16:36 -07:00
  0c8a36676a
• Use granted permissions when invoking apply_patch (#14429)
  Jack Mousseau · 2026-03-12 01:30:13 -07:00
  745ed4e5e0
• 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
• 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
• Add request permissions tool (#13092)

  Adds a built-in `request_permissions` tool and wires it through the
  Codex core, protocol, and app-server layers so a running turn can ask
  the client for additional permissions instead of relying on a static
  session policy.
  
  The new flow emits a `RequestPermissions` event from core, tracks the
  pending request by call ID, forwards it through app-server v2 as an
  `item/permissions/requestApproval` request, and resumes the tool call
  once the client returns an approved subset of the requested permission
  profile.

  Jack Mousseau · 2026-03-08 20:23:06 -07:00
  e6b93841c5
• protocol: keep root carveouts sandboxed (#13452)

  ## Why
  
  A restricted filesystem policy that grants `:root` read or write access
  but also carries explicit deny entries should still behave like scoped
  access with carveouts, not like unrestricted disk access.
  
  Without that distinction, later platform backends cannot preserve
  blocked subpaths under root-level permissions because the protocol layer
  reports the policy as fully unrestricted.
  
  ## What changed
  
  - taught `FileSystemSandboxPolicy` to treat root access plus explicit
  deny entries as scoped access rather than full-disk access
  - derived readable and writable roots from the filesystem root when root
  access is combined with carveouts, while preserving the denied paths as
  read-only subpaths
  - added protocol coverage for root-write policies with carveouts and a
  core sandboxing regression so those policies still require platform
  sandboxing
  
  ## Verification
  
  - added protocol coverage in `protocol/src/permissions.rs` and
  `protocol/src/protocol.rs` for root access with explicit carveouts
  - added platform-sandbox regression coverage in
  `core/src/sandboxing/mod.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/13452).
  * #13453
  * __->__ #13452
  * #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 21:15:47 -08:00
  3b5fe5ca35
• sandboxing: preserve denied paths when widening permissions (#13451)

  ## Why
  
  After the split-policy plumbing landed, additional-permissions widening
  still rebuilt filesystem access through the legacy projection in a few
  places.
  
  That can erase explicit deny entries and make the runtime treat a policy
  as fully writable even when it still has blocked subpaths, which in turn
  can skip the platform sandbox when it is still needed.
  
  ## What changed
  
  - preserved explicit deny entries when merging additional read and write
  permissions into `FileSystemSandboxPolicy`
  - switched platform-sandbox selection to rely on
  `FileSystemSandboxPolicy::has_full_disk_write_access()` instead of ad
  hoc root-write checks
  - kept the widened policy path in `core/src/exec.rs` and
  `core/src/sandboxing/mod.rs` aligned so denied subpaths survive both
  policy merging and sandbox selection
  - added regression coverage for root-write policies that still carry
  carveouts
  
  ## Verification
  
  - added regression coverage in `core/src/sandboxing/mod.rs` showing that
  root write plus carveouts still requires the platform sandbox
  - 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/13451).
  * #13453
  * #13452
  * __->__ #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-08 04:29:35 +00:00
  46b8d127cf
• 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
• seatbelt: honor split filesystem sandbox policies (#13448)

  ## Why
  
  After `#13440` and `#13445`, macOS Seatbelt policy generation was still
  deriving filesystem and network behavior from the legacy `SandboxPolicy`
  projection.
  
  That projection loses explicit unreadable carveouts and conflates split
  network decisions, so the generated Seatbelt policy could still be wider
  than the split policy that Codex had already computed.
  
  ## What changed
  
  - added Seatbelt entrypoints that accept `FileSystemSandboxPolicy` and
  `NetworkSandboxPolicy` directly
  - built read and write policy stanzas from access roots plus excluded
  subpaths so explicit unreadable carveouts survive into the generated
  Seatbelt policy
  - switched network policy generation to consult `NetworkSandboxPolicy`
  directly
  - failed closed when managed-network or proxy-constrained sessions do
  not yield usable loopback proxy endpoints
  - updated the macOS callers and test helpers that now need to carry the
  split policies explicitly
  
  ## Verification
  
  - added regression coverage in `core/src/seatbelt.rs` for unreadable
  carveouts under both full-disk and scoped-readable policies
  - 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/13448).
  * #13453
  * #13452
  * #13451
  * #13449
  * __->__ #13448
  * #13445
  * #13440
  * #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-08 00:35:19 +00:00
  bf5c2f48a5
• 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
• core/protocol: add structured macOS additional permissions and merge them into sandbox execution (#13499)

  ## Summary
  - Introduce strongly-typed macOS additional permissions across
  protocol/core/app-server boundaries.
  - Merge additional permissions into effective sandbox execution,
  including macOS seatbelt profile extensions.
  - Expand docs, schema/tool definitions, UI rendering, and tests for
  `network`, `file_system`, and `macos` additional permissions.

  Celia Chen · 2026-03-05 16:21:45 -08:00
  aaefee04cd
• refactor: prepare unified exec for zsh-fork backend (#13392)

  ## Why
  
  `shell_zsh_fork` already provides stronger guarantees around which
  executables receive elevated permissions. To reuse that machinery from
  unified exec without pushing Unix-specific escalation details through
  generic runtime code, the escalation bootstrap and session lifetime
  handling need a cleaner boundary.
  
  That boundary also needs to be safe for long-lived sessions: when an
  intercepted shell session is closed or pruned, any in-flight approval
  workers and any already-approved escalated child they spawned must be
  torn down with the session, and the inherited escalation socket must not
  leak into unrelated subprocesses.
  
  ## What Changed
  
  - Extracted a reusable `EscalationSession` and
  `EscalateServer::start_session(...)` in `shell-escalation` so callers
  can get the wrapper/socket env overlay and keep the escalation server
  alive without immediately running a one-shot command.
  - Documented that `EscalationSession::env()` and
  `ShellCommandExecutor::run(...)` exchange only that env overlay, which
  callers must merge into their own base shell environment.
  - Clarified the prepared-exec helper boundary in `core` by naming the
  new helper APIs around `ExecRequest`, while keeping the legacy
  `execute_env(...)` entrypoints as thin compatibility wrappers for
  existing callers that still use the older naming.
  - Added a small post-spawn hook on the prepared execution path so the
  parent copy of the inheritable escalation socket is closed immediately
  after both the existing one-shot shell-command spawn and the
  unified-exec spawn.
  - Made session teardown explicit with session-scoped cancellation:
  dropping an `EscalationSession` or canceling its parent request now
  stops intercept workers, and the server-spawned escalated child uses
  `kill_on_drop(true)` so teardown cannot orphan an already-approved
  child.
  - Added `UnifiedExecBackendConfig` plumbing through `ToolsConfig`, a
  `shell::zsh_fork_backend` facade, and an opaque unified-exec
  spawn-lifecycle hook so unified exec can prepare a wrapped `zsh -c/-lc`
  request without storing `EscalationSession` directly in generic
  process/runtime code.
  - Kept the existing `shell_command` zsh-fork behavior intact on top of
  the new bootstrap path. Tool selection is unchanged in this PR: when
  `shell_zsh_fork` is enabled, `ShellCommand` still wins over
  `exec_command`.
  
  ## Verification
  
  - `cargo test -p codex-shell-escalation`
    - includes coverage for `start_session_exposes_wrapper_env_overlay`
    - includes coverage for `exec_closes_parent_socket_after_shell_spawn`
  - includes coverage for
  `dropping_session_aborts_intercept_workers_and_kills_spawned_child`
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-core --test all
  shell_zsh_fork_prompts_for_skill_script_execution`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13392).
  * #13432
  * __->__ #13392

  Michael Bolin · 2026-03-05 08:55:12 +00:00
  b4cb989563
• chore: Nest skill and protocol network permissions under network.enabled (#13427)

  ## Summary
  
  Changes the permission profile shape from a bare network boolean to a
  nested object.
  
  Before:
  
  ```yaml
  permissions:
    network: true
  ```
  
  After:
  
  ```yaml
  permissions:
    network:
      enabled: true
  ```
  
  This also updates the shared Rust and app-server protocol types so
  `PermissionProfile.network` is no longer `Option<bool>`, but
  `Option<NetworkPermissions>` with `enabled: Option<bool>`.
  
  ## What Changed
  
  - Updated `PermissionProfile` in `codex-rs/protocol/src/models.rs`:
  - `pub network: Option<bool>` -> `pub network:
  Option<NetworkPermissions>`
  - Added `NetworkPermissions` with:
    - `pub enabled: Option<bool>`
  - Changed emptiness semantics so `network` is only considered empty when
  `enabled` is `None`
  - Updated skill metadata parsing to accept `permissions.network.enabled`
  - Updated core permission consumers to read
  `network.enabled.unwrap_or(false)` where a concrete boolean is needed
  - Updated app-server v2 protocol types and regenerated schema/TypeScript
  outputs
  - Updated docs to mention `additionalPermissions.network.enabled`

  Celia Chen · 2026-03-03 20:57:29 -08:00
  d622bff384
• 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
• fix: use AbsolutePathBuf for permission profile file roots (#12970)

  ## Why
  `PermissionProfile` should describe filesystem roots as absolute paths
  at the type level. Using `PathBuf` in `FileSystemPermissions` made the
  shared type too permissive and blurred together three different
  deserialization cases:
  
  - skill metadata in `agents/openai.yaml`, where relative paths should
  resolve against the skill directory
  - app-server API payloads, where callers should have to send absolute
  paths
  - local tool-call payloads for commands like `shell_command` and
  `exec_command`, where `additional_permissions.file_system` may
  legitimately be relative to the command `workdir`
  
  This change tightens the shared model without regressing the existing
  local command flow.
  
  ## What Changed
  - changed `protocol::models::FileSystemPermissions` and the app-server
  `AdditionalFileSystemPermissions` mirror to use `AbsolutePathBuf`
  - wrapped skill metadata deserialization in `AbsolutePathBufGuard`, so
  relative permission roots in `agents/openai.yaml` resolve against the
  containing skill directory
  - kept app-server/API deserialization strict, so relative
  `additionalPermissions.fileSystem.*` paths are rejected at the boundary
  - restored cwd/workdir-relative deserialization for local tool-call
  payloads by parsing `shell`, `shell_command`, and `exec_command`
  arguments under an `AbsolutePathBufGuard` rooted at the resolved command
  working directory
  - simplified runtime additional-permission normalization so it only
  canonicalizes and deduplicates absolute roots instead of trying to
  recover relative ones later
  - updated the app-server schema fixtures, `app-server/README.md`, and
  the affected transport/TUI tests to match the final behavior

  Michael Bolin · 2026-02-27 17:42:52 +00:00
  d09a7535ed
• feat: include sandbox config with escalation request (#12839)

  ## Why
  
  Before this change, an escalation approval could say that a command
  should be rerun, but it could not carry the sandbox configuration that
  should still apply when the escalated command is actually spawned.
  
  That left an unsafe gap in the `zsh-fork` skill path: skill scripts
  under `scripts/` that did not declare permissions could be escalated
  without a sandbox, and scripts that did declare permissions could lose
  their bounded sandbox on rerun or cached session approval.
  
  This PR extends the escalation protocol so approvals can optionally
  carry sandbox configuration all the way through execution. That lets the
  shell runtime preserve the intended sandbox instead of silently widening
  access.
  
  We likely want a single permissions type for this codepath eventually,
  probably centered on `Permissions`. For now, the protocol needs to
  represent both the existing `PermissionProfile` form and the fuller
  `Permissions` form, so this introduces a temporary disjoint union,
  `EscalationPermissions`, to carry either one.
  
  Further, this means that today, a skill either:
  
  - does not declare any permissions, in which case it is run using the
  default sandbox for the turn
  - specifies permissions, in which case the skill is run using that exact
  sandbox, which might be more restrictive than the default sandbox for
  the turn
  
  We will likely change the skill's permissions to be additive to the
  existing permissions for the turn.
  
  ## What Changed
  
  - Added `EscalationPermissions` to `codex-protocol` so escalation
  requests can carry either a `PermissionProfile` or a full `Permissions`
  payload.
  - Added an explicit `EscalationExecution` mode to the shell escalation
  protocol so reruns distinguish between `Unsandboxed`, `TurnDefault`, and
  `Permissions(...)` instead of overloading `None`.
  - Updated `zsh-fork` shell reruns to resolve `TurnDefault` at execution
  time, which keeps ordinary `UseDefault` commands on the turn sandbox and
  preserves turn-level macOS seatbelt profile extensions.
  - Updated the `zsh-fork` skill path so a skill with no declared
  permissions inherits the conversation's effective sandbox instead of
  escalating unsandboxed.
  - Updated the `zsh-fork` skill path so a skill with declared permissions
  reruns with exactly those permissions, including when a cached session
  approval is reused.
  
  ## Testing
  
  - Added unit coverage in
  `core/src/tools/runtimes/shell/unix_escalation.rs` for the explicit
  `UseDefault` / `RequireEscalated` / `WithAdditionalPermissions`
  execution mapping.
  - Added unit coverage in
  `core/src/tools/runtimes/shell/unix_escalation.rs` for macOS seatbelt
  extension preservation in both the `TurnDefault` and
  explicit-permissions rerun paths.
  - Added integration coverage in `core/tests/suite/skill_approval.rs` for
  permissionless skills inheriting the turn sandbox and explicit skill
  permissions remaining bounded across cached approval reuse.

  Michael Bolin · 2026-02-26 12:00:18 -08:00
  7fa9d9ae35
• chore: migrate additional permissions to PermissionProfile (#12731)

  This PR replaces the old `additional_permissions.fs_read/fs_write` shape
  with a shared `PermissionProfile`
  model and wires it through the command approval, sandboxing, protocol,
  and TUI layers. The schema is adopted from the
  `SkillManifestPermissions`, which is also refactored to use this unified
  struct. This helps us easily expose permission profiles in app
  server/core as a follow-up.

  Celia Chen · 2026-02-25 03:35:28 +00:00
  16ca527c80
• refactor: remove unused seatbelt unix socket arg (#12707)

  https://github.com/openai/codex/pull/12052 introduced an
  `allowed_unix_socket_paths` parameter to
  `create_seatbelt_command_args()`, but
  https://github.com/openai/codex/pull/12649 removed the abstraction that
  #12052 introduced, so this parameter is no longer necessary as it is
  always an empty slice.

  Michael Bolin · 2026-02-24 12:30:26 -08:00
  3b5fc7547e
• feat: run zsh fork shell tool via shell-escalation (#12649)

  ## Why
  
  This PR switches the `shell_command` zsh-fork path over to
  `codex-shell-escalation` so the new shell tool can use the shared
  exec-wrapper/escalation protocol instead of the `zsh_exec_bridge`
  implementation that was introduced in
  https://github.com/openai/codex/pull/12052. `zsh_exec_bridge` relied on
  UNIX domain sockets, which is not as tamper-proof as the FD-based
  approach in `codex-shell-escalation`.
  
  ## What Changed
  
  - Added a Unix zsh-fork runtime adapter in `core`
  (`core/src/tools/runtimes/shell/unix_escalation.rs`) that:
  - runs zsh-fork commands through
  `codex_shell_escalation::run_escalate_server`
    - bridges exec-policy / approval decisions into `ShellActionProvider`
  - executes escalated commands via a `ShellCommandExecutor` that calls
  `process_exec_tool_call`
  - Updated `ShellRuntime` / `ShellCommandHandler` / tool spec wiring to
  select a `shell_command` backend (`classic` vs `zsh-fork`) while leaving
  the generic `shell` tool path unchanged.
  - Removed the `zsh_exec_bridge`-based session service and deleted
  `core/src/zsh_exec_bridge/mod.rs`.
  - Moved exec-wrapper entrypoint dispatch to `arg0` by handling the
  `codex-execve-wrapper` arg0 alias there, and removed the old
  `codex_core::maybe_run_zsh_exec_wrapper_mode()` hooks from `cli` and
  `app-server` mains.
  - Added the needed `codex-shell-escalation` dependencies for `core` and
  `arg0`.
  
  ## Tests
  
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-app-server turn_start_shell_zsh_fork --
  --nocapture`
  - verifies zsh-fork command execution and approval flows through the new
  backend
  - includes subcommand approve/decline coverage using the shared zsh
  DotSlash fixture in `app-server/tests/suite/zsh`
  - To test manually, I added the following to `~/.codex/config.toml`:
  
  ```toml
  zsh_path = "/Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh"
  
  [features]
  shell_zsh_fork = true
  ```
  
  Then I ran `just c` to run the dev build of Codex with these changes and
  sent it the message:
  
  ```
  run `echo $0`
  ```
  
  And it replied with:
  
  ```
    echo $0 printed:
  
    /Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh
  
    In this tool context, $0 reflects the script path used to invoke the shell, not just zsh.
  ```
  
  so the tool appears to be wired up correctly.
  
  ## Notes
  
  - The zsh subcommand-decline integration test now uses `rm` under a
  `WorkspaceWrite` sandbox. The previous `/usr/bin/true` scenario is
  auto-allowed by the new `shell-escalation` policy path, which no longer
  produces subcommand approval prompts.

  Michael Bolin · 2026-02-24 10:31:08 -08:00
  3ca0e7673b
• feat(core) Introduce Feature::RequestPermissions (#11871)

  ## Summary
  Introduces the initial implementation of Feature::RequestPermissions.
  RequestPermissions allows the model to request that a command be run
  inside the sandbox, with additional permissions, like writing to a
  specific folder. Eventually this will include other rules as well, and
  the ability to persist these permissions, but this PR is already quite
  large - let's get the core flow working and go from there!
  
  <img width="1279" height="541" alt="Screenshot 2026-02-15 at 2 26 22 PM"
  src="https://github.com/user-attachments/assets/0ee3ec0f-02ec-4509-91a2-809ac80be368"
  />
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally
  - [x] Feature

  Dylan Hurd · 2026-02-24 09:48:57 -08:00
  f6053fdfb3
• 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
• feat(core): zsh exec bridge (#12052)

  zsh fork PR stack:
  - https://github.com/openai/codex/pull/12051 
  - https://github.com/openai/codex/pull/12052 👈 
  
  ### Summary
  This PR introduces a feature-gated native shell runtime path that routes
  shell execution through a patched zsh exec bridge, removing MCP-specific
  behavior from the shell hot path while preserving existing
  CommandExecution lifecycle semantics.
  
  When shell_zsh_fork is enabled, shell commands run via patched zsh with
  per-`execve` interception through EXEC_WRAPPER. Core receives wrapper
  IPC requests over a Unix socket, applies existing approval policy, and
  returns allow/deny before the subcommand executes.
  
  ### What’s included
  **1) New zsh exec bridge runtime in core**
  - Wrapper-mode entrypoint (maybe_run_zsh_exec_wrapper_mode) for
  EXEC_WRAPPER invocations.
  - Per-execution Unix-socket IPC handling for wrapper requests/responses.
  - Approval callback integration using existing core approval
  orchestration.
  - Streaming stdout/stderr deltas to existing command output event
  pipeline.
  - Error handling for malformed IPC, denial/abort, and execution
  failures.
  
  **2) Session lifecycle integration**
  SessionServices now owns a `ZshExecBridge`.
  Session startup initializes bridge state; shutdown tears it down
  cleanly.
  
  **3) Shell runtime routing (feature-gated)**
  When `shell_zsh_fork` is enabled:
  - Build execution env/spec as usual.
  - Add wrapper socket env wiring.
  - Execute via `zsh_exec_bridge.execute_shell_request(...)` instead of
  the regular shell path.
  - Non-zsh-fork behavior remains unchanged.
  
  **4) Config + feature wiring**
  - Added `Feature::ShellZshFork` (under development).
  - Added config support for `zsh_path` (optional absolute path to patched
  zsh):
  - `Config`, `ConfigToml`, `ConfigProfile`, overrides, and schema.
  - Session startup validates that `zsh_path` exists/usable when zsh-fork
  is enabled.
  - Added startup test for missing `zsh_path` failure mode.
  
  **5) Seatbelt/sandbox updates for wrapper IPC**
  - Extended seatbelt policy generation to optionally allow outbound
  connection to explicitly permitted Unix sockets.
  - Wired sandboxing path to pass wrapper socket path through to seatbelt
  policy generation.
  - Added/updated seatbelt tests for explicit socket allow rule and
  argument emission.
  
  **6) Runtime entrypoint hooks**
  - This allows the same binary to act as the zsh wrapper subprocess when
  invoked via `EXEC_WRAPPER`.
  
  **7) Tool selection behavior**
  - ToolsConfig now prefers ShellCommand type when shell_zsh_fork is
  enabled.
  - Added test coverage for precedence with unified-exec enabled.

  Owen Lin · 2026-02-17 20:19:53 -08:00
  edacbf7b6e
• 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
• feat(sandbox): enforce proxy-aware network routing in sandbox (#11113)

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

  viyatb-oai · 2026-02-10 07:44:21 +00:00
  3391e5ea86
• feat: 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
• 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
• 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
• feat: introduce ExternalSandbox policy (#8290)

  ## Description
  
  Introduced `ExternalSandbox` policy to cover use case when sandbox
  defined by outside environment, effectively it translates to
  `SandboxMode#DangerFullAccess` for file system (since sandbox configured
  on container level) and configurable `network_access` (either Restricted
  or Enabled by outside environment).
  
  as example you can configure `ExternalSandbox` policy as part of
  `sendUserTurn` v1 app_server API:
  
  ```
   {
              "conversationId": <id>,
              "cwd": <cwd>,
              "approvalPolicy": "never",
              "sandboxPolicy": {
                    "type": ""external-sandbox",
                    "network_access": "enabled"/"restricted"
              },
              "model": <model>,
              "effort": <effort>,
              ....
          }
  ```

  Anton Panasenko · 2025-12-18 17:02:03 -08:00
  3429de21b3
• better name for windows sandbox features (#8077)

  `--enable enable...` is a bad look

  iceweasel-oai · 2025-12-15 10:15:40 -08:00
  b4635ccc07
• Removed experimental "command risk assessment" feature (#7799)

  This experimental feature received lukewarm reception during internal
  testing. Removing from the code base.

  Eric Traut · 2025-12-10 09:48:11 -08:00
  c4af707e09
• 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