codex exec --sandbox workspace-write is effectively read-only on native Windows

Summary

On native Windows, a direct host-side codex exec --sandbox workspace-write run starts normally and exits with code 0, but model-generated writes inside the selected working directory are rejected as read-only. A lower-level workspace sandbox probe can write inside the same kind of isolated workspace and still blocks writes outside it.

Environment

• Codex CLI: 0.145.0-alpha.18
• Codex executable SHA-256: 20d611ef1c9851f4da1cb4609beb6763904f72275cb91517b2400639ca1c28c4
• OS: Windows NT 10.0.26200.0, x64
• Launch topology: direct host process; no command-runner or codex sandbox parent
• Parent sandbox depth: 0
• Requested sandbox: workspace-write
• Approval policy: never
• Network access: disabled
• User config and exec rules: ignored

Minimal reproduction

Run the sanitized PowerShell script from the supporting package:

.\GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_REPRODUCTION_FINAL.ps1 -CodexExe <path-to-codex.exe>

The script creates an isolated temporary working directory, writes a harmless INPUT.txt, invokes direct codex exec --sandbox workspace-write, and checks for RESULT.txt.

Equivalent core invocation:

codex.exe -a never exec --ignore-user-config --ignore-rules --strict-config `
  -c 'sandbox_workspace_write.network_access=false' `
  -c 'web_search="disabled"' --sandbox workspace-write `
  -C <TEMP_WORKSPACE> --skip-git-repo-check --ephemeral --json `
  --output-schema <SCHEMA_JSON> --output-last-message <FINAL_JSON> `
  'Read INPUT.txt. Create RESULT.txt with exactly WORKSPACE_WRITE_OK followed by one newline. Return {"status":"PASS"}.'

Expected behavior

RESULT.txt is created inside the selected working directory. Writes outside that directory remain blocked.

Actual behavior

• The session starts and reads INPUT.txt.
• The write tool reports that writing is blocked by a read-only sandbox.
• The process exits with code 0.
• Structured final output is produced.
• RESULT.txt is absent.

Evidence and scope

Observed:

• --sandbox workspace-write is present in the direct process arguments.
• The process is launched host-side with no enclosing sandbox.
• Inherited Codex permission-profile variables were removed.
• The isolated working directory is readable.
• The requested in-workspace write is rejected as read-only.
• A lower-level workspace sandbox comparison permits an in-workspace write and blocks an out-of-workspace write.

Inference:

• The effective permission diverges from the requested permission after CLI argument construction and before tool execution.

Not proven:

• Whether managed requirements or permission-profile resolution override the explicit CLI sandbox request.

Impact

Workspace-limited autonomous execution cannot complete even though the requested security boundary should permit only working-directory writes. Unsafe alternatives such as full-access bypass, elevated execution, credential replication, or undocumented launch paths are not acceptable workarounds.

Related but distinct

• #33322 reports a Desktop model switch changing an existing task from workspace-write to read-only.
• This report reproduces the mismatch through direct native-Windows codex exec, without a model switch or an enclosing Desktop task sandbox.

Request

Please confirm the supported native-Windows configuration for direct codex exec with workspace-only writes, or fix the execution path so the explicit --sandbox workspace-write request is honored. Guidance for a secret-safe isolated authenticated CODEX_HOME would also help.