Windows elevated sandbox fails on session-scoped mapped-drive cwd with error 267

What version of Codex are you using?

Codex Desktop package 26.803.10989.0; source reproduction and candidate fix were made from openai/codex main at b1373b74a27d1d9b65074a873202683355cae772.

What platform are you using?

Windows 11 x64, elevated Windows sandbox, workspace on a session-scoped mapped drive.

What issue are you seeing?

The elevated sandbox runner is launched with CreateProcessWithLogonW. When lpCurrentDirectory is a mapped drive visible in the interactive parent session but absent from the sandbox user's logon session, runner startup fails with Windows error 267 (ERROR_DIRECTORY).

This is especially visible with provider-backed drives such as Google Drive, but the underlying launch defect also reproduces safely with a temporary SUBST/DOS-device mapping.

The requested command cwd and the runner process's bootstrap cwd are currently conflated. The former belongs in the IPC SpawnRequest; the latter must be a path visible to the sandbox logon session.

Steps to reproduce

1. Create a temporary mapped drive backed by a disposable local directory.
2. Call CreateProcessWithLogonW using the existing Codex sandbox account and the mapped-drive directory as lpCurrentDirectory.
3. Repeat with the resolved local backing directory.

Observed controlled result:

• mapped-drive cwd: launch fails with Windows error 267;
• resolved C:\... backing cwd: launch succeeds with the same executable, account, and logon flags.

On the affected provider drive, QueryDosDeviceW returns an opaque virtual-volume device target rather than a verifiable local or UNC backing.

Expected behavior

• Bootstrap the command runner from its materialized local executable directory.
• Keep the user-requested cwd inside the IPC spawn request.
• Resolve verified DOS-device mappings before ACL/capability materialization so ACL paths and IPC paths remain identical.
• Fail closed with an actionable diagnostic when a provider/virtual device has no verifiable session-independent backing; do not fall back to the interactive user.

Candidate fix

A reviewed candidate is available at:

• Branch: https://github.com/webby888/codex/tree/codex/windows-sandbox-mapped-drive-fix
• Commit: https://github.com/webby888/codex/commit/1572eaf1892f85a91c3a07f308b91874e63cf5f4

It:

• separates runner bootstrap cwd from requested command cwd;
• resolves verified \??\C:\... and \??\UNC\... mappings before permission materialization in both elevated execution paths;
• memoizes drive targets for a consistent per-request snapshot;
• keeps security-bearing paths fail-closed;
• preserves unresolvable environment-only values for compatibility;
• rejects unknown provider/device targets with an explicit diagnostic;
• adds regression coverage for translation, virtual-device rejection, verbatim and drive-relative paths, self-referential mappings, runner bootstrap, and retry behavior.

Validation:

• focused regression suite: 6/6 passed;
• non-UAC crate suite: 142/142 passed, 4 skipped;
• just fix -p codex-windows-sandbox, just fmt, and git diff --check passed;
• independent adversarial review found no remaining code findings after one pipe-handle ordering correction.

The full fresh elevated end-to-end integration test was not completed because sandbox provisioning requested UAC and the attempt was cancelled with error 1223. Upstream Windows CI or a dedicated provisioned environment should cover that composed path.

Possibly related but not identical: #37919 (Box Drive through a junction).

Per docs/contributing.md, external PRs require an invitation. If this approach aligns with the intended solution, may I submit the tested branch as a PR?