## What changed
- Add `Platform` to `codex-utils-path-uri` with metadata parsing, native platform detection, and path convention mapping. Preserve missing or unrecognized metadata as `Unknown`.
- Replace `NetworkProxyExecutorOs` with the shared type and keep executor-specific socket path validation in the network proxy.
- Extract `effective_sandbox_mode` with explicit platform and Windows sandbox level inputs, preserving the native Windows fallback from `workspace-write` to `read-only` when the sandbox is disabled.
## Testing
Add unit tests for platform metadata, path conventions, native platform detection, and sandbox mode selection across platforms and Windows sandbox levels.
GitOrigin-RevId: 4fe0972e3a91040e35f2a6dfa5bcdf6c9a29be88
## Why
A controller and its executor can run different operating systems. Validating socket paths against the controller's OS can reject absolute paths that are valid on the executor, such as Windows paths on a Linux controller.
## What changed
- Thread `NetworkProxyExecutorOs` through network policy validation, proxy construction, and policy updates.
- Require allowed socket paths to be NUL-free and absolute for the executor OS, while preserving deny entries unchanged.
- Accept either Unix or Windows absolute syntax when executor metadata omits the OS, then validate against the executor's own OS at launch.
- Keep native path normalization and socket support checks at execution time.
## Testing
Add coverage for cross-platform absolute path syntax, invalid allow entries, preserved deny entries, and remote policy round trips that retain executor semantics through domain edits and proxy construction.
GitOrigin-RevId: 1ebc09cbce7138f60ec5fd62875591a3df52d067
## What changed
- Accept `windows.sandbox = "mxc"` and preserve the selected backend through environment configuration, command execution, patch writes, and sandbox metadata.
- Treat MXC as enabled in the TUI and report Windows sandbox readiness as `ready`, avoiding legacy setup prompts.
- Keep `allowed_sandbox_implementations` scoped to the legacy elevated and unelevated backends without restricting MXC.
- Default `windows.sandbox_private_desktop` to `false` for MXC while retaining `true` for legacy sandboxes.
## Testing
Add coverage for MXC configuration precedence, legacy requirement handling, sandbox selection, and TUI state. Add a Wine integration test that verifies command and patch routing fails when native MXC is unavailable and reports `windows_mxc` in turn metadata.
GitOrigin-RevId: e2162447d0750f60753864c92a20e02a7f297bca
## Why
An omitted controller socket policy was treated as an explicit denial, preventing execution environments from supplying their own Unix socket grants.
## What changed
- Preserve omission of `dangerously_allow_all_unix_sockets` separately from `false`, and retain explicitly empty `unix_sockets` maps.
- Defer to attachment socket permissions when the controller supplies neither setting. Continue enforcing explicit restrictions, socket denials, and managed requirements.
- Resolve omitted values to `false` for ordinary execution and remote configuration, preserving the default for commands without attachment grants.
- Add debug logging for effective environment and remote execution network policies.
## Testing
Add regression coverage for omitted, explicit, finite, empty, and managed socket policies through remote launch configuration, including live policy replacement and serialization round trips. Adjust remote environment tests to tolerate child-completion ordering and box large cold-resume test futures to reduce Windows stack usage.
GitOrigin-RevId: 98a88d01cbb91aea1faaa03b3c414ef3be7af398
## Why
Network access and Unix-socket allowlists must not let commands with filesystem restrictions reach the privileged app-server RPC transport.
## What changed
- Bind Unix control sockets in a fixed, user-owned directory with mode `0700`, independent of environment settings, and expose the advertised paths as symlinks. Preserve existing parent permissions, reject unsafe parents, and serialize socket setup and publication.
- Mask the socket directory in Linux bubblewrap sandboxes after each bind that exposes it. Reject host mount aliases and nested mounts that compromise isolation.
- Deny access to the directory and outbound connections to its sockets in macOS Seatbelt policies, including when network access or Unix-socket allowlists grant broader access.
- Require bubblewrap for filesystem-restricted Linux execution. Users with `features.use_legacy_landlock` enabled must disable it for these policies.
## Testing
Add regression coverage for direct and symlink socket access, hardlink attempts, Linux host-process links and bind-mount aliases, and continued use of unrelated and sandbox-local sockets. Add transport coverage for parent permissions, concurrent restart after a stale symlink, and cleanup that preserves a replacement at the advertised path.
GitOrigin-RevId: 53372c27eea278d964f2cf68aed24323ef3b7082
## Why
MXC is a sandbox implementation, not a restricted-token sandbox level. Executor requests need to represent that choice separately from `WindowsSandboxLevel`.
## What changed
- Introduce `WindowsSandboxSelection` for executor sandbox contexts and remove `Mxc` from `WindowsSandboxLevel`.
- Preserve the `windowsSandboxLevel` wire field and its serialized values for compatibility.
- Share sandbox selection between executor process launches and filesystem helpers, and use the new selection in capability discovery and skill reads.
- Disable Windows sandbox selection for executor paths that do not use Windows path conventions.
## Testing
Extend coverage for MXC wire serialization, Windows skill-read sandbox checks, and capability discovery with distinct permissions. Exercise remote filesystem write restrictions with both restricted-token and MXC sandboxes, including rejection when native MXC is unavailable.
GitOrigin-RevId: 266211377bcb138a0dc75861e9ff2225fa37a53d
## What changed
- Capture `CODEX_WINDOWS_REGISTERED_CORE=1` at startup and propagate the selected runtime to sandbox wrappers.
- Launch registered runners through service-recorded execution aliases, validating ownership, OS package identity, and the staged runner image before sending commands. Require service provisioning without falling back to copied helpers or `PATH` lookup.
- Preserve package context for sandboxed child processes and descendants so they can launch executables from the protected package directory.
- Refresh stale package registrations during readiness checks without blocking unrelated RPCs, and reconcile effective proxy settings through the service.
- Resolve setup ownership from the process token and avoid treating the server directory as a writable workspace when setup omits `cwd`.
- Record startup and command outcomes by runtime.
## Testing
Add coverage for runtime selection, package query validation, helper resolution, setup roots, proxy reconciliation, and command result reporting. Add an ignored integration test for environment forwarding, output, and exit status that requires an installed test MSIX and service provisioning in a Windows VM.
GitOrigin-RevId: 976d64039d611be4406c3d0e354820775f8eb6e4
## Why
Seatbelt ignored Unix socket permissions in `ManagedNetworkSandboxContext`, which could omit allowed sockets or inherit a live proxy's broader permissions.
## What changed
Use the prepared context's `allow_unix_sockets` and `dangerously_allow_all_unix_sockets` settings when present, falling back to the live proxy only when no prepared context exists. Normalize allowlisted paths and preserve explicit extra socket allowances.
## Testing
Add regression coverage for prepared-policy precedence, empty allowlists, invalid relative paths, and explicit extra allowances. Extend macOS exec-server tests to cover prepared and executor-local proxy socket permissions, including explicit allow-all behavior without unrestricted network access.
GitOrigin-RevId: 3372e1f2f1b161e60bde585db8d70b4e3a0b1854
## Why
Linux proxy-routed sandboxing denied standalone Unix sockets even when the effective network policy enabled `dangerously_allow_all_unix_sockets`.
## What changed
- Carry Unix socket permissions in `ManagedNetworkSandboxContext` and pass the prepared context through Linux sandbox launches with `--managed-network`.
- Allow `AF_UNIX` socket creation in proxy-routed mode when `dangerously_allow_all_unix_sockets` is enabled, while preserving network namespace isolation and restrictions on other socket families.
- Keep standalone Unix sockets denied by default and for path-only grants. Default missing fields in older serialized contexts to restrictive values.
## Testing
Add coverage for policy preparation and transport, legacy deserialization, and malformed policy rejection. Add a Linux integration test covering default denial, path-only denial, and explicit allow-all access, while checking that direct TCP access and `AF_NETLINK`/`AF_VSOCK` sockets remain blocked.
GitOrigin-RevId: 2695b945ad3e59fcb3faf7662d852a26650af16c
## What changed
- Add explicit MXC backend selection and carry its identity through exec-server process reporting and sandbox violation classification.
- Launch MXC through the Codex executable with the effective permission profile and command environment.
- Reject exec-server MXC requests when native MXC is unavailable or when they request a TTY, an `arg0` override, or managed networking. Reject private desktop isolation during MXC preparation.
- Allow an explicitly empty child environment and avoid exposing request payload values in launcher decode errors.
## Testing
Add coverage for sandbox selection and unsupported-request rejection, plus Windows RPC tests for stdin writes and temporary-directory permissions derived from the command environment. Native MXC tests skip when MXC is unavailable.
GitOrigin-RevId: 3626ff0f9ad7f9b812ce09b68c31ea9a5a9c72b1
## What changed
- Dispatch `--__codex-windows-mxc` before normal CLI parsing, launch the decoded request, and propagate the child exit code.
- Build the native request from the helper's environment and working directory, discovered Windows platform directories, and volume roots, including UNC working-directory roots. Reject non-Unicode environment values and empty child environments.
- Allow Win32k calls and desktop handles needed for PowerShell startup while retaining clipboard, input-injection, and desktop/system-control restrictions.
- Keep policy, transport, and native launch internals private, and report an explicit error when the helper is invoked outside Windows.
## Testing
Add a wrapper regression test covering exact argument preservation, Windows quoting, separate policy and command working directories, and explicit environment forwarding.
GitOrigin-RevId: 674d0d61a3265bd517b77da9f9de2cd9fad62917
## Why
Private desktops owned by short-lived sandbox wrappers disappear when those wrappers exit, preventing reuse across filesystem helper requests.
## What changed
- Select and cache private desktops in the calling process, keeping desktops separate for different sandbox permissions.
- Pass the desktop name through the wrapper to the restricted-token and elevated backends so helpers reuse the selected desktop.
- Separate sandbox account preparation from filesystem ACL refresh so desktop selection does not perform the wrapper's refresh.
- Propagate desktop preparation errors and require a desktop name when the wrapper's private desktop flag is set.
## Testing
Add a Windows filesystem regression test covering desktop survival and reuse across reads, writes, metadata queries, and streaming reads, plus separate read-only permissions and rejected writes. Extend wrapper argument tests to cover named desktops and rejection of a missing desktop name.
GitOrigin-RevId: 05a1cb829a902732248bfa7f4ad7470d911fa9f6
## What changed
- Add `codex-mxc-sandbox` with native MXC availability detection and a launcher that inherits standard I/O and waits for the sandboxed process.
- Reject unsupported learning-mode and fallback policies, and verify deny-path support before launch.
- Route the existing Windows MXC availability metric through the new crate and move its Windows linking dependencies alongside the adapter.
GitOrigin-RevId: e2a220b85718e00b0e710c30bbe66b6c56958176
## Why
`ShellExecuteExW` needs `SystemRoot` to elevate the Windows sandbox setup helper.
## What changed
Add `SYSTEMROOT` to the environment variables copied from the host for wrapper
setup. Keep the serialized inner command environment unchanged so the host value
is available only to the wrapper.
## Testing
Extend Windows sandbox manager tests to cover case-insensitive replacement of
`SystemRoot` and verify that it is excluded from the inner command environment.
GitOrigin-RevId: c69f9f92665e97a178e2de488fbb9fd6b7ff7ac6
## What changed
- Add the macOS-only `allow_symlinked_codex_home` user setting. When enabled in the execution host's `$CODEX_HOME/config.toml`, writable roots at or beneath that home may traverse symlinks.
- Keep the exception disabled by default and prevent project config, command-line overrides, and ignored user config from enabling it. Other writable roots remain subject to symlink checks.
- Propagate the resolved setting through local, interactive, and exec-server sandbox paths, including `CODEX_HOME` aliases.
- Explain the opt-out in symlink rejection errors, including that it trusts targets outside `CODEX_HOME` and targets that change between commands.
## Testing
- Add macOS coverage for shell commands, patches, filesystem helpers, process execution, and interactive startup with enabled, disabled, aliased, and out-of-scope homes.
GitOrigin-RevId: 99fcdf611200c9e1b7713cf06f7fdea5bfa7f089
## What changed
Increment the `codex.windows_sandbox.private_desktop` counter when preparing a
Windows restricted-token sandbox execution, tagging it with whether private
desktop isolation is enabled.
GitOrigin-RevId: 1eb5e183b57e19753dc133dbe152eabe23dd2a23
## What changed
- Pass the selected executor's `PathUri` through user command approval requests instead of converting the working directory to a host-native path.
- Make native-path permission helpers explicitly local and require executor-aware permission transforms to receive a `FileSystemSandboxPolicyContext`.
- Cover approved remote commands to verify that the approval request reports the selected remote working directory and execution resumes after approval.
GitOrigin-RevId: 0aa3042f2d7594af6c7d0abf31d7f99cf67d5556
## Why
`request_permissions` paths and grants need to be evaluated against the selected executor environment, including its path convention, home directory, workspace roots, and temporary directories.
## What changed
- Resolve relative and home-relative permission paths using the executor context, reject mismatched path conventions and lossy paths, and support legacy `read` and `write` path lists.
- Move grant intersection into core so requested and granted permissions use the originating environment's sandbox context. Preserve deny entries conservatively when a special path cannot be resolved.
- Keep the full originating environment with pending permission requests so delayed responses are normalized against the same context.
## Testing
- Cover POSIX, Windows, UNC, relative, and home-relative path resolution and invalid path contexts.
- Verify end-to-end app-server grants are limited to the requested workspace scope and unresolved temporary-directory denies are preserved.
GitOrigin-RevId: 730a2aacd391262e92a6314f3a5b6c262e3dca10
## What changed
- Probe whether the native Windows MXC process security environment is usable
when selecting a sandbox.
- Emit `codex.windows_mxc.available` at most once per process, labeled with the
probe result.
- Add the MXC workspace dependencies for Cargo and Bazel, and pin
`tracelogging` to a version compatible with the GNU Windows toolchain.
GitOrigin-RevId: d7cfeed6f0333feda5764e1ee44fe5bbd50f9a58
## Why
Permission grants can belong to an executor whose path convention differs from
the local host, such as a Windows remote environment. Matching those grants
against a host-native working directory can reject valid permissions.
## What changed
- Normalize, materialize, and compare additional filesystem permissions using
the selected executor's URI-based sandbox context.
- Apply the same context-aware preapproval flow to `exec_command`,
`apply_patch`, and extension tools.
- Fail closed when symbolic temporary-directory or project-root permissions
cannot be resolved from executor metadata, while accepting opaque working
directory URIs when requested paths use the executor's convention.
## Testing
- Added coverage for reusing a Windows permission grant from a non-Windows
host, resolving symbolic temporary-directory grants, and normalizing paths
with an opaque Windows working directory.
GitOrigin-RevId: aee54350a25430a0443f8319e2bb0bbdc4f44282
## What changed
- Add context-aware normalization, materialization, and intersection helpers for additional filesystem permissions.
- Resolve project roots, home-relative deny globs, temporary directories, and filesystem roots from the executor's `FileSystemSandboxPolicyContext` while preserving URI path conventions and symlinked paths.
- Keep deny constraints when intersecting grants across POSIX, Windows, and UNC paths, and reject incompatible path conventions when executor context is available.
## Testing
- Cover cross-convention validation, empty temporary-directory contexts, home-relative deny globs, and rooted deny globs for POSIX, Windows, and UNC paths.
GitOrigin-RevId: 14fd866a17a0ac4a595aa4f0e2fb82bfae1a8838
## Why
Programs running in a PTY can block while waiting for replies to terminal
queries.
## What changed
- Intercept device-status, window-size, cursor-position, and DEC private-mode
queries from TTY subprocess output and write bounded responses to the
subprocess input.
- Remove handled queries from the output stream while preserving other escape
sequences and output, including queries split across chunks.
- Apply the responder to both direct and driver-backed TTY process spawning.
## Testing
Added tests for driver-backed query handling and for a PTY subprocess that
waits for a cursor-position response before exiting.
GitOrigin-RevId: de92e06d183647271ef49024da9c30f01699f886
## Why
Filesystem policies can describe paths using a convention that differs from the
host running Codex. Native path comparisons can therefore mis-handle cases such
as case-variant Windows paths or ambiguous encoded components.
## What changed
- Resolve policy entries and special roots as `PathUri` values using the
executor's path convention.
- Use validated URI components for containment, overlap, and precedence, and
fail closed when component boundaries are ambiguous.
- Restrict relative joins to descendants and apply the same matching rules to
protected metadata paths and permission-profile intersections.
## Testing
Added coverage for Windows case variants, encoded and opaque paths, repeated
separators, descendant joins, special roots, metadata protection, and preserved
deny entries.
GitOrigin-RevId: fb09d44d11df25faaac806fe00457e6f6b0d8596
## Why
Filesystem helpers should not inherit access to system scratch directories beyond the paths granted by their filesystem policy, while ordinary processes still need scratch access for compatibility.
## What changed
- Move the `/tmp` and `/var/tmp` read/write grants, including their `/private` aliases, from the shared platform defaults into the process-only Seatbelt defaults.
- Keep process access to `/Applications` alongside the scratch-directory grants.
## Testing
Add a macOS Seatbelt test that verifies the generated policies and, when nested Seatbelt execution is available, confirms process scratch access, helper denial, and helper access to an approved project path.
GitOrigin-RevId: 26d83f09c131c1f1d000163b2f8929f601749719
## What changed
- Add Windows sandbox mode, private-desktop behavior, and legacy Landlock selection to each `EnvironmentConfig`.
- Centralize sandbox context construction on `TurnEnvironment`, preserving environment-owned permissions, paths, and backend settings while applying additional permission grants.
- Use the environment-derived context for project instructions, capability discovery, file uploads, and filesystem-oriented tools.
## Testing
- Verify capability discovery uses the selected environment's permission profile and sandbox backends when they differ from the thread defaults.
GitOrigin-RevId: 7ae2fed90c8ada950f2e8431e571e9b2c793c291
## Why
Python's `ProcessPoolExecutor` queries `SEM_NSEMS_MAX` through `sysconf`, which reads the `kern.sysv.semmns` sysctl on macOS.
## What changed
- Allow reads of `kern.sysv.semmns` in the base Seatbelt policy.
- Verify `/usr/bin/getconf SEM_NSEMS_MAX` succeeds with both read-only and workspace-write sandbox policies.
GitOrigin-RevId: ab3ae92dc8991729f90a47c1994eedb6c7a2b9cd
## Why
The macOS preferences service can expose data outside a sandbox's allowed
filesystem read roots.
## What changed
- Move the Seatbelt preference and `cfprefsd` grants into a separate policy
section that is included only when filesystem reads are unrestricted.
- Remove the equivalent grants from the restricted platform defaults.
## Testing
- Verify both Seatbelt profiles include preference grants only for full-disk
read policies, including policies with denied paths or globs.
- Verify a restricted sandbox cannot retrieve a preference whose plist is
denied, while an unrestricted read policy can.
GitOrigin-RevId: 90388366a7302bca1830ad0439544be8babc7321
## Why
Resolving attacker-mutable path components while preparing a Seatbelt profile can let a writable root be rebound to a different location before the sandbox is applied. File roots also need to remain confined to the file itself rather than granting access to descendants after replacement.
## What changed
- Preserve mutable components of writable-root paths until Seatbelt binds them, while still normalizing trusted top-level aliases such as `/tmp`.
- Use literal grants for existing file and device roots, and subpath grants for directories and missing roots.
- Exclude both logical and resolved forms of protected subpaths so symlinked metadata directories remain read-only.
## Testing
Add coverage for ancestor rebinding, file-root symlink and directory replacement, missing directory roots, top-level aliases, and symlinked metadata carveouts.
GitOrigin-RevId: 63c00e44dd30766e873b8acdad09d6657657fad9
## Why
Renaming a writable directory could move protected descendants outside the
paths covered by their read-only or unreadable policy entries.
## What changed
- Deny unlink-style writes to directory ancestors of protected paths, placing
these rules after broader write allowances in the generated Seatbelt policy.
- Apply full write denies to unreadable glob matches and protect their directory
ancestors against renames.
- Support brace alternation and backslash escapes when translating filesystem
globs into Seatbelt regular expressions.
## Testing
Add coverage for ancestor rename attempts across explicit read-only and deny
entries, multiple glob forms, canonicalized glob paths, and the new glob syntax.
GitOrigin-RevId: edfda9d4c2bc7ba2ecd6b67744446871e526084f
## Why
A sandboxed process could replace a writable directory root, changing the
authority boundary used to construct a later sandbox policy.
## What changed
- Deny unlinking or renaming directory roots granted write access by Seatbelt,
while preserving replacement and deletion behavior for writable files.
- Reject writable roots with nested symlink components and report these as
Seatbelt preparation errors instead of network proxy failures.
- Normalize writable roots before adding them to the generated Seatbelt policy.
## Testing
Add coverage for symlink rejection, error classification, directory-root
replacement and rename protection, newly created roots, and writable file
replacement.
GitOrigin-RevId: ab1ed4e55f20034bc43e028e6529d3d1f0d8181c
## Why
A stored permission grant may allow access to a parent while explicitly denying
a child path. A later request for that child must not be treated as already
approved by the broader parent grant.
## What changed
- Compare materialized permission profiles without intersecting away denied or
reopened paths before deciding that a request is preapproved.
- Execute preapproved commands with the stored grant itself so its denied paths
remain enforced.
- Fail closed when permission profiles cannot be materialized.
## Testing
Added unit and integration coverage for turn and session grants across
`exec_command`, `shell_command`, and `apply_patch`, including approval-disabled
and `Never` approval modes.
GitOrigin-RevId: 5455880328a89c7958f859c7ce87805dff9704fb
## Why
Filesystem permission paths can use a convention that differs from the host
running Codex. Converting them immediately to native absolute paths can change
the meaning of ambiguous paths such as `/C:/secret` or Windows UNC paths.
## What changed
- Store literal filesystem permission paths as `PathUri` values through the
runtime policy and execution protocol.
- Keep legacy string-based serialization at explicit protocol boundaries and
reject conversions that cannot be represented losslessly.
- Encode native paths as opaque URIs when a normal file URI would imply the
wrong path convention.
## Testing
Added coverage for cross-platform and ambiguous path round trips, UNC path
variants, permission-profile serialization, and deny-policy enforcement.
GitOrigin-RevId: 5247713796d1f2bb4e02f94eb9fc82d4698060f0
## Why
Filesystem helpers only need access to their own executables. Granting access to
the containing directories also makes unrelated sibling files readable.
## What changed
- Allow filesystem helpers to read the Codex and Linux sandbox executables
directly instead of their parent directories.
- Give macOS filesystem helpers a narrower Seatbelt profile that omits the
normal process sandbox's `/Applications` read access.
- Preserve the existing platform defaults for normal sandboxed processes.
## Testing
Add unit and integration coverage for direct and symlinked sibling-file access,
sandboxed copies, allowed workspace reads, and the macOS-specific Seatbelt
profiles.
GitOrigin-RevId: 9380c6868a695bdf2275baa74bd5e8a30a64ba1b
## What changed
Implement `From<AbsolutePathBuf>` for `FileSystemPath` and use the conversion
when constructing concrete filesystem permission paths.
GitOrigin-RevId: 244bcbd0c3f76cd87cc1240458fcac6c9ef0a8e3
## Why
Cross-platform remote `apply_patch` calls were rejected when filesystem writes
were restricted because patch verification and writes could not be safely
performed against executor files.
## What changed
- Route intercepted and direct remote patches through the executor-managed
filesystem sandbox, including the configured workspace roots.
- Select the restricted-token sandbox for Windows executor paths when no
Windows sandbox level was configured.
- Fail closed when an executor cannot enforce the requested sandbox, and treat
executor-managed access failures as sandbox denials so approval can retry the
patch without sandboxing.
## Testing
- Cover sandboxed remote patches, denied writes, approval retries, Windows
sandbox selection, and executor filesystem enforcement.
GitOrigin-RevId: caddeed0b266c456a689080a14a3a58e2bd7887c
## Why
Managed networking implicitly selected the elevated Windows sandbox backend,
even when the sandbox was configured to use a restricted token.
## What changed
- Select the Windows sandbox backend solely from `WindowsSandboxLevel`.
- Reject managed networking with a restricted-token sandbox before spawning a
process, since managed networking requires the elevated backend.
- Cover the rejection through sandbox preparation, unified exec, and Windows
sandbox session tests.
GitOrigin-RevId: 308858652d7b629af623d22896dafde3a23d3758
## Why
The `:slash_tmp` filesystem entry represents the Unix `/tmp` directory and
should not affect Windows sandbox policy decisions.
## What changed
- Ignore symbolic `SlashTmp` entries when resolving Windows filesystem access,
converting permission profiles, and intersecting requested permissions.
- Continue treating a literal `/tmp` entry as a regular filesystem path.
## Testing
Add Windows-specific coverage for policy conversion, access checks, and
permission-profile intersection.
GitOrigin-RevId: f4cdd37ea41abc9debfe8a0d3a456b70da5e534c
## Why
Filesystem denials and managed-network blocks did not share a structured event
shape, requiring downstream consumers to rediscover enforcement paths and parse
backend-specific output. See https://github.com/openai/codex/pull/17573.
## What changed
- Add normalized filesystem and network violation types in `codex-sandboxing`
and emit them through a shared tracing seam.
- Classify filesystem denials by backend and reason, retaining an optional path
and bounded output snippet, and preserve managed-network block context.
- Report the sandbox type through exec-server responses so unified exec can
classify remote denials without guessing; omitted values remain compatible
with older peers.
- Record violations from exec, apply-patch, shell-escalation, unified-exec, and
managed-network enforcement paths without changing denial behavior.
## Testing
- Cover filesystem classification, path extraction, `SIGSYS`, network event
conversion, protocol compatibility, and remote sandbox-type propagation.
GitOrigin-RevId: d673173b4fa6bdf0a24421194a8a61c81fab9c96
## What changed
- Pass the canonical `PermissionProfile` through execution requests, sandbox
selection, escalation, and the exec server instead of carrying separate
derived filesystem and network policies.
- Derive runtime sandbox policies from the effective profile at their points of
use, including after applying additional permissions.
- Update sandbox and escalation tests to inspect policies through the profile.
GitOrigin-RevId: 695b82ea94f5289516b0933bb23074cb2dcce8ac
## Why
Elevated Windows sandboxes need stable managed-proxy ports while preserving the network policy and environment attribution of each sandboxed process.
## What changed
- Keep shared HTTP and SOCKS5 loopback ingress listeners alive across managed-proxy instances.
- Add a per-route restricting SID to elevated sandbox tokens and dispatch incoming connections to the matching proxy policy after attributing the client process.
- Reject connections without exactly one registered route, remove routes when their proxy handle is dropped, and keep unsandboxed Windows launches off the managed ingress.
- Provision the elevated sandbox with the configured proxy ports and local-binding setting, honoring the selected profile and CLI overrides.
## Testing
- Add Windows unit tests for TCP ownership attribution, route selection, restricting-token propagation, and setup settings.
- Add an end-to-end Windows test covering stable ports, isolated environment policies, HTTP and SOCKS5 routing, and route teardown.
GitOrigin-RevId: 783fac6e0f904dc9bb1955b75d4a5895e8bb9690
## Why
Default read-only protections for project metadata should apply when paths such
as `.git`, `.agents`, and `.codex` exist, without causing sandbox setup to
materialize missing paths as ACL targets.
## What changed
- Add an optional `missing_path_behavior` to filesystem sandbox entries and
mark default project-metadata protections with `skip`.
- Preserve the behavior through permission transforms and exec/MCP protocol
serialization while keeping existing path wire variants stable.
- Ignore skip-missing entries when projecting configuration or Windows sandbox
overrides, while retaining explicit metadata carveouts.
## Testing
- Cover protocol round trips for path and special-path entries.
- Verify default metadata protections and Windows explicit carveout handling.
GitOrigin-RevId: 6df13dadacdd131c44aab9f15a967c81051355c1
## Why
Sandboxed process launch through the exec server was unsupported on Windows.
## What changed
- Add a shared native process launcher that selects the Windows sandbox session backend when required and otherwise launches PTY or pipe-based processes.
- Pass Windows permission, workspace-root, proxy, filesystem-override, and desktop settings through exec-server process preparation.
- Preserve piped stdin and inherited file descriptors across the shared launch path.
## Testing
- Verify that a remote Windows sandbox process accepts stdin while blocking a write under a read-only policy.
- Enable workspace-root sandbox tests on native Windows while continuing to skip environments that cannot emulate Windows sandbox semantics.
GitOrigin-RevId: 6719ccbe87ad0d5a57af56503e3f23f894c60a71
## What changed
- Represent built-in filesystem policy entries with the same `Path` and
`Special` variants used by other entries.
- Remove generated-default filtering from Windows sandbox policy resolution and
simplify elevated deny-write handling to rely on direct-runtime enforcement
and the legacy policy projection.
- Update protocol conversions, policy transforms, and profile expectations for
the reduced filesystem path model.
GitOrigin-RevId: a65793e6855a03d52a575e82cb3d4b9b2e32db5c
## Why
Windows firewall enforcement is tied to the logon-user sandbox identities. Proxy-enforced commands therefore need the elevated backend even when the configured sandbox mode is the default restricted-token mode.
## What changed
- Select the elevated Windows sandbox backend whenever a command uses the managed network proxy.
- Remove configuration and startup checks that required users or managed requirements to select the elevated sandbox explicitly.
- Start and expose managed network proxy state consistently on Windows.
## Testing
- Verify that proxy enforcement selects the elevated backend for the restricted-token sandbox mode.
GitOrigin-RevId: e01ac052587721c468a8fbcf4e2c7c5a185a3e05
## Why
Elevated Windows sandbox setup could turn the built-in read-only protections
for workspace metadata into deny-write paths, creating metadata directories
that did not already exist.
## What changed
- Track whether filesystem permission entries come from a built-in profile or
were explicitly configured.
- Exclude generated metadata defaults from direct Windows deny-write overrides
while continuing to enforce explicit read-only carveouts for the same paths.
- Preserve the distinction while materializing and normalizing permission
paths, without exposing generated defaults as user configuration.
## Testing
Added Windows coverage confirming that elevated sandbox setup leaves missing
workspace metadata absent and still produces overrides for explicit metadata
carveouts.
GitOrigin-RevId: 701bcb229f631b18ab5ced22f3edf6f303d932f3
## Why
Network proxy enforcement on Windows requires the elevated sandbox backend. Silently selecting that backend for an unelevated configuration makes the effective sandbox differ from the configured mode.
## What changed
- Reject enabled network proxy configurations on Windows unless managed requirements allow only the elevated sandbox and `windows.sandbox` resolves to `"elevated"`.
- Preserve the configured sandbox backend during execution and validate proxy compatibility at config loading, sandbox setup, and process launch boundaries.
- Defer this validation during cloud-config bootstrap so authoritative managed requirements can be loaded first.
- Do not start or expose disabled Windows proxies, and render transitions to disabled networking as `<network enabled="false"></network>`.
## Testing
- Cover Windows requirement and sandbox compatibility matrices, bootstrap behavior, backend selection, disabled proxy handling, and environment-context updates.
GitOrigin-RevId: bfa1dda98594e0db61883f8e7f65bd560e3453e6
## Why
PR #31767 flattened `NetworkProxyConfig`, leaving the [seatbelt test
setup](https://github.com/openai/codex/blob/d72d669ca727a26765315ffe03db3dd2594d9b91/codex-rs/sandboxing/src/seatbelt_tests.rs#L660-L662)
to assign fields directly after `NetworkProxyConfig::default()`. Rust
1.95 flags that pattern as `clippy::field_reassign_with_default`, and
the macOS Bazel Clippy job treats the warning as an error, blocking
`main` and PRs based on it.
## What Changed
Initialize `enabled` and `mode` in the `NetworkProxyConfig` struct
literal, then apply the Unix socket allowlist through the existing
setter. This preserves the test behavior while satisfying Clippy.
## How to Test
This is a test-only initialization change, so there is no manual product
flow.
Targeted tests:
- `just test -p codex-sandboxing` (65 passed)
- `just clippy -p codex-sandboxing`
The local argument-comment lint could not complete because Bazel's LLVM
repository is missing the `compiler-rt` BUILD package. The touched Rust
diff was manually audited and adds no positional literal calls.
## Why
`NetworkProxyConfig` only wrapped `NetworkProxySettings` in a single
`network` field. That extra level made runtime callers repeat `.network`
everywhere without representing a real boundary.
## What changed
- move the managed-network fields directly onto `NetworkProxyConfig`
- collapse the matching partial-config wrapper
- update runtime callers and tests to use the direct fields
- keep the user-facing permissions/profile TOML layout unchanged
The internal serialized shape now matches the runtime type itself. This
does not change managed-network behavior or the `config.toml` shape.
## Why
Filesystem helpers intentionally run with a minimal environment that
excludes proxy variables. After filesystem operations started using the
Windows sandbox wrapper, the wrapper derived an empty proxy
configuration from that helper environment and compared it with the
persistent sandbox setup marker. When the marker contained proxy ports,
every filesystem operation appeared to require a firewall update, which
could launch elevated setup, show a UAC or loader dialog, and fail
operations such as `apply_patch` with error 1223.
Filesystem helpers do not use network access, so they should preserve
the proxy/firewall state established by normal sandboxed process
launches.
## What changed
- Add an explicit Windows sandbox proxy-settings mode for reconciling or
preserving persistent proxy state.
- Use preserve mode for filesystem helpers while normal process launches
continue to reconcile proxy settings from their environment.
- Carry the selected proxy state consistently through setup validation,
elevated setup, and non-elevated ACL refreshes.
- Cover wrapper argument propagation and marker-derived proxy
preservation.
## Validation
- `cargo build -p codex-cli --bin codex`
- `just test -p codex-windows-sandbox
preserving_proxy_settings_uses_the_existing_marker`
- `just test -p codex-windows-sandbox windows_wrapper_args_round_trip`
- `just test -p codex-windows-sandbox
setup_request_prefers_explicit_proxy_settings`
- `just test -p codex-sandboxing transform_for_direct_spawn_windows`
- `just test -p codex-exec-server fs_sandbox::tests`
- Ran the same sandboxed `fs/writeFile` reproduction against published
`0.142.0-alpha.6` and the new CLI. The published CLI launched elevated
setup and failed with `ShellExecuteExW ... 1223`; the new CLI completed
without elevation.
Related to #28359.
Sean Huang