Fix Windows fs-helper sandbox bypass

[iceweasel-oai]

Why

The exec-server filesystem helper path is a direct-spawn path: it asks SandboxManager for a SandboxExecRequest, then launches the returned argv itself. That is safe on macOS/Linux because the transformed argv is a self-contained sandbox wrapper (sandbox-exec / codex-linux-sandbox). On Windows, the transform result carried WindowsRestrictedToken sandbox metadata, but the filesystem helper runner still spawned the helper argv directly.

As a result, Windows filesystem built-ins that route through the fs-helper could run with the parent Codex process permissions instead of the configured Windows sandbox. In practice, that means a helper-backed operation could write where the active permission profile says it should not.

What Changed

• Added a hidden Windows arg1 wrapper, --run-as-windows-sandbox, so direct-spawn callers can receive a self-contained Windows sandbox argv.
• Added SandboxManager::transform_for_direct_spawn, which preserves the existing transform behavior for normal command execution but wraps Windows restricted-token requests for direct-spawn callers.
• Updated the fs-helper runner to use the direct-spawn transform.
• Materialized the inner Codex helper executable into .sandbox-bin before it is launched by the sandboxed user.
• Moved the Windows sandbox stdio bridge out of the debug CLI path so codex sandbox windows and the hidden wrapper share the same forwarding code.
• Carried runtime workspace roots through FileSystemSandboxContext so symbolic :workspace_roots policies are resolved correctly for the wrapped helper.
• Ensured the outer wrapper setup env gets authoritative USERNAME / USERPROFILE values while preserving the serialized inner command env.

Verification

• just test -p codex-sandboxing transform_for_direct_spawn_windows
• just test -p codex-windows-sandbox windows_wrapper_args_round_trip
• just test -p codex-exec-server fs_sandbox::tests
• just test -p codex-core apply_patch
• Manual built-binary check: --run-as-windows-sandbox -- ... --codex-run-as-apply-patch patched an allowed file and failed to write a denied file.
• Manual built-binary check through codex exec-server --listen stdio: fs/writeFile wrote inside the allowed root, failed with Access is denied. (os error 5) outside it, and used the materialized helper at .sandbox-bin/codex.exe.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 32fab729cf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Refresh Bazel lock for the dependency change

This Cargo.toml change adds a Windows-only dependency but MODULE.bazel.lock is unchanged, so Bazel crate resolution can drift and just bazel-lock-check/Bazel builds can fail for the Windows dependency set; refresh and include the Bazel lock with the dependency edit. guidance

Useful? React with 👍 / 👎.