codex

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

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

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

windows sandbox: support multiple workspace roots (#6854 )

The Windows sandbox did not previously support multiple workspace roots
via config. Now it does

iceweasel-oai · 2025-11-18 16:35:00 -08:00

cf57320b9f

Improve world-writable scan (#6381 )

1. scan many more directories since it's much faster than the original
implementation
2. limit overall scan time to 2s
3. skip some directories that are noisy - ApplicationData, Installer,
etc.

iceweasel-oai · 2025-11-07 21:28:55 -08:00

917f39ec12

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

13 Commits