Windows: codex exec --sandbox workspace-write remains read-only

What issue are you seeing?

Summary

On Windows, codex exec --sandbox workspace-write starts successfully and exits with code 0, but the effective sandbox remains read-only.

The command is launched directly from the host process. There is no external codex sandbox wrapper, no command-runner parent, and the parent sandbox depth is zero.

Despite requesting workspace-write, Codex cannot create the expected file inside the working directory.

Environment

• Operating system: Windows
• Product: OpenAI Codex CLI
• Execution mode: codex exec
• Requested sandbox: workspace-write
• Effective sandbox: read-only
• Parent sandbox depth: 0
• External sandbox parent: none
• Command runner parent: none
• Network access: disabled
• Approval escalation: disabled

I can provide the exact Codex version, executable checksum and Windows build from the sanitized diagnostic package.

Minimal reproduction

Run Codex from a normal host-side process, using a temporary working directory containing an input file.

Example command:

codex exec --json --sandbox workspace-write --output-schema "<SANITIZED_SCHEMA_PATH>"

The prompt asks Codex to create a simple file named OUTPUT.txt in the current working directory.

Expected behavior

Because --sandbox workspace-write is requested and the current working directory is the authorized workspace, Codex should be able to create:

OUTPUT.txt

inside that directory.

Writes outside the authorized workspace should remain blocked.

Actual behavior

• Codex starts successfully.
• The execution exits with code 0.
• Structured execution events are produced.
• The effective inner sandbox behaves as read-only.
• OUTPUT.txt is not created.
• The final workspace validation therefore fails.

Diagnostics already performed

We verified the following:

• direct host-side execution;
• parent sandbox depth is zero;
• no codex sandbox parent;
• no command-runner parent;
• isolated working directory;
• sanitized CODEX_* environment variables;
• isolated configuration and rules;
• explicit --sandbox workspace-write;
• workspace path and current working directory alignment;
• executable path and checksum validation;
• process-tree validation;
• filesystem snapshots before and after execution;
• side-effect scanning;
• write capability from the host launch point;
• no retry or fallback.

A separate non-AI write gate using the same host-side environment can successfully write inside the workspace. The read-only behavior appears when codex exec applies its effective inner sandbox.

Observed facts

1. workspace-write is passed explicitly to codex exec.
2. The command is launched directly from a host process.
3. Parent sandbox depth is zero.
4. Codex exits with code 0.
5. The expected workspace file is not created.
6. Filesystem evidence shows that the Codex execution had effective read-only behavior.

Inference

The sandbox mode used internally by codex exec on Windows may not be applying or propagating the requested workspace-write policy correctly.

This is an inference based on the observed behavior, not a confirmed OpenAI diagnosis.

Security impact

Using an unrestricted sandbox is not an acceptable workaround.

The required behavior is:

• write access only inside the designated workspace;
• no write access outside it;
• no network access;
• no approval escalation.

Workarounds attempted

• direct host-side execution;
• removal of nested sandbox wrappers;
• sanitized Codex environment;
• isolated configuration;
• isolated rules;
• isolated working directory;
• explicit sandbox argument;
• pre-launch write validation;
• process-tree validation.

These did not change the effective read-only behavior inside codex exec.

We did not use unrestricted filesystem access or copy authentication credentials into an unsupported environment.

Questions

1. Is this a known limitation or bug in Codex CLI on Windows?
2. Is codex exec --sandbox workspace-write expected to support creating files in its working directory on Windows?
3. Is there an officially supported configuration required to make the workspace writable?
4. Is an isolated and authenticated CODEX_HOME supported without copying credential material?
5. Are there additional diagnostic logs or flags that would help identify the effective sandbox policy?

Additional evidence

I have a sanitized reproduction package containing:

• a minimal PowerShell reproduction script;
• Codex version and executable checksum;
• sanitized process tree;
• requested-versus-effective sandbox evidence;
• sanitized environment details;
• filesystem diff;
• attempted-workaround matrix.

I can attach or paste the relevant sanitized files if requested.

GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_SUBMISSION_RESULT.json
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_ATTACHMENT_MANIFEST.json
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_CHANNEL_VALIDATION.json
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_ISSUE_FINAL.md
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_MANUAL_SUBMISSION_INSTRUCTIONS.md
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_SANITIZATION_REPORT.json
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_SUBMISSION_DECISION.json
GP_AUTONOMOUS_COMMANDER_STEP2_UPSTREAM_SUBMISSION_REPORT.md

What steps can reproduce the bug?

1. On Windows, create a new empty temporary folder, for example:

mkdir C:\Temp\codex-workspace-test
cd C:\Temp\codex-workspace-test

1. Create a simple prompt or input asking Codex to create a file named OUTPUT.txt in the current working directory.

1. Run Codex directly from the host process with no external sandbox wrapper and no command runner parent:

codex exec --json --sandbox workspace-write "Create a file named OUTPUT.txt in the current working directory containing the text: workspace write test"

1. Wait for the command to complete.

1. Check the exit code and verify whether the file exists:

$LASTEXITCODE
Test-Path .\OUTPUT.txt

1. The command exits successfully with exit code 0, but Test-Path returns False because OUTPUT.txt is not created.

1. Repeating the test with direct host-side execution, parent sandbox depth 0, sanitized CODEX_* environment variables, isolated configuration, and the working directory set to the authorized workspace produces the same result.

Expected result: OUTPUT.txt is created inside the current workspace, while writes outside the workspace remain blocked.

Actual result: the effective sandbox behaves as read-only even though --sandbox workspace-write was explicitly requested.

What is the expected behavior?

codex exec --sandbox workspace-write should allow Codex to create and modify files inside the current authorized workspace.

In this test, Codex should create:

OUTPUT.txt

in the current working directory with the requested content.

Writes outside the authorized workspace should remain blocked, network access should remain disabled, and no approval escalation should be required.

The command should therefore complete with exit code 0 and Test-Path .\OUTPUT.txt should return True.

Additional information

_No response_