43 Commits

• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• Extract sandbox manager and transforms into codex-sandboxing (#15603)

  Extract sandbox manager

  pakrym-oai · 2026-03-24 08:20:57 -07:00
  f49eb8e9d7
• Rename reject approval policy to granular (#14516)
  Jack Mousseau · 2026-03-12 16:38:04 -07:00
  b7dba72dbd
• 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
• fix: align core approvals with split sandbox policies (#14171)

  ## Stack
  
     fix: fail closed for unsupported split windows sandboxing #14172
     fix: preserve split filesystem semantics in linux sandbox #14173
  -> fix: align core approvals with split sandbox policies #14171
     refactor: centralize filesystem permissions precedence #14174
  
  ## Why This PR Exists
  
  This PR is intentionally narrower than the title may suggest.
  
  Most of the original split-permissions migration already landed in the
  earlier `#13434 -> #13453` stack. In particular:
  
  - `#13439` already did the broad runtime plumbing for split filesystem
  and network policies.
  - `#13445` already moved `apply_patch` safety onto filesystem-policy
  semantics.
  - `#13448` already switched macOS Seatbelt generation to split policies.
  - `#13449` and `#13453` already handled Linux helper and bubblewrap
  enforcement.
  - `#13440` already introduced the first protocol-side helpers for
  deriving effective filesystem access.
  
  The reason this PR still exists is that after the follow-on
  `[permissions]` work and the new shared precedence helper in `#14174`, a
  few core approval paths were still deciding behavior from the legacy
  `SandboxPolicy` projection instead of the split filesystem policy that
  actually carries the carveouts.
  
  That means this PR is mostly a cleanup and alignment pass over the
  remaining core consumers, not a fresh sandbox backend migration.
  
  ## What Is Actually New Here
  
  - make unmatched-command fallback decisions consult
  `FileSystemSandboxPolicy` instead of only legacy `DangerFullAccess` /
  `ReadOnly` / `WorkspaceWrite` categories
  - thread `file_system_sandbox_policy` into the shell, unified-exec, and
  intercepted-exec approval paths so they all use the same split-policy
  semantics
  - keep `apply_patch` safety on the same effective-access rules as the
  shared protocol helper, rather than letting it drift through
  compatibility projections
  - add loader-level regression coverage proving legacy `sandbox_mode`
  config still builds split policies and round-trips back without semantic
  drift
  
  ## What This PR Does Not Do
  
  This PR does not introduce new platform backend enforcement on its own.
  
  - Linux backend parity remains in `#14173`.
  - Windows fail-closed handling remains in `#14172`.
  - The shared precedence/model changes live in `#14174`.
  
  ## Files To Focus On
  
  - `core/src/exec_policy.rs`: unmatched-command fallback and approval
  rendering now read the split filesystem policy directly
  - `core/src/tools/sandboxing.rs`: default exec-approval requirement keys
  off `FileSystemSandboxPolicy.kind`
  - `core/src/tools/handlers/shell.rs`: shell approval requests now carry
  the split filesystem policy
  - `core/src/unified_exec/process_manager.rs`: unified-exec approval
  requests now carry the split filesystem policy
  - `core/src/tools/runtimes/shell/unix_escalation.rs`: intercepted exec
  fallback now uses the same split-policy approval semantics
  - `core/src/safety.rs`: `apply_patch` safety keeps using effective
  filesystem access rather than legacy sandbox categories
  - `core/src/config/config_tests.rs`: new regression coverage for legacy
  `sandbox_mode` no-drift behavior through the split-policy loader
  
  ## Notes
  
  - `core/src/codex.rs` and `core/src/codex_tests.rs` are just small
  fallout updates for `RequestPermissionsResponse.scope`; they are not the
  point of the PR.
  - If you reviewed the earlier `#13439` / `#13445` stack, the main review
  question here is simply: “are there any remaining approval or
  patch-safety paths that still reconstruct semantics from legacy
  `SandboxPolicy` instead of consuming the split filesystem policy
  directly?”
  
  ## Testing
  - cargo test -p codex-core
  legacy_sandbox_mode_config_builds_split_policies_without_drift
  - cargo test -p codex-core request_permissions
  - cargo test -p codex-core intercepted_exec_policy
  - cargo test -p codex-core
  restricted_sandbox_requires_exec_approval_on_request
  - cargo test -p codex-core
  unmatched_on_request_uses_split_filesystem_policy_for_escalation_prompts
  - cargo test -p codex-core explicit_
  - cargo clippy -p codex-core --tests -- -D warnings

  viyatb-oai · 2026-03-12 02:23:22 +00:00
  c2d5458d67
• chore: add a separate reject-policy flag for skill approvals (#14271)

  ## Summary
  - add `skill_approval` to `RejectConfig` and the app-server v2
  `AskForApproval::Reject` payload so skill-script prompts can be
  configured independently from sandbox and rule-based prompts
  - update Unix shell escalation to reject prompts based on the actual
  decision source, keeping prefix rules tied to `rules`, unmatched command
  fallbacks tied to `sandbox_approval`, and skill scripts tied to
  `skill_approval`
  - regenerate the affected protocol/config schemas and expand
  unit/integration coverage for the new flag and skill approval behavior

  Celia Chen · 2026-03-11 12:33:09 -07:00
  c1a424691f
• fix(protocol): preserve legacy workspace-write semantics (#13957)

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

  viyatb-oai · 2026-03-09 18:43:27 -07:00
  b0cbc25a48
• feat(approvals) RejectConfig for request_permissions (#14118)

  ## Summary
  We need to support allowing request_permissions calls when using
  `Reject` policy
  
  <img width="1133" height="588" alt="Screenshot 2026-03-09 at 12 06
  40 PM"
  src="https://github.com/user-attachments/assets/a8df987f-c225-4866-b8ab-5590960daec5"
  />
  
  Note that this is a backwards-incompatible change for Reject policy. I'm
  not sure if we need to add a default based on our current use/setup
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally

  Dylan Hurd · 2026-03-09 18:16:54 -07:00
  6da84efed8
• Add guardian approval MVP (#13692)

  ## Summary
  - add the guardian reviewer flow for `on-request` approvals in command,
  patch, sandbox-retry, and managed-network approval paths
  - keep guardian behind `features.guardian_approval` instead of exposing
  a public `approval_policy = guardian` mode
  - route ordinary `OnRequest` approvals to the guardian subagent when the
  feature is enabled, without changing the public approval-mode surface
  
  ## Public model
  - public approval modes stay unchanged
  - guardian is enabled via `features.guardian_approval`
  - when that feature is on, `approval_policy = on-request` keeps the same
  approval boundaries but sends those approval requests to the guardian
  reviewer instead of the user
  - `/experimental` only persists the feature flag; it does not rewrite
  `approval_policy`
  - CLI and app-server no longer expose a separate `guardian` approval
  mode in this PR
  
  ## Guardian reviewer
  - the reviewer runs as a normal subagent and reuses the existing
  subagent/thread machinery
  - it is locked to a read-only sandbox and `approval_policy = never`
  - it does not inherit user/project exec-policy rules
  - it prefers `gpt-5.4` when the current provider exposes it, otherwise
  falls back to the parent turn's active model
  - it fail-closes on timeout, startup failure, malformed output, or any
  other review error
  - it currently auto-approves only when `risk_score < 80`
  
  ## Review context and policy
  - guardian mirrors `OnRequest` approval semantics rather than
  introducing a separate approval policy
  - explicit `require_escalated` requests follow the same approval surface
  as `OnRequest`; the difference is only who reviews them
  - managed-network allowlist misses that enter the approval flow are also
  reviewed by guardian
  - the review prompt includes bounded recent transcript history plus
  recent tool call/result evidence
  - transcript entries and planned-action strings are truncated with
  explicit `<guardian_truncated ... />` markers so large payloads stay
  bounded
  - apply-patch reviews include the full patch content (without
  duplicating the structured `changes` payload)
  - the guardian request layout is snapshot-tested using the same
  model-visible Responses request formatter used elsewhere in core
  
  ## Guardian network behavior
  - the guardian subagent inherits the parent session's managed-network
  allowlist when one exists, so it can use the same approved network
  surface while reviewing
  - exact session-scoped network approvals are copied into the guardian
  session with protocol/port scope preserved
  - those copied approvals are now seeded before the guardian's first turn
  is submitted, so inherited approvals are available during any immediate
  review-time checks
  
  ## Out of scope / follow-ups
  - the sandbox-permission validation split was pulled into a separate PR
  and is not part of this diff
  - a future follow-up can enable `serde_json` preserve-order in
  `codex-core` and then simplify the guardian action rendering further
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-07 05:40:10 -08:00
  e84ee33cc0
• safety: honor filesystem policy carveouts in apply_patch (#13445)

  ## Why
  
  `apply_patch` safety approval was still checking writable paths through
  the legacy `SandboxPolicy` projection.
  
  That can hide explicit `none` carveouts when a split filesystem policy
  projects back to compatibility `ExternalSandbox`, which leaves one more
  approval path that can auto-approve writes inside paths that are
  intentionally blocked.
  
  ## What changed
  
  - passed `turn.file_system_sandbox_policy` into `assess_patch_safety`
  - changed writable-path checks to derive effective access from
  `FileSystemSandboxPolicy` instead of the legacy `SandboxPolicy`
  - made those checks reject explicit unreadable roots before considering
  broad write access or writable roots
  - added regression coverage showing that an `ExternalSandbox`
  compatibility projection still asks for approval when the split
  filesystem policy blocks a subpath
  
  ## Verification
  
  - `cargo test -p codex-core safety::tests::`
  - `cargo test -p codex-core test_sandbox_config_parsing`
  - `cargo clippy -p codex-core --all-targets -- -D warnings`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13445).
  * #13453
  * #13452
  * #13451
  * #13449
  * #13448
  * __->__ #13445
  * #13440
  * #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 08:01:08 +00:00
  5ceff6588e
• feat: add Reject approval policy with granular prompt rejection controls (#12087)

  ## Why
  
  We need a way to auto-reject specific approval prompt categories without
  switching all approvals off.
  
  The goal is to let users independently control:
  - sandbox escalation approvals,
  - execpolicy `prompt` rule approvals,
  - MCP elicitation prompts.
  
  ## What changed
  
  - Added a new primary approval mode in `protocol/src/protocol.rs`:
  
  ```rust
  pub enum AskForApproval {
      // ...
      Reject(RejectConfig),
      // ...
  }
  
  pub struct RejectConfig {
      pub sandbox_approval: bool,
      pub rules: bool,
      pub mcp_elicitations: bool,
  }
  ```
  
  - Wired `RejectConfig` semantics through approval paths in `core`:
    - `core/src/exec_policy.rs`
      - rejects rule-driven prompts when `rules = true`
      - rejects sandbox/escalation prompts when `sandbox_approval = true`
  - preserves rule priority when both rule and sandbox prompt conditions
  are present
    - `core/src/tools/sandboxing.rs`
  - applies `sandbox_approval` to default exec approval decisions and
  sandbox-failure retry gating
    - `core/src/safety.rs`
  - keeps `Reject { all false }` behavior aligned with `OnRequest` for
  patch safety
      - rejects out-of-root patch approvals when `sandbox_approval = true`
    - `core/src/mcp_connection_manager.rs`
      - auto-declines MCP elicitations when `mcp_elicitations = true`
  
  - Ensured approval policy used by MCP elicitation flow stays in sync
  with constrained session policy updates.
  
  - Updated app-server v2 conversions and generated schema/TypeScript
  artifacts for the new `Reject` shape.
  
  ## Verification
  
  Added focused unit coverage for the new behavior in:
  - `core/src/exec_policy.rs`
  - `core/src/tools/sandboxing.rs`
  - `core/src/mcp_connection_manager.rs`
  - `core/src/safety.rs`
  - `core/src/tools/runtimes/apply_patch.rs`
  
  Key cases covered include rule-vs-sandbox prompt precedence, MCP
  auto-decline behavior, and patch/sandbox retry behavior under
  `RejectConfig`.

  Michael Bolin · 2026-02-19 11:41:49 -08:00
  425fff7ad6
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

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

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• 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
• fix: implement 'Allow this session' for apply_patch approvals (#8451)

  **Summary**
  This PR makes “ApprovalDecision::AcceptForSession / don’t ask again this
  session” actually work for `apply_patch` approvals by caching approvals
  based on absolute file paths in codex-core, properly wiring it through
  app-server v2, and exposing the choice in both TUI and TUI2.
  - This brings `apply_patch` calls to be at feature-parity with general
  shell commands, which also have a "Yes, and don't ask again" option.
  - This also fixes VSCE's "Allow this session" button to actually work.
  
  While we're at it, also split the app-server v2 protocol's
  `ApprovalDecision` enum so execpolicy amendments are only available for
  command execution approvals.
  
  **Key changes**
  - Core: per-session patch approval allowlist keyed by absolute file
  paths
  - Handles multi-file patches and renames/moves by recording both source
  and destination paths for `Update { move_path: Some(...) }`.
  - Extend the `Approvable` trait and `ApplyPatchRuntime` to work with
  multiple keys, because an `apply_patch` tool call can modify multiple
  files. For a request to be auto-approved, we will need to check that all
  file paths have been approved previously.
  - App-server v2: honor AcceptForSession for file changes
  - File-change approval responses now map AcceptForSession to
  ReviewDecision::ApprovedForSession (no longer downgraded to plain
  Approved).
  - Replace `ApprovalDecision` with two enums:
  `CommandExecutionApprovalDecision` and `FileChangeApprovalDecision`
  - TUI / TUI2: expose “don’t ask again for these files this session”
  - Patch approval overlays now include a third option (“Yes, and don’t
  ask again for these files this session (s)”).
      - Snapshot updates for the approval modal.
  
  **Tests added/updated**
  - Core:
  - Integration test that proves ApprovedForSession on a patch skips the
  next patch prompt for the same file
  - App-server:
  - v2 integration test verifying
  FileChangeApprovalDecision::AcceptForSession works properly
  
  **User-visible behavior**
  - When the user approves a patch “for session”, future patches touching
  only those previously approved file(s) will no longer prompt gain during
  that session (both via app-server v2 and TUI/TUI2).
  
  **Manual testing**
  Tested both TUI and TUI2 - see screenshots below.
  
  TUI:
  <img width="1082" height="355" alt="image"
  src="https://github.com/user-attachments/assets/adcf45ad-d428-498d-92fc-1a0a420878d9"
  />
  
  
  TUI2:
  <img width="1089" height="438" alt="image"
  src="https://github.com/user-attachments/assets/dd768b1a-2f5f-4bd6-98fd-e52c1d3abd9e"
  />

  Owen Lin · 2026-01-07 20:11:12 +00:00
  66450f0445
• 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
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

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

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• Elevated Sandbox 4 (#7889)
  iceweasel-oai · 2025-12-12 12:30:38 -08:00
  677732ff65
• feat: intercept apply_patch for unified_exec (#7446)
  jif-oai · 2025-12-02 17:54:02 +00:00
  72b95db12f
• Windows Sandbox - Alpha version (#4905)

  - Added the new codex-windows-sandbox crate that builds both a library
  entry point (run_windows_sandbox_capture) and a CLI executable to launch
  commands inside a Windows restricted-token sandbox, including ACL
  management, capability SID provisioning, network lockdown, and output
  capture
  (windows-sandbox-rs/src/lib.rs:167, windows-sandbox-rs/src/main.rs:54).
  - Introduced the experimental WindowsSandbox feature flag and wiring so
  Windows builds can opt into the sandbox:
  SandboxType::WindowsRestrictedToken, the in-process execution path, and
  platform sandbox selection now honor the flag (core/src/features.rs:47,
  core/src/config.rs:1224, core/src/safety.rs:19,
  core/src/sandboxing/mod.rs:69, core/src/exec.rs:79,
  core/src/exec.rs:172).
  - Updated workspace metadata to include the new crate and its
  Windows-specific dependencies so the core crate can link against it
  (codex-rs/
      Cargo.toml:91, core/Cargo.toml:86).
  - Added a PowerShell bootstrap script that installs the Windows
  toolchain, required CLI utilities, and builds the workspace to ease
  development
      on the platform (scripts/setup-windows.ps1:1).
  - Landed a Python smoke-test suite that exercises
  read-only/workspace-write policies, ACL behavior, and network denial for
  the Windows sandbox
      binary (windows-sandbox-rs/sandbox_smoketests.py:1).

  iceweasel-oai · 2025-10-30 15:51:57 -07:00
  87cce88f48
• chore: rework tools execution workflow (#5278)

  Re-work the tool execution flow. Read `orchestrator.rs` to understand
  the structure

  jif-oai · 2025-10-20 20:57:37 +01:00
  5e4f3bbb0b
• chore: sandbox refactor 2 (#4653)

  Revert the revert and fix the UI issue

  jif-oai · 2025-10-03 11:17:39 +01:00
  69cb72f842
• Revert "chore: sanbox extraction" (#4626)

  Reverts openai/codex#4286

  Ahmed Ibrahim · 2025-10-02 21:09:21 +00:00
  ed5d656fa8
• chore: sanbox extraction (#4286)

  # Extract and Centralize Sandboxing
  - Goal: Improve safety and clarity by centralizing sandbox planning and
  execution.
    - Approach:
  - Add planner (ExecPlan) and backend registry (Direct/Seatbelt/Linux)
  with run_with_plan.
  - Refactor codex.rs to plan-then-execute; handle failures/escalation via
  the plan.
  - Delegate apply_patch to the codex binary and run it with an empty env
  for determinism.

  jif-oai · 2025-10-01 12:05:12 +01:00
  b8195a17e5
• OpenTelemetry events (#2103)

  ### Title
  
  ## otel
  
  Codex can emit [OpenTelemetry](https://opentelemetry.io/) **log events**
  that
  describe each run: outbound API requests, streamed responses, user
  input,
  tool-approval decisions, and the result of every tool invocation. Export
  is
  **disabled by default** so local runs remain self-contained. Opt in by
  adding an
  `[otel]` table and choosing an exporter.
  
  ```toml
  [otel]
  environment = "staging"   # defaults to "dev"
  exporter = "none"          # defaults to "none"; set to otlp-http or otlp-grpc to send events
  log_user_prompt = false    # defaults to false; redact prompt text unless explicitly enabled
  ```
  
  Codex tags every exported event with `service.name = "codex-cli"`, the
  CLI
  version, and an `env` attribute so downstream collectors can distinguish
  dev/staging/prod traffic. Only telemetry produced inside the
  `codex_otel`
  crate—the events listed below—is forwarded to the exporter.
  
  ### Event catalog
  
  Every event shares a common set of metadata fields: `event.timestamp`,
  `conversation.id`, `app.version`, `auth_mode` (when available),
  `user.account_id` (when available), `terminal.type`, `model`, and
  `slug`.
  
  With OTEL enabled Codex emits the following event types (in addition to
  the
  metadata above):
  
  - `codex.api_request`
    - `cf_ray` (optional)
    - `attempt`
    - `duration_ms`
    - `http.response.status_code` (optional)
    - `error.message` (failures)
  - `codex.sse_event`
    - `event.kind`
    - `duration_ms`
    - `error.message` (failures)
    - `input_token_count` (completion only)
    - `output_token_count` (completion only)
    - `cached_token_count` (completion only, optional)
    - `reasoning_token_count` (completion only, optional)
    - `tool_token_count` (completion only)
  - `codex.user_prompt`
    - `prompt_length`
    - `prompt` (redacted unless `log_user_prompt = true`)
  - `codex.tool_decision`
    - `tool_name`
    - `call_id`
  - `decision` (`approved`, `approved_for_session`, `denied`, or `abort`)
    - `source` (`config` or `user`)
  - `codex.tool_result`
    - `tool_name`
    - `call_id`
    - `arguments`
    - `duration_ms` (execution time for the tool)
    - `success` (`"true"` or `"false"`)
    - `output`
  
  ### Choosing an exporter
  
  Set `otel.exporter` to control where events go:
  
  - `none` – leaves instrumentation active but skips exporting. This is
  the
    default.
  - `otlp-http` – posts OTLP log records to an OTLP/HTTP collector.
  Specify the
    endpoint, protocol, and headers your collector expects:
  
    ```toml
    [otel]
    exporter = { otlp-http = {
      endpoint = "https://otel.example.com/v1/logs",
      protocol = "binary",
      headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
    }}
    ```
  
  - `otlp-grpc` – streams OTLP log records over gRPC. Provide the endpoint
  and any
    metadata headers:
  
    ```toml
    [otel]
    exporter = { otlp-grpc = {
      endpoint = "https://otel.example.com:4317",
      headers = { "x-otlp-meta" = "abc123" }
    }}
    ```
  
  If the exporter is `none` nothing is written anywhere; otherwise you
  must run or point to your
  own collector. All exporters run on a background batch worker that is
  flushed on
  shutdown.
  
  If you build Codex from source the OTEL crate is still behind an `otel`
  feature
  flag; the official prebuilt binaries ship with the feature enabled. When
  the
  feature is disabled the telemetry hooks become no-ops so the CLI
  continues to
  function without the extra dependencies.
  
  ---------
  
  Co-authored-by: Anton Panasenko <apanasenko@openai.com>

  vishnu-oai · 2025-09-29 11:30:55 -07:00
  04c1782e52
• reject dangerous commands for AskForApproval::Never (#4307)

  If we detect a dangerous command but approval_policy is Never, simply
  reject the command.

  iceweasel-oai · 2025-09-26 14:08:28 -07:00
  55801700de
• core: add potentially dangerous command check (#4211)

  Certain shell commands are potentially dangerous, and we want to check
  for them.
  Unless the user has explicitly approved a command, we will *always* ask
  them for approval
  when one of these commands is encountered, regardless of whether they
  are in a sandbox, or what their approval policy is.
  
  The first (of probably many) such examples is `git reset --hard`. We
  will be conservative and check for any `git reset`

  iceweasel-oai · 2025-09-25 19:46:20 -07:00
  eb2b739d6a
• chore: enable clippy::redundant_clone (#3489)

  Created this PR by:
  
  - adding `redundant_clone` to `[workspace.lints.clippy]` in
  `cargo-rs/Cargol.toml`
  - running `cargo clippy --tests --fix`
  - running `just fmt`
  
  Though I had to clean up one instance of the following that resulted:
  
  ```rust
  let codex = codex;
  ```

  Michael Bolin · 2025-09-11 11:59:37 -07:00
  bec51f6c05
• Auto-approve DangerFullAccess patches on non-sandboxed platforms (#2988)

  **What?**
  Auto-approve patches when `SandboxPolicy::DangerFullAccess` is enabled
  on platforms without sandbox support.
  Changes in `codex-rs/core/src/safety.rs`: return
  `SafetyCheck::AutoApprove { sandbox_type: SandboxType::None }` when no
  sandbox is available and DangerFullAccess is set.
  
  **Why?**
  On platforms lacking sandbox support, requiring explicit user approval
  despite `DangerFullAccess` being explicitly enabled adds friction
  without additional safety. This aligns behavior with the stated policy
  intent.
  
  **How?**
  Extend `assess_patch_safety` match:
  
  * If `get_platform_sandbox()` returns `Some`, keep `AutoApprove {
  sandbox_type }`.
  * If `None` **and** `SandboxPolicy::DangerFullAccess`, return
  `AutoApprove { SandboxType::None }`.
  * Otherwise, fall back to `AskUser`.
  
  **Tests**
  
  * Local checks:
    ```bash
  cargo test && cargo clippy --tests && cargo fmt -- --config
  imports_granularity=Item
    ```
  (Additionally: `just fmt`, `just fix -p codex-core`, `cargo check -p
  codex-core`.)
  
  **Docs**
  No user-facing CLI changes. No README/help updates needed.
  
  **Risk/Impact**
  Reduces prompts on non-sandboxed platforms when DangerFullAccess is
  explicitly chosen; consistent with policy semantics.
  
  ---------
  
  Co-authored-by: Michael Bolin <bolinfest@gmail.com>

  Sing303 · 2025-09-03 10:57:47 -07:00
  0e827b6598
• rework message styling (#2877)

  https://github.com/user-attachments/assets/cf07f62b-1895-44bb-b9c3-7a12032eb371

  Jeremy Rose · 2025-09-02 17:29:58 +00:00
  e442ecedab
• chore: upgrade to Rust 1.89 (#2465)

  Codex created this PR from the following prompt:
  
  > upgrade this entire repo to Rust 1.89. Note that this requires
  updating codex-rs/rust-toolchain.toml as well as the workflows in
  .github/. Make sure that things are "clippy clean" as this change will
  likely uncover new Clippy errors. `just fmt` and `cargo clippy --tests`
  are sufficient to check for correctness
  
  Note this modifies a lot of lines because it folds nested `if`
  statements using `&&`.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/2465).
  * #2467
  * __->__ #2465

  Michael Bolin · 2025-08-19 13:22:02 -07:00
  50c48e88f5
• fix: tighten up checks against writable folders for SandboxPolicy (#2338)

  I was looking at the implementation of `Session::get_writable_roots()`,
  which did not seem right, as it was a copy of writable roots, which is
  not guaranteed to be in sync with the `sandbox_policy` field.
  
  I looked at who was calling `get_writable_roots()` and its only call
  site was `apply_patch()` in `codex-rs/core/src/apply_patch.rs`, which
  took the roots and forwarded them to `assess_patch_safety()` in
  `safety.rs`. I updated `assess_patch_safety()` to take `sandbox_policy:
  &SandboxPolicy` instead of `writable_roots: &[PathBuf]` (and replaced
  `Session::get_writable_roots()` with `Session::get_sandbox_policy()`).
  
  Within `safety.rs`, it was fairly easy to update
  `is_write_patch_constrained_to_writable_paths()` to work with
  `SandboxPolicy`, and in particular, it is far more accurate because, for
  better or worse, `SandboxPolicy::get_writable_roots_with_cwd()` _returns
  an empty vec_ for `SandboxPolicy::DangerFullAccess`, suggesting that
  _nothing_ is writable when in reality _everything_ is writable. With
  this PR, `is_write_patch_constrained_to_writable_paths()` now does the
  right thing for each variant of `SandboxPolicy`.
  
  I thought this would be the end of the story, but it turned out that
  `test_writable_roots_constraint()` in `safety.rs` needed to be updated,
  as well. In particular, the test was writing to
  `std::env::current_dir()` instead of a `TempDir`, which I suspect was a
  holdover from earlier when `SandboxPolicy::WorkspaceWrite` would always
  make `TMPDIR` writable on macOS, which made it hard to write tests to
  verify `SandboxPolicy` in `TMPDIR`. Fortunately, we now have
  `exclude_tmpdir_env_var` as an option on
  `SandboxPolicy::WorkspaceWrite`, so I was able to update the test to
  preserve the existing behavior, but to no longer write to
  `std::env::current_dir()`.
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/2338).
  * #2345
  * #2329
  * #2343
  * #2340
  * __->__ #2338

  Michael Bolin · 2025-08-15 09:06:15 -07:00
  26c8373821
• Added allow-expect-in-tests / allow-unwrap-in-tests (#2328)

  This PR:
  * Added the clippy.toml to configure allowable expect / unwrap usage in
  tests
  * Removed as many expect/allow lines as possible from tests
  * moved a bunch of allows to expects where possible
  
  Note: in integration tests, non `#[test]` helper functions are not
  covered by this so we had to leave a few lingering `expect(expect_used`
  checks around

  Parker Thompson · 2025-08-14 17:59:01 -07:00
  a075424437
• [approval_policy] Add OnRequest approval_policy (#1865)

  ## Summary
  A split-up PR of #1763 , stacked on top of a tools refactor #1858 to
  make the change clearer. From the previous summary:
  
  > Let's try something new: tell the model about the sandbox, and let it
  decide when it will need to break the sandbox. Some local testing
  suggests that it works pretty well with zero iteration on the prompt!
  
  ## Testing
  - [x] Added unit tests
  - [x] Tested locally and it appears to work smoothly!

  Dylan · 2025-08-05 20:44:20 -07:00
  725dd6be6a
• fix: ensure PatchApplyBeginEvent and PatchApplyEndEvent are dispatched reliably (#1760)

  This is a follow-up to https://github.com/openai/codex/pull/1705, as
  that PR inadvertently lost the logic where `PatchApplyBeginEvent` and
  `PatchApplyEndEvent` events were sent when patches were auto-approved.
  
  Though as part of this fix, I believe this also makes an important
  safety fix to `assess_patch_safety()`, as there was a case that returned
  `SandboxType::None`, which arguably is the thing we were trying to avoid
  in #1705.
  
  On a high level, we want there to be only one codepath where
  `apply_patch` happens, which should be unified with the patch to run
  `exec`, in general, so that sandboxing is applied consistently for both
  cases.
  
  Prior to this change, `apply_patch()` in `core` would either:
  
  * exit early, delegating to `exec()` to shell out to `apply_patch` using
  the appropriate sandbox
  * proceed to run the logic for `apply_patch` in memory
  
  
  https://github.com/openai/codex/blob/549846b29ad52f6cb4f8560365a731966054a9b3/codex-rs/core/src/apply_patch.rs#L61-L63
  
  In this implementation, only the latter would dispatch
  `PatchApplyBeginEvent` and `PatchApplyEndEvent`, though the former would
  dispatch `ExecCommandBeginEvent` and `ExecCommandEndEvent` for the
  `apply_patch` call (or, more specifically, the `codex
  --codex-run-as-apply-patch PATCH` call).
  
  To unify things in this PR, we:
  
  * Eliminate the back half of the `apply_patch()` function, and instead
  have it also return with `DelegateToExec`, though we add an extra field
  to the return value, `user_explicitly_approved_this_action`.
  * In `codex.rs` where we process `DelegateToExec`, we use
  `SandboxType::None` when `user_explicitly_approved_this_action` is
  `true`. This means **we no longer run the apply_patch logic in memory**,
  as we always `exec()`. (Note this is what allowed us to delete so much
  code in `apply_patch.rs`.)
  * In `codex.rs`, we further update `notify_exec_command_begin()` and
  `notify_exec_command_end()` to take additional fields to determine what
  type of notification to send: `ExecCommand` or `PatchApply`.
  
  Admittedly, this PR also drops some of the functionality about giving
  the user the opportunity to expand the set of writable roots as part of
  approving the `apply_patch` command. I'm not sure how much that was
  used, and we should probably rethink how that works as we are currently
  tidying up the protocol to the TUI, in general.

  Michael Bolin · 2025-07-31 11:13:57 -07:00
  06c786b2da
• fix: run apply_patch calls through the sandbox (#1705)

  Building on the work of https://github.com/openai/codex/pull/1702, this
  changes how a shell call to `apply_patch` is handled.
  
  Previously, a shell call to `apply_patch` was always handled in-process,
  never leveraging a sandbox. To determine whether the `apply_patch`
  operation could be auto-approved, the
  `is_write_patch_constrained_to_writable_paths()` function would check if
  all the paths listed in the paths were writable. If so, the agent would
  apply the changes listed in the patch.
  
  Unfortunately, this approach afforded a loophole: symlinks!
  
  * For a soft link, we could fix this issue by tracing the link and
  checking whether the target is in the set of writable paths, however...
  * ...For a hard link, things are not as simple. We can run `stat FILE`
  to see if the number of links is greater than 1, but then we would have
  to do something potentially expensive like `find . -inum <inode_number>`
  to find the other paths for `FILE`. Further, even if this worked, this
  approach runs the risk of a
  [TOCTOU](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use)
  race condition, so it is not robust.
  
  The solution, implemented in this PR, is to take the virtual execution
  of the `apply_patch` CLI into an _actual_ execution using `codex
  --codex-run-as-apply-patch PATCH`, which we can run under the sandbox
  the user specified, just like any other `shell` call.
  
  This, of course, assumes that the sandbox prevents writing through
  symlinks as a mechanism to write to folders that are not in the writable
  set configured by the sandbox. I verified this by testing the following
  on both Mac and Linux:
  
  ```shell
  #!/usr/bin/env bash
  set -euo pipefail
  
  # Can running a command in SANDBOX_DIR write a file in EXPLOIT_DIR?
  
  # Codex is run in SANDBOX_DIR, so writes should be constrianed to this directory.
  SANDBOX_DIR=$(mktemp -d -p "$HOME" sandboxtesttemp.XXXXXX)
  # EXPLOIT_DIR is outside of SANDBOX_DIR, so let's see if we can write to it.
  EXPLOIT_DIR=$(mktemp -d -p "$HOME" sandboxtesttemp.XXXXXX)
  
  echo "SANDBOX_DIR: $SANDBOX_DIR"
  echo "EXPLOIT_DIR: $EXPLOIT_DIR"
  
  cleanup() {
    # Only remove if it looks sane and still exists
    [[ -n "${SANDBOX_DIR:-}" && -d "$SANDBOX_DIR" ]] && rm -rf -- "$SANDBOX_DIR"
    [[ -n "${EXPLOIT_DIR:-}" && -d "$EXPLOIT_DIR" ]] && rm -rf -- "$EXPLOIT_DIR"
  }
  
  trap cleanup EXIT
  
  echo "I am the original content" > "${EXPLOIT_DIR}/original.txt"
  
  # Drop the -s to test hard links.
  ln -s "${EXPLOIT_DIR}/original.txt" "${SANDBOX_DIR}/link-to-original.txt"
  
  cat "${SANDBOX_DIR}/link-to-original.txt"
  
  if [[ "$(uname)" == "Linux" ]]; then
      SANDBOX_SUBCOMMAND=landlock
  else
      SANDBOX_SUBCOMMAND=seatbelt
  fi
  
  # Attempt the exploit
  cd "${SANDBOX_DIR}"
  
  codex debug "${SANDBOX_SUBCOMMAND}" bash -lc "echo pwned > ./link-to-original.txt" || true
  
  cat "${EXPLOIT_DIR}/original.txt"
  ```
  
  Admittedly, this change merits a proper integration test, but I think I
  will have to do that in a follow-up PR.

  Michael Bolin · 2025-07-30 16:45:08 -07:00
  221ebfcccc
• feat: add --dangerously-bypass-approvals-and-sandbox (#1384)

  This PR reworks `assess_command_safety()` so that the combination of
  `AskForApproval::Never` and `SandboxPolicy::DangerFullAccess` ensures
  that commands are run without _any_ sandbox and the user should never be
  prompted. In turn, it adds support for a new
  `--dangerously-bypass-approvals-and-sandbox` flag (that cannot be used
  with `--approval-policy` or `--full-auto`) that sets both of those
  options.
  
  Fixes https://github.com/openai/codex/issues/1254

  Michael Bolin · 2025-06-25 12:36:10 -07:00
  50924101d2
• chore: rename AskForApproval::UnlessAllowListed to AskForApproval::UnlessTrusted (#1385)

  We could just rename to `Untrusted` instead of `UnlessTrusted`, but I
  think `AskForApproval::UnlessTrusted` reads a bit better.

  Michael Bolin · 2025-06-25 12:26:13 -07:00
  72082164c1
• chore: rename unless-allow-listed to untrusted (#1378)

  For the `approval_policy` config option, renames `unless-allow-listed`
  to `untrusted`. In general, when it comes to exec'ing commands, I think
  "trusted" is a more accurate term than "safe."
  
  Also drops the `AskForApproval::AutoEdit` variant, as we were not really
  making use of it, anyway.
  
  Fixes https://github.com/openai/codex/issues/1250.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1378).
  * #1379
  * __->__ #1378

  Michael Bolin · 2025-06-24 22:19:21 -07:00
  86d5a9d80d
• fix: enable clippy on tests (#870)

  https://github.com/openai/codex/pull/855 added the clippy warning to
  disallow `unwrap()`, but apparently we were not verifying that tests
  were "clippy clean" in CI, so I ended up with a lot of local errors in
  VS Code.
  
  This turns on the check in CI and fixes the offenders.

  Michael Bolin · 2025-05-08 16:02:56 -07:00
  a9adb4175c
• fix: ensure apply_patch resolves relative paths against workdir or project cwd (#810)

  https://github.com/openai/codex/pull/800 kicked off some work to be more
  disciplined about honoring the `cwd` param passed in rather than
  assuming `std::env::current_dir()` as the `cwd`. As part of this, we
  need to ensure `apply_patch` calls honor the appropriate `cwd` as well,
  which is significant if the paths in the `apply_patch` arg are not
  absolute paths themselves. Failing that:
  
  - The `apply_patch` function call can contain an optional`workdir`
  param, so:
  - If specified and is an absolute path, it should be used to resolve
  relative paths
  - If specified and is a relative path, should be resolved against
  `Config.cwd` and then any relative paths will be resolved against the
  result
  - If `workdir` is not specified on the function call, relative paths
  should be resolved against `Config.cwd`
  
  Note that we had a similar issue in the TypeScript CLI that was fixed in
  https://github.com/openai/codex/pull/556.
  
  As part of the fix, this PR introduces `ApplyPatchAction` so clients can
  deal with that instead of the raw `HashMap<PathBuf,
  ApplyPatchFileChange>`. This enables us to enforce, by construction,
  that all paths contained in the `ApplyPatchAction` are absolute paths.

  Michael Bolin · 2025-05-04 12:32:51 -07:00
  5d924d44cf
• feat: make cwd a required field of Config so we stop assuming std::env::current_dir() in a session (#800)

  In order to expose Codex via an MCP server, I realized that we should be
  taking `cwd` as a parameter rather than assuming
  `std::env::current_dir()` as the `cwd`. Specifically, the user may want
  to start a session in a directory other than the one where the MCP
  server has been started.
  
  This PR makes `cwd: PathBuf` a required field of `Session` and threads
  it all the way through, though I think there is still an issue with not
  honoring `workdir` for `apply_patch`, which is something we also had to
  fix in the TypeScript version: https://github.com/openai/codex/pull/556.
  
  This also adds `-C`/`--cd` to change the cwd via the command line.
  
  To test, I ran:
  
  ```
  cargo run --bin codex -- exec -C /tmp 'show the output of ls'
  ```
  
  and verified it showed the contents of my `/tmp` folder instead of
  `$PWD`.

  Michael Bolin · 2025-05-04 10:57:12 -07:00
  421e159888
• fix: overhaul SandboxPolicy and config loading in Rust (#732)

  Previous to this PR, `SandboxPolicy` was a bit difficult to work with:
  
  
  https://github.com/openai/codex/blob/237f8a11e11fdcc793a09e787e48215676d9b95b/codex-rs/core/src/protocol.rs#L98-L108
  
  Specifically:
  
  * It was an `enum` and therefore options were mutually exclusive as
  opposed to additive.
  * It defined things in terms of what the agent _could not_ do as opposed
  to what they _could_ do. This made things hard to support because we
  would prefer to build up a sandbox config by starting with something
  extremely restrictive and only granting permissions for things the user
  as explicitly allowed.
  
  This PR changes things substantially by redefining the policy in terms
  of two concepts:
  
  * A `SandboxPermission` enum that defines permissions that can be
  granted to the agent/sandbox.
  * A `SandboxPolicy` that internally stores a `Vec<SandboxPermission>`,
  but externally exposes a simpler API that can be used to configure
  Seatbelt/Landlock.
  
  Previous to this PR, we supported a `--sandbox` flag that effectively
  mapped to an enum value in `SandboxPolicy`. Though now that
  `SandboxPolicy` is a wrapper around `Vec<SandboxPermission>`, the single
  `--sandbox` flag no longer makes sense. While I could have turned it
  into a flag that the user can specify multiple times, I think the
  current values to use with such a flag are long and potentially messy,
  so for the moment, I have dropped support for `--sandbox` altogether and
  we can bring it back once we have figured out the naming thing.
  
  Since `--sandbox` is gone, users now have to specify `--full-auto` to
  get a sandbox that allows writes in `cwd`. Admittedly, there is no clean
  way to specify the equivalent of `--full-auto` in your `config.toml`
  right now, so we will have to revisit that, as well.
  
  Because `Config` presents a `SandboxPolicy` field and `SandboxPolicy`
  changed considerably, I had to overhaul how config loading works, as
  well. There are now two distinct concepts, `ConfigToml` and `Config`:
  
  * `ConfigToml` is the deserialization of `~/.codex/config.toml`. As one
  might expect, every field is `Optional` and it is `#[derive(Deserialize,
  Default)]`. Consistent use of `Optional` makes it clear what the user
  has specified explicitly.
  * `Config` is the "normalized config" and is produced by merging
  `ConfigToml` with `ConfigOverrides`. Where `ConfigToml` contains a raw
  `Option<Vec<SandboxPermission>>`, `Config` presents only the final
  `SandboxPolicy`.
  
  The changes to `core/src/exec.rs` and `core/src/linux.rs` merit extra
  special attention to ensure we are faithfully mapping the
  `SandboxPolicy` to the Seatbelt and Landlock configs, respectively.
  
  Also, take note that `core/src/seatbelt_readonly_policy.sbpl` has been
  renamed to `codex-rs/core/src/seatbelt_base_policy.sbpl` and that
  `(allow file-read*)` has been removed from the `.sbpl` file as now this
  is added to the policy in `core/src/exec.rs` when
  `sandbox_policy.has_full_disk_read_access()` is `true`.

  Michael Bolin · 2025-04-29 15:01:16 -07:00
  0a00b5ed29
• 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