21 Commits

• Make deny canonical for filesystem permission entries (#23493)

  ## Why
  Filesystem permission profiles used `none` for deny-read entries, which
  is less direct than the action the entry actually represents. This
  change makes `deny` the canonical filesystem permission spelling while
  preserving compatibility for older configs that still send `none`.
  
  ## What changed
  - rename `FileSystemAccessMode::None` to `Deny`
  - serialize and generate schemas with `deny` as the canonical value
  - retain `none` only as a legacy input alias for temporary config
  compatibility
  - update filesystem glob diagnostics and regression coverage to use the
  canonical spelling
  - refresh config and app-server schema fixtures to match the new wire
  shape
  
  ## Validation
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core config_toml_deserializes_permission_profiles
  --lib`
  - `cargo test -p codex-core
  read_write_glob_patterns_still_reject_non_subpath_globs --lib`
  
  Earlier in the session, a broad `cargo test -p codex-core` run reached
  unrelated pre-existing failures in timing/snapshot/git-info tests under
  this environment; the targeted surfaces touched by this PR passed
  cleanly.

  viyatb-oai · 2026-05-19 11:03:47 -07:00
  3c76081876
• test: construct permission profiles directly (#23030)

  ## Why
  
  `SandboxPolicy` is now a legacy compatibility shape, but several tests
  still built a `SandboxPolicy` only to immediately convert it into
  `PermissionProfile` for APIs that already accept canonical runtime
  permissions. Those detours make it harder to audit where legacy sandbox
  policy is still required, because boundary-only usages are mixed
  together with ordinary test setup.
  
  ## What Changed
  
  - Updated tests in `codex-core`, `codex-exec`, `codex-analytics`, and
  `codex-config` to construct `PermissionProfile` values directly when the
  code under test takes a permission profile.
  - Changed exec-policy, request-permissions, session, and sandbox test
  helpers to pass `PermissionProfile` through instead of converting from
  `SandboxPolicy` internally.
  - Left `SandboxPolicy` in place where tests are explicitly exercising
  legacy compatibility or request/response boundaries.
  
  ## Test Plan
  
  - `cargo test -p codex-analytics -p codex-config`
  - `cargo test -p codex-core --lib safety::tests`
  - `cargo test -p codex-core --lib exec_policy::tests::`
  - `cargo test -p codex-core --lib exec::tests`
  - `cargo test -p codex-core --lib guardian_review_session_config`
  - `cargo test -p codex-core --lib tools::network_approval::tests`
  - `cargo test -p codex-core --lib
  tools::runtimes::shell::unix_escalation::tests`
  - `cargo test -p codex-core --lib managed_network`
  - `cargo test -p codex-core --test all request_permissions::`
  - `cargo test -p codex-exec sandbox`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23030).
  * #23036
  * __->__ #23030

  Michael Bolin · 2026-05-16 12:12:37 -07:00
  d91bc15618
• feat(sandbox): add Windows deny-read parity (#18202)

  ## Why
  
  The split filesystem policy stack already supports exact and glob
  `access = none` read restrictions on macOS and Linux. Windows still
  needed subprocess handling for those deny-read policies without claiming
  enforcement from a backend that cannot provide it.
  
  ## Key finding
  
  The unelevated restricted-token backend cannot safely enforce deny-read
  overlays. Its `WRITE_RESTRICTED` token model is authoritative for write
  checks, not read denials, so this PR intentionally fails that backend
  closed when deny-read overrides are present instead of claiming
  unsupported enforcement.
  
  ## What changed
  
  This PR adds the Windows deny-read enforcement layer and makes the
  backend split explicit:
  
  - Resolves Windows deny-read filesystem policy entries into concrete ACL
  targets.
  - Preserves exact missing paths so they can be materialized and denied
  before an enforceable sandboxed process starts.
  - Snapshot-expands existing glob matches into ACL targets for Windows
  subprocess enforcement.
  - Honors `glob_scan_max_depth` when expanding Windows deny-read globs.
  - Plans both the configured lexical path and the canonical target for
  existing paths so reparse-point aliases are covered.
  - Threads deny-read overrides through the elevated/logon-user Windows
  sandbox backend and unified exec.
  - Applies elevated deny-read ACLs synchronously before command launch
  rather than delegating them to the background read-grant helper.
  - Reconciles persistent deny-read ACEs per sandbox principal so policy
  changes do not leave stale deny-read ACLs behind.
  - Fails closed on the unelevated restricted-token backend when deny-read
  overrides are present, because its `WRITE_RESTRICTED` token model is not
  authoritative for read denials.
  
  ## Landed prerequisites
  
  These prerequisite PRs are already on `main`:
  
  1. #15979 `feat(permissions): add glob deny-read policy support`
  2. #18096 `feat(sandbox): add glob deny-read platform enforcement`
  3. #17740 `feat(config): support managed deny-read requirements`
  
  This PR targets `main` directly and contains only the Windows deny-read
  enforcement layer.
  
  ## Implementation notes
  
  - Exact deny-read paths remain enforceable on the elevated path even
  when they do not exist yet: Windows materializes the missing path before
  applying the deny ACE, so the sandboxed command cannot create and read
  it during the same run.
  - Existing exact deny paths are preserved lexically until the ACL
  planner, which then adds the canonical target as a second ACL target
  when needed. That keeps both the configured alias and the resolved
  object covered.
  - Windows ACLs do not consume Codex glob syntax directly, so glob
  deny-read entries are expanded to the concrete matches that exist before
  process launch.
  - Glob traversal deduplicates directory visits within each pattern walk
  to avoid cycles, without collapsing distinct lexical roots that happen
  to resolve to the same target.
  - Persistent deny-read ACL state is keyed by sandbox principal SID, so
  cleanup only removes ACEs owned by the same backend principal.
  - Deny-read ACEs are fail-closed on the elevated path: setup aborts if
  mandatory deny-read ACL application fails.
  - Unelevated restricted-token sessions reject deny-read overrides early
  instead of running with a silently unenforceable read policy.
  
  ## Verification
  
  - `cargo test -p codex-core
  windows_restricted_token_rejects_unreadable_split_carveouts`
  - `just fmt`
  - `just fix -p codex-core`
  - `just fix -p codex-windows-sandbox`
  - GitHub Actions rerun is in progress on the pushed head.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-05-11 23:04:28 -07:00
  46f30d0282
• fix: handle deferred network proxy denials (#19184)

  ## Why
  
  This bug is exposed by Guardian/auto-review approvals. With the managed
  network proxy enabled, a blocked network request can be reported back
  through the network approval service as an approval denial after the
  command has already started. Before this change, the shell and unified
  exec runtimes registered those network approval calls, but did not have
  a way to observe an async proxy denial as a cancellation/failure signal
  for the running process.
  
  The result was confusing: Guardian/auto-review could correctly deny
  network access, but the command path could keep running or unregister
  the approval without surfacing the denial as the command failure.
  
  ## What Changed
  
  - `NetworkApprovalService` now attaches a cancellation token to active
  and deferred network approvals.
  - Proxy-denial outcomes are recorded only for active registrations,
  cancel the owning token, and are consumed when the approval is
  finalized.
  - The shell runtime combines the normal command timeout with the
  network-denial cancellation token.
  - Unified exec stores the deferred network approval object, terminates
  tracked processes when the proxy denial arrives, and returns the denial
  as a process failure while polling or completing the process.
  - Tool orchestration passes the active network approval cancellation
  token into the sandbox attempt and preserves deferred approval errors
  instead of silently unregistering them.
  - App-server `command/exec` now handles the combined
  timeout-or-cancellation expiration variant used by the runtime.
  
  ## Verification
  
  - `cargo test -p codex-core network_approval --lib`
  - `cargo clippy -p codex-app-server --all-targets -- -D warnings`
  - `cargo clippy -p codex-core --all-targets -- -D warnings`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-29 19:13:57 +00:00
  07c8b8c77c
• permissions: remove cwd special path (#19841)

  ## Why
  
  The experimental `PermissionProfile` API had both `:cwd` and
  `:project_roots` special filesystem paths, which made the permission
  root ambiguous. This PR removes the unstable `current_working_directory`
  special path before the permissions API is stabilized, so callers use
  `:project_roots` for symbolic project-root access.
  
  ## What changed
  
  - Removes `FileSystemSpecialPath::CurrentWorkingDirectory` from protocol
  and app-server protocol models, plus regenerated app-server
  JSON/TypeScript schemas.
  - Replaces internal `:cwd` permission entries with `:project_roots`
  entries.
  - Keeps the existing cwd-update behavior for legacy-shaped
  workspace-write profiles, while removing the deleted
  `CurrentWorkingDirectory` case from that compatibility path.
  - Keeps `PermissionProfile::workspace_write()` as the reusable symbolic
  workspace-write helper, with docs noting that `:project_roots` entries
  resolve at enforcement time.
  - Updates app-server docs/examples and approval UI labeling to stop
  advertising `:cwd` as a permission token.
  
  ## Compatibility
  
  Persisted rollout items may contain the old
  `{"kind":"current_working_directory"}` tag from earlier experimental
  `permissionProfile` snapshots. This PR keeps that tag as a
  deserialize-only alias for `ProjectRoots { subpath: None }`, while
  continuing to serialize only the new `project_roots` tag.
  
  ## Follow-up
  
  This PR intentionally does not introduce an explicit project-root set on
  `SessionConfiguration` or runtime sandbox resolution. Today, the
  resolver still uses the active cwd as the single implicit project root.
  A follow-up should model project roots separately from tool cwd so
  `:project_roots` entries can resolve against the configured project
  roots, and resolve to no entries when there are no project roots.
  
  ## Verification
  
  - `cargo test -p codex-protocol permissions:: --lib`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-sandboxing -p codex-exec-server --lib`
  - `cargo test -p codex-core session_configuration_apply_ --lib`
  - `cargo test -p codex-app-server
  command_exec_permission_profile_project_roots_use_command_cwd --test
  all`
  - `cargo test -p codex-tui
  thread_read_session_state_does_not_reuse_primary_permission_profile
  --lib`
  - `cargo test -p codex-tui
  preset_matching_accepts_workspace_write_with_extra_roots --lib`
  - `cargo test -p codex-config --lib`

  Michael Bolin · 2026-04-27 13:41:27 -07:00
  4b55979755
• 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
• permissions: remove legacy read-only access modes (#19449)

  ## Why
  
  `ReadOnlyAccess` was a transitional legacy shape on `SandboxPolicy`:
  `FullAccess` meant the historical read-only/workspace-write modes could
  read the full filesystem, while `Restricted` tried to carry partial
  readable roots. The partial-read model now belongs in
  `FileSystemSandboxPolicy` and `PermissionProfile`, so keeping it on
  `SandboxPolicy` makes every legacy projection reintroduce lossy
  read-root bookkeeping and creates unnecessary noise in the rest of the
  permissions migration.
  
  This PR makes the legacy policy model narrower and explicit:
  `SandboxPolicy::ReadOnly` and `SandboxPolicy::WorkspaceWrite` represent
  the old full-read sandbox modes only. Split readable roots, deny-read
  globs, and platform-default/minimal read behavior stay in the runtime
  permissions model.
  
  ## What changed
  
  - Removes `ReadOnlyAccess` from
  `codex_protocol::protocol::SandboxPolicy`, including the generated
  `access` and `readOnlyAccess` API fields.
  - Updates legacy policy/profile conversions so restricted filesystem
  reads are represented only by `FileSystemSandboxPolicy` /
  `PermissionProfile` entries.
  - Keeps app-server v2 compatible with legacy `fullAccess` read-access
  payloads by accepting and ignoring that no-op shape, while rejecting
  legacy `restricted` read-access payloads instead of silently widening
  them to full-read legacy policies.
  - Carries Windows sandbox platform-default read behavior with an
  explicit override flag instead of depending on
  `ReadOnlyAccess::Restricted`.
  - Refreshes generated app-server schema/types and updates tests/docs for
  the simplified legacy policy shape.
  
  ## Verification
  
  - `cargo check -p codex-app-server-protocol --tests`
  - `cargo check -p codex-windows-sandbox --tests`
  - `cargo test -p codex-app-server-protocol sandbox_policy_`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19449).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19449

  Michael Bolin · 2026-04-24 17:16:58 -07:00
  789f387982
• feat(permissions): add glob deny-read policy support (#15979)

  ## Summary
  - adds first-class filesystem policy entries for deny-read glob patterns
  - parses config such as :project_roots { "**/*.env" = "none" } into
  pattern entries
  - enforces deny-read patterns in direct read/list helpers
  - fails closed for sandbox execution until platform backends enforce
  glob patterns in #18096
  - preserves split filesystem policy in turn context only when it cannot
  be reconstructed from legacy sandbox policy
  
  ## Stack
  1. This PR - glob deny-read policy/config/direct-tool support
  2. #18096 - macOS and Linux sandbox enforcement
  3. #17740 - managed deny-read requirements
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-sandboxing --tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-16 10:31:51 -07:00
  6862b9c745
• fix: cleanup the contract of the general-purpose exec() function (#17870)

  `exec()` had a number of arguments that were unused, making the function
  signature misleading. This PR aims to clean things up to clarify the
  role of this function and to clarify which fields of `ExecParams` are
  unused and why.

  Michael Bolin · 2026-04-15 04:40:12 +00:00
  c6defb1f0f
• Spread AbsolutePathBuf (#17792)

  Mechanical change to promote absolute paths through code.

  pakrym-oai · 2026-04-14 14:26:10 -07:00
  dd1321d11b
• fix(permissions): fix symlinked writable roots in sandbox permissions (#15981)

  ## Summary
  - preserve logical symlink paths during permission normalization and
  config cwd handling
  - bind real targets for symlinked readable/writable roots in bwrap and
  remap carveouts and unreadable roots there
  - add regressions for symlinked carveouts and nested symlink escape
  masking
  
  ## Root cause
  Permission normalization canonicalized symlinked writable roots and cwd
  to their real targets too early. That drifted policy checks away from
  the logical paths the sandboxed process can actually address, while
  bwrap still needed the real targets for mounts. The mismatch caused
  shell and apply_patch failures on symlinked writable roots.
  
  ## Impact
  Fixes #15781.
  
  Also fixes #17079:
  - #17079 is the protected symlinked carveout side: bwrap now binds the
  real symlinked writable-root target and remaps carveouts before masking.
  
  Related to #15157:
  - #15157 is the broader permission-check side of this path-identity
  problem. This PR addresses the shared logical-vs-canonical normalization
  issue, but the reported Darwin prompt behavior should be validated
  separately before auto-closing it.
  
  This should also fix #14672, #14694, #14715, and #15725:
  - #14672, #14694, and #14715 are the same Linux
  symlinked-writable-root/bwrap family as #15781.
  - #15725 is the protected symlinked workspace path variant; the PR
  preserves the protected logical path in policy space while bwrap applies
  read-only or unreadable treatment to the resolved target so
  file-vs-directory bind mismatches do not abort sandbox setup.
  
  ## Notes
  - Added Linux-only regressions for symlinked writable ancestors and
  protected symlinked directory targets, including nested symlink escape
  masking without rebinding the escape target writable.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-10 17:00:58 -07:00
  b114781495
• 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
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

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

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• Protect first-time project .codex creation across Linux and macOS sandboxes (#15067)

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

  rreichel3-oai · 2026-03-26 16:06:53 -04:00
  86764af684
• fix: 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
• Extract sandbox manager and transforms into codex-sandboxing (#15603)

  Extract sandbox manager

  pakrym-oai · 2026-03-24 08:20:57 -07:00
  f49eb8e9d7
• core: add a full-buffer exec capture policy (#15254)
  Michael Bolin · 2026-03-20 02:38:12 +00:00
  a3e59e9e85
• feat: support restricted ReadOnlyAccess in elevated Windows sandbox (#14610)

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

  viyatb-oai · 2026-03-17 19:08:50 -07:00
  d950543e65
• 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