61 Commits

• Use released DotSlash package for argument-comment lint (#15199)

  ## Why
  The argument-comment lint now has a packaged DotSlash artifact from
  [#15198](https://github.com/openai/codex/pull/15198), so the normal repo
  lint path should use that released payload instead of rebuilding the
  lint from source every time.
  
  That keeps `just clippy` and CI aligned with the shipped artifact while
  preserving a separate source-build path for people actively hacking on
  the lint crate.
  
  The current alpha package also exposed two integration wrinkles that the
  repo-side prebuilt wrapper needs to smooth over:
  - the bundled Dylint library filename includes the host triple, for
  example `@nightly-2025-09-18-aarch64-apple-darwin`, and Dylint derives
  `RUSTUP_TOOLCHAIN` from that filename
  - on Windows, Dylint's driver path also expects `RUSTUP_HOME` to be
  present in the environment
  
  Without those adjustments, the prebuilt CI jobs fail during `cargo
  metadata` or driver setup. This change makes the checked-in prebuilt
  wrapper normalize the packaged library name to the plain
  `nightly-2025-09-18` channel before invoking `cargo-dylint`, and it
  teaches both the wrapper and the packaged runner source to infer
  `RUSTUP_HOME` from `rustup show home` when the environment does not
  already provide it.
  
  After the prebuilt Windows lint job started running successfully, it
  also surfaced a handful of existing anonymous literal callsites in
  `windows-sandbox-rs`. This PR now annotates those callsites so the new
  cross-platform lint job is green on the current tree.
  
  ## What Changed
  - checked in the current
  `tools/argument-comment-lint/argument-comment-lint` DotSlash manifest
  - kept `tools/argument-comment-lint/run.sh` as the source-build wrapper
  for lint development
  - added `tools/argument-comment-lint/run-prebuilt-linter.sh` as the
  normal enforcement path, using the checked-in DotSlash package and
  bundled `cargo-dylint`
  - updated `just clippy` and `just argument-comment-lint` to use the
  prebuilt wrapper
  - split `.github/workflows/rust-ci.yml` so source-package checks live in
  a dedicated `argument_comment_lint_package` job, while the released lint
  runs in an `argument_comment_lint_prebuilt` matrix on Linux, macOS, and
  Windows
  - kept the pinned `nightly-2025-09-18` toolchain install in the prebuilt
  CI matrix, since the prebuilt package still relies on rustup-provided
  toolchain components
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` to
  normalize host-qualified nightly library filenames, keep the `rustup`
  shim directory ahead of direct toolchain `cargo` binaries, and export
  `RUSTUP_HOME` when needed for Windows Dylint driver setup
  - updated `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
  so future published DotSlash artifacts apply the same nightly-filename
  normalization and `RUSTUP_HOME` inference internally
  - fixed the remaining Windows lint violations in
  `codex-rs/windows-sandbox-rs` by adding the required `/*param*/`
  comments at the reported callsites
  - documented the checked-in DotSlash file, wrapper split, archive
  layout, nightly prerequisite, and Windows `RUSTUP_HOME` requirement in
  `tools/argument-comment-lint/README.md`

  Michael Bolin · 2026-03-20 03:19:22 +00:00
  fa2a2f0be9
• 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
• temporarily disable private desktop until it works with elevated IPC path (#14986)
  iceweasel-oai · 2026-03-17 21:09:57 +00:00
  2cc4ee413f
• use framed IPC for elevated command runner (#14846)

  ## Summary
  This is PR 2 of the Windows sandbox runner split.
  
  PR 1 introduced the framed IPC runner foundation and related Windows
  sandbox infrastructure without changing the active elevated one-shot
  execution path. This PR switches that elevated one-shot path over to the
  new runner IPC transport and removes the old request-file bootstrap that
  PR 1 intentionally left in place.
  
  After this change, ordinary elevated Windows sandbox commands still
  behave as one-shot executions, but they now run as the simple case of
  the same helper/IPC transport that later unified_exec work will build
  on.
  
  ## Why this is needed for unified_exec
  Windows elevated sandboxed execution crosses a user boundary: the CLI
  launches a helper as the sandbox user and has to manage command
  execution from outside that security context. For one-shot commands, the
  old request-file/bootstrap flow was sufficient. For unified_exec, it is
  not.
  
  Unified_exec needs a long-lived bidirectional channel so the parent can:
  - send a spawn request
  - receive structured spawn success/failure
  - stream stdout and stderr incrementally
  - eventually support stdin writes, termination, and other session
  lifecycle events
  
  This PR does not add long-lived sessions yet. It converts the existing
  elevated one-shot path to use the same framed IPC transport so that PR 3
  can add unified_exec session semantics on top of a transport that is
  already exercised by normal elevated command execution.
  
  ## Scope
  This PR:
  - updates `windows-sandbox-rs/src/elevated_impl.rs` to launch the runner
  with named pipes, send a framed `SpawnRequest`, wait for `SpawnReady`,
  and collect framed `Output`/`Exit` messages
  - removes the old `--request-file=...` execution path from
  `windows-sandbox-rs/src/elevated/command_runner_win.rs`
  - keeps the public behavior one-shot: no session reuse or interactive
  unified_exec behavior is introduced here
  
  This PR does not:
  - add Windows unified_exec session support
  - add background terminal reuse
  - add PTY session lifecycle management
  
  ## Why Windows needs this and Linux/macOS do not
  On Linux and macOS, the existing sandbox/process model composes much
  more directly with long-lived process control. The parent can generally
  spawn and own the child process (or PTY) directly inside the sandbox
  model we already use.
  
  Windows elevated sandboxing is different. The parent is not directly
  managing the sandboxed process in the same way; it launches across a
  different user/security context. That means long-lived control requires
  an explicit helper process plus IPC for spawn, output, exit, and later
  stdin/session control.
  
  So the extra machinery here is not because unified_exec is conceptually
  different on Windows. It is because the elevated Windows sandbox
  boundary requires a helper-mediated transport to support it cleanly.
  
  ## Validation
  - `cargo test -p codex-windows-sandbox`

  iceweasel-oai · 2026-03-17 11:38:44 -07:00
  95bdea93d2
• windows-sandbox: add runner IPC foundation for future unified_exec (#14139)

  # Summary
  
  This PR introduces the Windows sandbox runner IPC foundation that later
  unified_exec work will build on.
  
  The key point is that this is intentionally infrastructure-only. The new
  IPC transport, runner plumbing, and ConPTY helpers are added here, but
  the active elevated Windows sandbox path still uses the existing
  request-file bootstrap. In other words, this change prepares the
  transport and module layout we need for unified_exec without switching
  production behavior over yet.
  
  Part of this PR is also a source-layout cleanup: some Windows sandbox
  files are moved into more explicit `elevated/`, `conpty/`, and shared
  locations so it is clearer which code is for the elevated sandbox flow,
  which code is legacy/direct-spawn behavior, and which helpers are shared
  between them. That reorganization is intentional in this first PR so
  later behavioral changes do not also have to carry a large amount of
  file-move churn.
  
  # Why This Is Needed For unified_exec
  
  Windows elevated sandboxed unified_exec needs a long-lived,
  bidirectional control channel between the CLI and a helper process
  running under the sandbox user. That channel has to support:
  
  - starting a process and reporting structured spawn success/failure
  - streaming stdout/stderr back incrementally
  - forwarding stdin over time
  - terminating or polling a long-lived process
  - supporting both pipe-backed and PTY-backed sessions
  
  The existing elevated one-shot path is built around a request-file
  bootstrap and does not provide those primitives cleanly. Before we can
  turn on Windows sandbox unified_exec, we need the underlying runner
  protocol and transport layer that can carry those lifecycle events and
  streams.
  
  # Why Windows Needs More Machinery Than Linux Or macOS
  
  Linux and macOS can generally build unified_exec on top of the existing
  sandbox/process model: the parent can spawn the child directly, retain
  normal ownership of stdio or PTY handles, and manage the lifetime of the
  sandboxed process without introducing a second control process.
  
  Windows elevated sandboxing is different. To run inside the sandbox
  boundary, we cross into a different user/security context and then need
  to manage a long-lived process from outside that boundary. That means we
  need an explicit helper process plus an IPC transport to carry spawn,
  stdin, output, and exit events back and forth. The extra code here is
  mostly that missing Windows sandbox infrastructure, not a conceptual
  difference in unified_exec itself.
  
  # What This PR Adds
  
  - the framed IPC message types and transport helpers for parent <->
  runner communication
  - the renamed Windows command runner with both the existing request-file
  bootstrap and the dormant IPC bootstrap
  - named-pipe helpers for the elevated runner path
  - ConPTY helpers and process-thread attribute plumbing needed for
  PTY-backed sessions
  - shared sandbox/process helpers that later PRs will reuse when
  switching live execution paths over
  - early file/module moves so later PRs can focus on behavior rather than
  layout churn
  
  # What This PR Does Not Yet Do
  
  - it does not switch the active elevated one-shot path over to IPC yet
  - it does not enable Windows sandbox unified_exec yet
  - it does not remove the existing request-file bootstrap yet
  
  So while this code compiles and the new path has basic validation, it is
  not yet the exercised production path. That is intentional for this
  first PR: the goal here is to land the transport and runner foundation
  cleanly before later PRs start routing real command execution through
  it.
  
  # Follow-Ups
  
  Planned follow-up PRs will:
  
  1. switch elevated one-shot Windows sandbox execution to the new runner
  IPC path
  2. layer Windows sandbox unified_exec sessions on top of the same
  transport
  3. remove the legacy request-file path once the IPC-based path is live
  
  # Validation
  
  - `cargo build -p codex-windows-sandbox`

  iceweasel-oai · 2026-03-16 19:45:06 +00:00
  d0a693e541
• 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
• copy current exe to CODEX_HOME/.sandbox-bin for apply_patch (#13669)

  We do this for codex-command-runner.exe as well for the same reason.
  Windows sandbox users cannot execute binaries in the WindowsApp/
  installed directory for the Codex App. This causes apply-patch to fail
  because it tries to execute codex.exe as the sandbox user.

  iceweasel-oai · 2026-03-05 22:15:10 -08:00
  14de492985
• copy command-runner to CODEX_HOME so sandbox users can always execute it (#13413)

  • Keep Windows sandbox runner launches working from packaged installs by
  running the helper from a user-owned runtime location.
  
  On some Windows installs, the packaged helper location is difficult to
  use reliably for sandboxed runner launches even though the binaries are
  present. This change works around that by copying codex-
  command-runner.exe into CODEX_HOME/.sandbox-bin/, reusing that copy
  across launches, and falling back to the existing packaged-path lookup
  if anything goes wrong.
  
  The runtime copy lives in a dedicated directory with tighter ACLs than
  .sandbox: sandbox users can read and execute the runner there, but they
  cannot modify it. This keeps the workaround focused on the
  command runner, leaves the setup helper on its trusted packaged path,
  and adds logging so it is clear which runner path was selected at
  launch.

  iceweasel-oai · 2026-03-04 01:31:37 +00:00
  639a5f6c48
• don't grant sandbox read access to ~/.ssh and a few other dirs. (#12835)

  OpenSSH complains if any other users have read access to ssh keys.
  
  ie https://github.com/openai/codex/issues/12226

  iceweasel-oai · 2026-02-26 11:35:55 -08:00
  6b879fe248
• Protect workspace .agents directory in Windows sandbox (#11970)

  The Mac and Linux implementations of the sandbox recently added write
  protections for `.codex` and `.agents` subdirectories in all writable
  roots. When adding documentation for this, I noticed that this change
  was never made for the Windows sandbox.
  
  Summary
  - make compute_allow_paths treat .codex/.agents as protected alongside
  .git, and cover their behavior in new tests
  - wire protect_workspace_agents_dir through the sandbox lib and setup
  path to apply deny ACEs when `.agents` exists
  - factor shared ACL logic for workspace subdirectories

  Eric Traut · 2026-02-17 09:40:46 -08:00
  5296e06b61
• add a slash command to grant sandbox read access to inaccessible directories (#11512)

  There is an edge case where a directory is not readable by the sandbox.
  In practice, we've seen very little of it, but it can happen so this
  slash command unlocks users when it does.
  
  Future idea is to make this a tool that the agent knows about so it can
  be more integrated.

  iceweasel-oai · 2026-02-12 12:48:36 -08:00
  5c3ca73914
• 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
• fix: remove errant Cargo.lock files (#11526)

  These leaked into the repo:
  
  - #4905 `codex-rs/windows-sandbox-rs/Cargo.lock`
  - #5391 `codex-rs/app-server-test-client/Cargo.lock`
  
  Note that these affect cache keys such as:
  
  
  https://github.com/openai/codex/blob/9722567a80b4bac81b74f679828747031fd95fa0/.github/workflows/rust-release.yml#L154
  
  so it seems best to remove them.

  Michael Bolin · 2026-02-12 02:28:02 +00:00
  ead38c3d1c
• Promote Windows Sandbox (#11341)

  1. Move Windows Sandbox NUX to right after trust directory screen
  2. Don't offer read-only as an option in Sandbox NUX.
  Elevated/Legacy/Quit
  3. Don't allow new untrusted directories. It's trust or quit
  4. move experimental sandbox features to `[windows]
  sandbox="elevated|unelevatd"`
  5. Copy tweaks = elevated -> default, non-elevated -> non-admin

  iceweasel-oai · 2026-02-11 11:48:33 -08:00
  87279de434
• Include real OS info in metrics. (#10425)

  calculated a hashed user ID from either auth user id or API key
  Also correctly populates OS.
  
  These will make our metrics more useful and powerful for analysis.

  iceweasel-oai · 2026-02-05 06:30:31 -08:00
  f2ffc4e5d0
• implement per-workspace capability SIDs for workspace specific ACLs (#10189)

  Today, there is a single capability SID that allows the sandbox to write
  to
  * workspace (cwd)
  * tmp directories if enabled
  * additional writable roots
  
  This change splits those up, so that each workspace has its own
  capability SID, while tmp and additional roots, which are
  installation-wide, are still governed by the "generic" capability SID
  
  This isolates workspaces from each other in terms of sandbox write
  access.
  Also allows us to protect <cwd>/.codex when codex runs in a specific
  <cwd>

  iceweasel-oai · 2026-02-03 12:37:51 -08:00
  aabe0f259c
• emit a separate metric when the user cancels UAT during elevated setup (#10399)

  Currently this shows up as elevated setup failure, which isn't quite
  accurate.

  iceweasel-oai · 2026-02-02 15:31:08 -08:00
  a5066bef78
• error code/msg details for failed elevated setup (#9941)
  iceweasel-oai · 2026-01-27 23:06:10 -08:00
  9f79365691
• fix: handle utf-8 in windows sandbox logs (#8647)

  Currently `apply_patch` will fail on Windows if the file contents happen
  to have a multi-byte character at the point where the `preview` function
  truncates.
  
  I've used the existing `take_bytes_at_char_boundary` helper and added a
  regression test (that fails without the fix).
  
  This is related to #4013 but doesn't fix it.

  David Gilbertson · 2026-01-26 15:11:27 -08:00
  313ee3003b
• fix(windows-sandbox): remove request files after read (#9316)

  ## Summary
  - Remove elevated runner request files after read (best-effort cleanup
  on errors)
  - Add a unit test to cover request file lifecycle
  
  ## Testing
  - `cargo test -p codex-windows-sandbox` (Windows)
  
  Fixes #9315

  Max Kong · 2026-01-24 10:23:37 -08:00
  e2bd9311c9
• use machine scope instead of user scope for dpapi. (#9713)

  This fixes a bug where the elevated sandbox setup encrypts sandbox user
  passwords as an admin user, but normal command execution attempts to
  decrypt them as a different user.
  
  Machine scope allows all users to encyrpt/decrypt
  
  this PR also moves the encrypted file to a different location
  .codex/.sandbox-secrets which the sandbox users cannot read.

  iceweasel-oai · 2026-01-22 16:40:13 -08:00
  0e4adcd760
• fix(windows-sandbox): parse PATH list entries for audit roots (#9319)

  ## Summary
  - Use `std::env::split_paths` to parse PATH entries in audit candidate
  collection
  - Add a unit test covering multiple PATH entries (including spaces)
  
  ## Testing
  - `cargo test -p codex-windows-sandbox` (Windows)
  
  Fixes #9317

  Max Kong · 2026-01-20 14:00:27 -08:00
  c73a11d55e
• fix(windows-sandbox): deny .git file entries under writable roots (#9314)

  ## Summary
  - Deny `.git` entries under writable roots even when `.git` is a file
  (worktrees/submodules)
  - Add a unit test for `.git` file handling
  
  ## Testing
  - `cargo test -p codex-windows-sandbox` (Windows)
  
  Fixes #9313

  Max Kong · 2026-01-20 13:59:59 -08:00
  f2de920185
• lookup system SIDs instead of hardcoding English strings. (#9552)

  The elevated setup does not work on non-English windows installs where
  Users/Administrators/etc are in different languages. This PR uses the
  well-known SIDs instead, which do not vary based on locale

  iceweasel-oai · 2026-01-20 13:55:37 -08:00
  9ea8e3115e
• chore: upgrade to Rust 1.92.0 (#8860)

  **Summary**
  - Upgrade Rust toolchain used by CI to 1.92.0.
  - Address new clippy `derivable_impls` warnings by deriving `Default`
  for enums across protocol, core, backend openapi models, and
  windows-sandbox setup.
  - Tidy up related test/config behavior (originator header handling, env
  override cleanup) and remove a now-unused assignment in TUI/TUI2 render
  layout.
  
  **Testing**
  - `just fmt`
  - `just fix -p codex-tui`
  - `just fix -p codex-tui2`
  - `just fix -p codex-windows-sandbox`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-tui2`
  - `cargo test -p codex-windows-sandbox`
  - `cargo test -p codex-core --test all`
  - `cargo test -p codex-app-server --test all`
  - `cargo test -p codex-mcp-server --test all`
  - `cargo test --all-features`

  viyatb-oai · 2026-01-16 11:12:52 -08:00
  f89a40a849
• fix(windows-sandbox-rs) bump SETUP_VERSION (#9134)

  ## Summary
  Bumps the windows setup version, to re-trigger windows sandbox setup for
  users in the experimental sandbox. We've seen some drift in the ACL
  controls, amongst a few other changes. Hopefully this should fix #9062.
  
  ## Testing
  - [x] Tested locally

  Dylan Hurd · 2026-01-13 13:47:29 -08:00
  ebacd28817
• feat: add support for building with Bazel (#8875)

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

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• Elevated sandbox NUX (#8789)

  Elevated Sandbox NUX:
  
  * prompt for elevated sandbox setup when agent mode is selected (via
  /approvals or at startup)
  * prompt for degraded sandbox if elevated setup is declined or fails
  * introduce /elevate-sandbox command to upgrade from degraded
  experience.

  iceweasel-oai · 2026-01-08 16:23:06 -08:00
  6372ba9d5f
• best effort to "hide" Sandbox users (#8492)

  The elevated sandbox creates two new Windows users - CodexSandboxOffline
  and CodexSandboxOnline. This is necessary, so this PR does all that it
  can to "hide" those users. It uses the registry plus directory flags (on
  their home directories) to get them to show up as little as possible.

  iceweasel-oai · 2026-01-05 12:29:10 -08:00
  07f077dfb3
• never let sandbox write to .codex/ or .codex/.sandbox/ (#8683)

  Never treat .codex or .codex/.sandbox as a workspace root.
  Handle write permissions to .codex/.sandbox in a single method so that
  the sandbox setup/runner can write logs and other setup files to that
  directory.

  iceweasel-oai · 2026-01-05 11:54:21 -08:00
  95580f229e
• better idempotency for creating/updating firewall rules during setup. (#8686)

  make sure if the Sandbox has to re-initialize with different Sandbox
  user SID, it still finds/updates the firewall rule instead of creating a
  new one.

  iceweasel-oai · 2026-01-05 10:42:33 -08:00
  720fa67816
• use a SandboxUsers group for ACLs instead of granting to each sandbox user separately (#8483)

  This is more future-proof if we ever decide to add additional Sandbox
  Users for new functionality
  
  This also moves some more user-related code into a new file for code
  cleanliness

  iceweasel-oai · 2026-01-02 10:47:26 -08:00
  79ce79a62e
• fix: restrict windows-sys to Windows target (#8522)

  I attempted to build codex on LoongArch Linux and encountered
  compilation errors.
  After investigation, the errors were traced to certain `windows-sys`
  features
  which rely on platform-specific cfgs that only support x86 and aarch64.
  
  With this change applied, the project now builds and runs successfully
  on my
  platform:
  - OS: AOSC OS (loongarch64)
  - Kernel: Linux 6.17
  - CPU: Loongson-3A6000
  
  Please let me know if this approach is reasonable, or if there is a
  better way
  to support additional platforms.

  RosarioYui · 2025-12-24 17:12:04 -07:00
  810ebe0d2b
• use a junction for the cwd while read ACLs are being applied (#8444)

  The elevated setup synchronously applies read/write ACLs to any
  workspace roots.
  
  However, until we apply *read* permission to the full path, powershell
  cannot use some roots as a cwd as it needs access to all parts of the
  path in order to apply it as the working directory for a command.
  
  The solution is, while the async read-ACL part of setup is running, use
  a "junction" that lives in C:\Users\CodexSandbox{Offline|Online} that
  points to the cwd.
  
  Once the read ACLs are applied, we stop using the junction.
  
  -----
  
  this PR also removes some dead code and overly-verbose logging, and has
  some light refactoring to the ACL-related functions

  iceweasel-oai · 2025-12-22 12:23:13 -08:00
  d65fe38b2c
• 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
• add a default dacl to restricted token to enable reading of pipes (#8280)

  this fixes sandbox errors (legacy and elevated) for commands that
  include pipes, which the model often favors.

  iceweasel-oai · 2025-12-18 12:59:52 -08:00
  6395430220
• grant read ACL to exe directory first so we can call the command runner (#8275)

  when granting read access to the sandbox user, grant the
  codex/command-runner exe directory first so commands can run before the
  entire read ACL process is finished.

  iceweasel-oai · 2025-12-18 19:52:32 +00:00
  ad41182ee8
• speed and reliability improvements for setting reads ACLs (#8216)

  - Batch read ACL creation for online/offline sandbox user
  - creates a new ACL helper process that is long-lived and runs in the
  background
  - uses a mutex so that only one helper process is running at a time.

  iceweasel-oai · 2025-12-17 15:27:52 -08:00
  25ecd0c2e4
• bug fixes and perf improvements for elevated sandbox setup (#8094)

  a few fixes based on testing feedback:
  * ensure cap_sid file is always written by elevated setup.
  * always log to same file whether using elevated sandbox or not
  * process potentially slow ACE write operations in parallel
  * dedupe write roots so we don't double process any
  * don't try to create read/write ACEs on the same directories, due to
  race condition

  iceweasel-oai · 2025-12-16 09:48:29 -08:00
  3d14da9728
• 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
• Elevated Sandbox 3 (#7809)

  dedicated sandbox command runner exe.

  iceweasel-oai · 2025-12-11 13:51:27 -08:00
  3e81ed4b91
• Elevated Sandbox 2 (#7792)

  - DPAPI helpers for storing Sandbox user passwords securely
  - creation of Offline/Online sandbox users
  - ACL setup for sandbox users
  - firewall rule setup

  iceweasel-oai · 2025-12-10 21:23:16 -08:00
  13c0919bff
• Elevated Sandbox 1 (#7788)

  - updating helpers, refactoring some functions that will be used in the
  elevated sandbox
  - better logging
  - better and faster handling of ACL checks/writes
  - No functional change—legacy restricted-token sandbox
  remains the only path.

  iceweasel-oai · 2025-12-09 19:00:33 -08:00
  fc4249313b
• Windows Sandbox: treat <workspace_root>/.git as read-only in workspace-write mode (#7142)

  this functionality is
  [supported](https://github.com/openai/codex/blob/main/codex-rs/protocol/src/protocol.rs#L421-L422)
  in the MacOs sandbox as well. Adding it to Windows for parity
  
  This PR also changes `rust-ci.yaml` to work around a github `hashFiles`
  issue. Others have done something
  [similar](https://github.com/openai/superassistant/pull/32156) today

  iceweasel-oai · 2025-11-24 12:41:21 -08:00
  99e5340c54
• chore: add cargo-deny configuration (#7119)

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

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874
• consolidate world-writable-directories scanning. (#7234)

  clean up the code for scanning for world writable directories
  
  One path (selecting a sandbox mode from /approvals) was using an
  incorrect method that did not use the new method of creating deny aces
  to prevent writing to those directories. Now all paths are the same.

  iceweasel-oai · 2025-11-24 09:51:58 -08:00
  486b1c4d9d
• Windows Sandbox: support network_access and exclude_tmpdir_env_var (#7030)
  iceweasel-oai · 2025-11-20 22:59:55 -08:00
  f4af6e389e
• add deny ACEs for world writable dirs (#7022)

  Our Restricted Token contains 3 SIDs (Logon, Everyone, {WorkspaceWrite
  Capability || ReadOnly Capability})
  
  because it must include Everyone, that left us vulnerable to directories
  that allow writes to Everyone. Even though those directories do not have
  ACEs that enable our capability SIDs to write to them, they could still
  be written to even in ReadOnly mode, or even in WorkspaceWrite mode if
  they are outside of a writable root.
  
  A solution to this is to explicitly add *Deny* ACEs to these
  directories, always for the ReadOnly Capability SID, and for the
  WorkspaceWrite SID if the directory is outside of a workspace root.
  
  Under a restricted token, Windows always checks Deny ACEs before Allow
  ACEs so even though our restricted token would allow a write to these
  directories due to the Everyone SID, it fails first because of the Deny
  ACE on the capability SID

  iceweasel-oai · 2025-11-20 14:50:33 -08:00
  3f92ad4190
• stop over-reporting world-writable directories (#6936)

  Fix world-writable audit false positives by expanding generic
  permissions with MapGenericMask and then checking only concrete write
  bits. The earlier check looked for FILE_GENERIC_WRITE/generic masks
  directly, which shares bits with read permissions and could flag an
  Everyone read ACE as writable.

  iceweasel-oai · 2025-11-19 13:59:17 -08:00
  2fde03b4a0