## Why
Windows sandbox setup reconciles persistent deny ACLs against the paths supplied for a session. The `codex sandbox --permission-profile` path supplied an empty list, which could discard the profile's deny-read restrictions.
## What changed
Resolve deny-read paths from the selected permission profile and workspace roots before starting a Windows sandbox session, and pass them through to setup.
## Testing
Add a Windows CLI integration test that launches the same managed-deny profile twice and verifies that denied file reads and DLL loads remain blocked while allowed access still works.
GitOrigin-RevId: 6ec8b6a13a33b862d7b152eadbbdde3146de4b7d
## What changed
- Build `codex-command-runner` as a Windows-subsystem binary outside tests.
- Launch non-TTY sandbox commands without a console window.
- Suppress the busy cursor when creating the elevated runner process.
GitOrigin-RevId: fc6b70059add7dea642805030bd508915367fe44
## 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
## What changed
- Record the authenticated sandbox owner and observe package uninstall events across service restarts and session changes.
- During uninstall, serialize setup and cleanup, disable sandbox accounts, stop their processes, and remove sandbox directories, firewall and WFP rules, hidden-user entries, accounts, and the sandbox group.
- Restrict desktop-owned directory cleanup to pinned paths and perform it while impersonating the authenticated owner.
- Detect missing or disabled sandbox accounts after interrupted cleanup and reprovision them before restoring network access.
GitOrigin-RevId: 7d63fff7ddcff3eb01d018653146df12044bd277
## Why
The Windows sandbox service had provisioning policy and client authentication in place, but its IPC listener was still disabled.
## What changed
- Serve framed provisioning requests over a local named pipe, authenticate packaged clients, validate requests and machine policy, and report provisioning outcomes through bounded responses and Windows event logging.
- Return `unavailable` for configuration parse failures so clients can fall back to the elevated setup helper.
- Keep validated directory handles alive in the setup helper so path protections survive an unexpected service exit.
- Make connection recovery and shutdown wakeups tolerate clients that disconnect before the listener accepts them.
## Testing
Added Windows tests for response framing, configuration-error classification, pipe security and reconnect behavior, shutdown wakeups, and retained helper handles.
GitOrigin-RevId: 68e9d546dcada88ff162ea4f98c0f4d748706b34
## Why
Windows sandbox provisioning performs privileged work beneath a requested Codex home. Provisioning paths and output entries must remain bound to the files and directories that were validated, without following reparse points or writing through caller-controlled hard links.
## What changed
- Add reusable no-reparse directory opens, path validation, directory guards, and handle-relative atomic file replacement.
- Use fresh or retained handles for provisioning logs, sandbox credentials, setup markers, and error reports in service provisioning mode.
- Add service-side validation for framed provisioning requests, proxy settings, fixed-drive Codex homes, and pinned sandbox directories.
## Testing
Add Windows tests covering junction and unsafe-path rejection, hard-link-safe output replacement, retained output handles, request framing and normalization, and ancestor pinning.
GitOrigin-RevId: 2ec4f0d15404c3387df1414bb0c1915cf452ecf2
## What changed
- Add a client for the packaged Windows sandbox provisioning service that verifies the named-pipe server belongs to the running `CodexSandboxService` process before exchanging a versioned provisioning request.
- Treat an absent, busy, timed-out, or disconnected service as unavailable while surfacing provisioning and authentication failures.
- Send the complete `WindowsSandboxProvisioningSettings` and classify inherited HTTP and SOCKS proxy listeners separately for managed-policy validation.
- Share bounded frame-readiness handling between runner and provisioning IPC.
## Testing
- Extend proxy environment tests to cover network-enabled profiles, mixed HTTP and SOCKS listeners, explicit proxy-port overrides, case-insensitive schemes, and unclassified protocols.
GitOrigin-RevId: 6ff6741fc3ecd76314a7a045523a8d7a7e7af686
## What changed
- Define a versioned, length-prefixed JSON request/response protocol for the
machine-wide Windows sandbox provisioning service, including its named pipe
and network setup parameters.
- Add a readiness check that compares the recorded proxy ports and local-binding
policy with the requested provisioning settings.
- Share framed JSON I/O, sandbox-group creation, and SID resolution between the
existing elevated setup path and provisioning clients.
GitOrigin-RevId: d6250542d06f7646ffeb92150472e7d7fa1e5e66
## Why
An inherited write ACE from a writable parent directory could leave sandbox
runner files in `.sandbox-bin` writable or deletable by the workspace capability
SID.
## What changed
- Mark the `.sandbox-bin` DACL as protected when applying its explicit ACL, while
preserving inherited DACL behavior for the other persistent sandbox
directories.
- Cover both full and provision-only setup, including runner files created before
and after the directory is locked.
GitOrigin-RevId: fcda4df97e3f8d729438ccb3d42daa606076e0c4
## What changed
- Limit elevated interactive setup to provisioning sandbox identities and proxy settings; do not include caller workspace or ACL roots in its payload.
- Always run the non-elevated setup refresh during sandbox activation so the current permission profile supplies read, write, and deny paths, including when provisioning was completed previously.
- Add an `interactive-provision` setup mode that performs provisioning without the full ACL setup path.
## Testing
- Verify elevated provisioning payloads contain no caller ACL roots and use the new mode.
- Verify the setup helper accepts `interactive-provision` payloads.
GitOrigin-RevId: 081b1b43abd2388773c230fb35da82896e7be2ea
## Why
The root Python formatting pass only covered `scripts/`, leaving Python utilities elsewhere in the repository outside `just fmt` and `just fmt-check`.
## What changed
- Run the scripts Ruff formatter from the repository root.
- Exclude `sdk/python`, which has its own formatter pass, and `codex-rs/vendor`.
- Apply Ruff formatting to the newly covered Python files and update the formatter coverage test.
GitOrigin-RevId: 73ac82b8bb9c713d589724f6c4f926399febb513
## Why
Read-deny policies must use the target executor's path convention so URI-based
policy checks and native filesystem enumeration enforce the same rules.
## What changed
- Prepare deny roots and glob matchers from `PathUri` policy context, including
executor-relative working directories and home-relative patterns.
- Match Windows globs case-insensitively with normalized separators, while
preserving byte-oriented POSIX matching for non-UTF-8 paths.
- Fail closed for malformed paths, incompatible path conventions, unresolved
home-relative patterns, and invalid globs.
- Make Windows deny-read discovery use case-insensitive ripgrep glob matching.
## Testing
Added coverage for Windows URI conventions, executor home expansion,
case-insensitive `.env` discovery, malformed paths, non-UTF-8 names, and
canonical directory-link targets.
GitOrigin-RevId: 36001219a2e9b36acfce8972dc1d3bbc304271c5
Expand Windows deny-read globs robustly across protected directories while preserving filesystem enforcement. Preserve structured MCP tool and resource errors through app-server responses. Bind cached Guardian classifications to current local and root authorization state so stale scores cannot approve actions.
Add regression coverage for the sandbox resolver, structured protocol errors, and authorization changes.
GitOrigin-RevId: 4b80ed724d869afeca79204222d8465fa99d3a24
## What changed
- Return the number of directories flagged by successful Windows sandbox world-writable scans.
- Record that count in the `codex.windows_sandbox.world_writable_scan_flagged_directories` histogram for startup and warning-triggered scans.
- Tag each measurement with a `success` or `error` result, using a count of zero when the scan fails.
GitOrigin-RevId: 076160f36b1d62fa737f4b2d0318774e6c44a4b1
## Why
Windows filesystem operations can complete while their helper process remains
alive, and elevated sandbox processes must not survive a disconnected control
pipe.
## What changed
- Read newline-delimited filesystem helper responses without imposing an
operation deadline, then bound the time spent reaping the helper.
- Drain helper stderr concurrently, retain a bounded diagnostic on failure, and
kill helpers that do not exit after responding.
- Terminate the elevated runner's job or process when its input pipe closes or
fails.
## Testing
Added coverage for delayed responses, noisy stderr, stuck helpers, duplicated
file handles, and termination of elevated descendants after a control-pipe
disconnect.
GitOrigin-RevId: c0d3d5d76e13318de17638df4db71fcfb9a7397f
## Why
Private desktops need to remain available across command-runner exits and idle
gaps.
## What changed
- Keep parent-owned private desktops alive and reuse them only when the sandbox
account and effective permissions match.
- Pass the selected desktop name to elevated command runners, which validate and
open the existing desktop instead of creating their own.
- Apply the same policy-aware reuse to the legacy Windows sandbox path.
## Testing
Add Windows tests for desktop-name validation, lifetime and concurrent reuse,
and separation when effective permissions differ.
GitOrigin-RevId: 2df8b1c31ff22d72549f2ec3065cd80ea1dd0c6a
## 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
`SetSecurityInfo` can reject a directory handle opened with only `WRITE_DAC`.
## What changed
- Request `READ_CONTROL` alongside `WRITE_DAC` when opening or creating a
no-reparse sandbox directory.
- Add a Windows regression test that provisions and locks a plain sandbox
directory through the handle-based ACL path.
GitOrigin-RevId: bd50dc54d4cc80e9609323ddb4ecc7e4780a31fb
## What changed
- Detect readable symbolic `:root` entries separately from effective full-disk access so narrower deny-read rules do not disable the Windows sandbox's broad-read setup.
- Add explicit readable roots to that setup while omitting the filesystem root itself, and prevent read roots at or below denied paths from being granted access.
## Testing
- Extend the elevated Windows sandbox integration test to verify that an allowed bundled skill under the user profile remains readable while exact and glob-based secrets stay denied.
GitOrigin-RevId: 8f6f267b78718b9e8609a9205c489f253f478491
## Why
Sandbox setup runs on a Tokio worker thread without a Windows message loop, so
`ShellExecuteExW` requires synchronous activation when launching the elevated
setup helper.
## What changed
Add `SEE_MASK_NOASYNC` to the shell execution flags while retaining
`SEE_MASK_NOCLOSEPROCESS` for helper process tracking.
GitOrigin-RevId: 875cc1d49bb19f92f940633b6315711143beeae7
## Why
Installer `bin` directories can be junctions, so looking for bundled helpers
relative to the apparent executable path can miss the package's
`codex-resources` directory.
## What changed
Retry bundled executable lookup from the canonical executable path when lookup
from the original path fails.
## Testing
Add a Windows regression test that creates a `bin` junction and verifies that
the sandbox setup helper is resolved from the package resources directory.
GitOrigin-RevId: f2f20ce1ccfa95ae65171a03a986d10e2560e696
## What changed
- Report the configured Windows sandbox backend and whether denied-read restrictions are active.
- Diagnose incompatible backend policy, incomplete or failed elevated sandbox provisioning, unreadable setup failure reports, and missing, locked, disabled, or expired sandbox accounts.
- Provide issue-specific remediation and promote the sandbox check status and summary to the highest detected severity.
- Export the Windows sandbox setup data needed by the diagnostic check.
## Testing
- Cover missing Linux helpers and malformed or oversized Windows setup failure reports.
- Cover a recorded Windows sandbox refresh failure after setup completed.
GitOrigin-RevId: e965b703578a5c0597dcce9f836d2e1f510ad0c8
## Why
Windows sandbox preflight could report success when applying a deny ACE failed,
leaving a detected world-writable path without the intended capability
restriction.
## What changed
- Return errors from `SetEntriesInAclW` and `SetNamedSecurityInfoW`, including the
affected path in ACL API errors.
- Attempt every flagged path, aggregate deny-ACE failures, and fail preflight
after logging them.
- Preserve cleanup of security descriptors and newly allocated ACLs on failure.
## Testing
Added tests that verify ACL API failures are returned and that preflight keeps
processing remaining paths before propagating an error.
GitOrigin-RevId: e2be1c70f72840046dc55760364de7bcf3b1bdc9
## 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
Elevated provisioning can apply ACLs beneath a user-supplied `CODEX_HOME`.
Following a directory junction or another reparse point could apply those ACLs
to a different directory than the one provisioning intended to secure.
## What changed
- Require provisioning paths to be absolute paths on a local Windows disk.
- In provision-only mode, open or create sandbox directories with
`OBJ_DONT_REPARSE` and keep the resulting handle open while applying ACLs
with `SetSecurityInfo`.
- Reject reparse points in both the final directory and its ancestors while
preserving the existing path-based behavior for full setup.
## Testing
Add Windows tests covering plain directory creation and rejection of junctions
at both the leaf and ancestor levels.
GitOrigin-RevId: d165b8b3685c89bc171e4d58c63c739fa9fb2cf9
## Why
Creating the telemetry shutdown thread during shutdown can fail under resource
pressure, including when the native thread guard page cannot be allocated.
## What changed
- Start and verify a dedicated shutdown worker when `OtelProvider` is created.
- Send the provider to the prepared worker for bounded shutdown, while preserving
timeout behavior and avoiding a potentially blocking destructor if worker
preparation failed.
- Rename the fallible provider constructor to `try_new`.
## Testing
Add Unix regression coverage that injects guard-page allocation failures, plus
coverage for worker preparation failure, successful shutdown, and timeouts.
GitOrigin-RevId: 3656298078a800a7fa392437c2ee4a68753092e3
## Why
Windows sandbox requests must preserve managed filesystem deny rules across every execution path and setup refresh. Unsupported policies should fail closed instead of allowing a command to run without the requested protection.
## What changed
- Resolve Windows filesystem overrides while constructing each sandbox execution request so both `shell_command` and `exec_command` enforce exact-path and glob deny-read entries.
- Carry resolved deny-read paths into Windows sandbox setup refreshes, including workspace-relative entries.
- Reject unelevated restricted-token requests that cannot enforce deny-read rules.
- Reject recursive globs rooted at a filesystem root unless `glob_scan_max_depth` bounds their expansion.
## Testing
Added coverage for deny-read enforcement through both command runtimes, setup refresh resolution, restricted-token failure, and bounded root-level glob scans.
GitOrigin-RevId: 33dfa4d1a45b14850cbf58f9173717e3e707d9bf
## Why
`rules_rust` drops the build script's per-binary linker directives, so Bazel
builds can omit the `asInvoker` manifest from the Windows sandbox setup helper.
## What changed
- Add per-binary compile data and Rust flags to `codex_rust_crate` so linker
inputs remain scoped to the setup helper.
- Embed the manifest directly for MSVC builds and compile it into a resource
with hermetic LLVM tooling for GNU/LLVM cross-builds.
- Disable the redundant build script under Bazel and avoid duplicating binary
runfiles in integration test data.
## Testing
Add a Windows integration test that loads the setup executable's manifest
resource and verifies that it requests `asInvoker` execution with UI access
disabled.
GitOrigin-RevId: a77e7e627ee43810f5eaf7701bb4909bf855216b
## Why
Git rejects repositories owned by the primary user when commands run as the
sandbox user. Trusting only the enclosing worktree leaves nested repositories
unavailable.
## What changed
Add both the worktree root and its `/*` wildcard to Git's `safe.directory`
environment configuration. Update the directory and gitfile unit tests to
expect both entries.
GitOrigin-RevId: 4b8e2bc8cc52cff580451ffbd17eb71325957404
## What changed
- Apply the sandbox read/execute ACL to the local Codex application root so it
inherits across its contents, while continuing to handle the managed runtime
cache separately.
- Skip missing paths, non-directories, and directory reparse points before
inspecting or updating ACLs.
- Update the runtime path test to expect the application root.
GitOrigin-RevId: 34f2946d2140f8ea2b76c449b0e5542b99cb6f70
## 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
Windows non-TTY exec sessions reported interrupts as unsupported, so sending
Ctrl-C through `write_stdin` did not stop the running process.
## What changed
- Route interrupt requests for Windows non-TTY processes through their existing
termination callback, including pipe-backed processes.
- Track whether driver-backed Windows sessions use a TTY so PTY interrupts keep
their existing behavior.
- Consume the terminator after a successful interrupt to avoid invoking it again
when the process handle is dropped.
## Testing
Added coverage for local and remote exec-server sessions, unified exec, pipe
fallbacks, and legacy Windows sandbox processes.
GitOrigin-RevId: 34504d01f091ef57bb961e98ad5a8d9f1acee4ee
## What changed
- Include CLI snapshot files in Bazel test runfiles.
- Restrict the Windows sandbox binary test target to Windows.
- Label boolean and optional arguments in the affected CLI tests.
GitOrigin-RevId: c248396c51d881c38856739d7d9b653dcde1823e
## Why
Guardian review commands can run without the proxy-port environment used to
configure the parent session. Reconciling persistent Windows sandbox settings
for those commands can discard the parent's proxy configuration.
## What changed
- Add a session-level Windows sandbox proxy-settings mode and use `Preserve`
for guardian review sessions while keeping `Reconcile` as the default.
- Carry the mode through unified exec and the exec-server sandbox context to
Windows process launches.
- In preserve mode, reuse the proxy settings recorded by the existing sandbox
setup marker.
## Testing
Added coverage for guardian session configuration, exec-server transport, and
preserving an existing setup marker when proxy-port environment variables are
absent.
GitOrigin-RevId: 214655c6e6d97360906431773dc0de0fdda2db6e
## What changed
- Check writable-root permissions for the sandbox group and root capability SID from a single DACL snapshot, and refresh the ACL when either SID is missing the required access or has a stale explicit delete-child grant.
- Start the command runner without loading a user profile and poll more frequently while waiting for it to become ready.
- Make the Windows sandbox binaries available to Bazel tests.
## Testing
- Add coverage that verifies ACL refresh checks every requested SID.
- Add an elevated non-TTY command test that verifies environment forwarding, stdout, and exit-code propagation.
GitOrigin-RevId: 657ed9dc906039299f9ffa4772e0926c47066a73
## Why
Terminating a Windows execution session must also stop child processes, while a
normal root-process exit must continue to allow background descendants to run.
## What changed
- Assign Windows pipe, ConPTY, and sandbox processes to job objects and terminate
the job when a session is cancelled, times out, or is explicitly stopped.
- Preserve descendants when the root process exits normally.
- Attach ConPTY and sandbox processes to their jobs atomically at creation; keep
root-process termination as a fallback where job setup is unavailable.
## Testing
Added Windows coverage for descendant termination and preservation across pipe,
ConPTY, capture, cancellation, and legacy sandbox execution paths.
GitOrigin-RevId: 8f831f2fc4caaa7b79ce842a3ed7192bd02dd3b4
## 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
## What changed
Redirect stdin to null when launching:
- `codex doctor --json` for uploaded diagnostic reports
- Git commands used by `codex doctor`
- ripgrep searches over rollout files
- the Windows sandbox setup refresh helper
This keeps these non-interactive subprocesses from reading Codex's inherited
input stream.
GitOrigin-RevId: 063d191b0b1b849d74b55a7d6ff2f0b3d5212c86
## 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
An inherited `FILE_DELETE_CHILD` grant can make a write root look stale, but
`SET_ACCESS` cannot replace an ACE inherited from an ancestor. Treating that
grant as explicit causes unnecessary ACL refresh attempts that cannot converge.
## What changed
- Add explicit-ACE filtering to the Windows DACL permission checks.
- Refresh a write root only when `FILE_DELETE_CHILD` is present in an explicit
allow ACE, while retaining effective-permission checks for required rights.
- Ignore inherited stale rights when deciding whether `SET_ACCESS` must repair
an allow ACE.
## Testing
Add a Windows regression test covering a write root that inherits
`FILE_DELETE_CHILD`, verifying that repeated refresh checks leave its explicit
write ACE unchanged.
GitOrigin-RevId: d0df9429efcf299da3ff3c1bce92942684803293
## 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
Concurrent callers can submit the same Windows sandbox setup payload while an
identical helper invocation is already running.
## What changed
- Share one in-flight helper invocation among setup and refresh requests with
identical serialized payloads.
- Return the shared success or failure to every waiter while preserving
structured setup error codes, then allow subsequent requests to run again.
## Testing
- Add a concurrency test that verifies identical requests execute the setup
operation once.
GitOrigin-RevId: 18ebbcb9b36de3eb5912b8bbbe153d39328b5e48
## 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
## What changed
- Add a console mode to the Windows sandbox process launcher.
- Launch `--codex-run-as-fs-helper` subprocesses with `CREATE_NO_WINDOW`.
- Preserve inherited-console behavior for regular sandboxed commands.
GitOrigin-RevId: 927be36b82903b6a5fb1a243ba7f406f9ed85f3f
## Why
Codex Desktop installs its managed primary runtime under
`%USERPROFILE%\.cache\codex-runtimes`. Elevated Windows sandbox commands
run as dedicated sandbox users. The synchronous runtime ACL refresh
repairs read/execute access for the Desktop runtime directories under
`%LOCALAPPDATA%\OpenAI\Codex`, but did not include the managed primary
runtime cache.
As a result, the Desktop app could discover a bundled runtime while a
sandboxed command received `ACCESS_DENIED` when reading or executing it.
## What changed
- Include `%USERPROFILE%\.cache\codex-runtimes` in the managed runtime
paths considered by the Windows sandbox ACL refresh.
- Reuse the existing inherited read/execute ACL repair; no write
permission is added.
- Add Windows-target regression coverage for the runtime path list and
the primary-runtime-only case.
## Impact
Bundled Python, Node, and native tools remain usable from elevated
Windows sandbox sessions without broadening write access or granting
access to the rest of the user profile.
## Validation
- `just fmt`
- `just test -p codex-windows-sandbox` (10/10 host-side tests passed)
- Windows-target path tests included for CI
## Why
The legacy unelevated Windows sandbox allowed tools to create and update
files in workspace-write roots, but it could not delete files that
already existed there. This breaks operations such as `apply_patch` file
deletion and replacement in the workspace, `TEMP`, and `TMP`.
The delete grant must also preserve deny-write carveouts. Granting
`FILE_DELETE_CHILD` on a writable parent would let the sandbox remove
protected children such as `.git` or an explicit read-only subpath even
when those children have direct deny ACEs.
This addresses the delete-failure variant reported in #30009 and #30712.
It does not claim to fix their separate split-root setup,
elevated-helper, or proxy-related failure modes.
## What Changed
- Give writable-root capability ACEs inheritable `DELETE` rights without
granting parent-level `FILE_DELETE_CHILD`, so descendants can be removed
while protected children remain protected.
- Replace stale write ACEs that still contain `FILE_DELETE_CHILD`, and
make elevated setup detect and refresh that unsafe legacy state.
- Keep read-only capability handling unchanged.
- Add Windows regressions covering pre-existing files in the workspace,
`TEMP`, and `TMP`, plus protected `.git` and outside-root controls.
The core ACL behavior is in
[`acl.rs`](767540eec3/codex-rs/windows-sandbox-rs/src/acl.rs (L303-L438)),
stale-ACE detection is in
[`setup_main/win.rs`](767540eec3/codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs (L163-L179)),
and the end-to-end regression is in
[`unified_exec/tests.rs`](767540eec3/codex-rs/windows-sandbox-rs/src/unified_exec/tests.rs (L458-L568)).
## How to Test
On Windows:
1. Start Codex with the legacy unelevated Windows sandbox and a
workspace-write permission profile.
2. Seed pre-existing files in the workspace, `TEMP`, and `TMP`; also
create a sibling file outside the writable roots and a protected `.git`
directory.
3. Delete the three files inside writable roots through a sandboxed
command or `apply_patch`.
4. Confirm the writable-root files are deleted, while the outside-root
file and protected `.git` directory remain intact.
Targeted tests:
- `just test -p codex-windows-sandbox`
- Windows-only
`legacy_workspace_write_delete_is_limited_to_writable_roots`
- Windows-only `write_root_refresh_replaces_stale_delete_child_grant`
The final SHA passed all 31 required checks, including the Windows Bazel
test matrix, in [run
28886245161](https://github.com/openai/codex/actions/runs/28886245161).
## Summary
- keep the child error 1312 credential retry for normal executables
- return WindowsApps/AppX launch errors directly instead of rotating
sandbox credentials and retrying the same command
## Why
Windows AppX activation can return `ERROR_NO_SUCH_LOGON_SESSION` (1312)
even when the sandbox token is healthy. For executables under
`WindowsApps`, refreshing the sandbox account password cannot fix that
activation failure; it only triggers elevated setup before the same
command fails again.
This is a focused follow-up to #29624.
## Summary
- recognize stale Windows sandbox credentials from both runner logon and
child startup failures
- refresh credentials once without changing the original command,
permissions, file rules, desktop mode, or managed-network identity
- add a Windows regression test that forces error 1312 and inspects the
real retry arguments
## Why
Elevated unified exec starts commands in two steps:
```text
Codex -> sandbox command runner -> requested command
```
Either process start can fail when Windows invalidates the sandbox logon
session. The child-side failure was previously returned as text, so the
parent could not reliably recognize Windows error 1312.
The existing retry also refreshed credentials with `proxy_enforced =
false`, even when the original request used managed networking. That
could change the selected Windows sandbox identity from offline to
online during the retry.
## How
- carry the failure stage and numeric Windows error code through the
command-runner IPC protocol
- preserve native `CreateProcessAsUserW` error codes instead of parsing
error messages
- keep every retry-sensitive field in one request and use it for both
attempts
- retry exactly once after refreshing credentials, then return the
second failure
- share the retry rule with the elevated capture path
The Windows test injects error 1312 on both attempts and verifies:
- two spawn attempts and one credential refresh
- stale credentials are replaced by refreshed credentials
- both attempts receive the same command, environment, cwd, permissions,
roots, deny paths, TTY settings, and private-desktop mode
- credential refresh receives the original `proxy_enforced` value
## Tests
- `just test -p codex-windows-sandbox`
- the new Windows-only regression test is included in the Windows
nextest CI archive
## Why
Windows unified-exec TTY input did not behave like the non-Windows PTY
path. ConPTY sessions could receive the wrong line ending or mishandle
backspace, especially when sending input to a foreground program through
PowerShell or cmd. The local, legacy restricted, and elevated paths also
handled this normalization separately.
## What changed
- share one stateful Windows TTY input normalizer across local, legacy
restricted, and elevated runner paths
- translate LF and split CRLF into one Windows terminal Enter, encode
backspace as DEL, and preserve UTF-8 and control bytes such as Ctrl-C
- add Windows integration coverage for Unicode input, backspace, Enter,
and PowerShell foreground-child Ctrl-C behavior
## Validation
- `just test -p codex-utils-pty` (13 tests passed; the Unicode
integration test retried once)
- the Unicode integration test passed five consecutive runs with retries
disabled
- integration coverage sends `cafeé 漢字` through cmd and PowerShell and
verifies that Ctrl-C interrupts a running PowerShell foreground child
## 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.
