Windows workspace-write sandbox launches PowerShell in a way that triggers profile access/language-mode errors; danger-full-access works

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #17019

Powered by Codex Action

Additional version-pinned, no-model app-server evidence

I reproduced the same PowerShell language-mode failure through the stable
app-server command/exec API. This test did not use a model turn, Codex thread,
experimental API, private Desktop IPC, rollout parsing, or UI observation.

Environment

• Codex CLI: 0.149.0
• Codex native binary SHA-256:

14b7e6b2356e82d1d9275579eaa588757b4e0a501b65dcc19fccdf77bd83dc00

• Version-generated stable schema: 291 files
• Schema bundle SHA-256:

0a400c60c044a11fe75cbd31478d2cb33e63892155296d0783b0a68889e8f9f9

• Guest executable: Windows PowerShell 5.1
• Invocation: absolute powershell.exe path with -NoProfile -File
• API: command/exec over stdio
• Sandbox policy: readOnly
• No custom outputBytesCap was supplied

PowerShell matrix

Four independent requests were intended to test:

1. argv, cwd, Unicode, stdout, and stderr;
2. an expected process exit code of 7;
3. a two-second timeout;
4. a write attempt under the read-only sandbox.

All four PowerShell processes started, but all four returned:

• exitCode: 1;
• empty stdout;
• stderr beginning with: `Cannot dot-source this command because it was

defined in a different language mode.`;

• elapsed time of approximately 338-354 ms.

The write target was absent.

Result: 0/4 intended PowerShell semantics reached their probe oracle.

Native control

The same command/exec API and readOnly sandbox were then tested with the
absolute current python.exe and direct argv tokens, again without a custom
output cap.

All four intended semantics passed:

• exact argv, cwd, Unicode, stdout, and stderr with exit 0;
• expected nonzero exit 7;
• timeout reported after approximately two seconds;
• read-only write denied and the target remained absent.

Result: native Python control 4/4 PASS.

This makes the failure specific to the tested Windows PowerShell execution
boundary rather than to command/exec transport or the read-only sandbox in
general.

Evidence integrity and limits

• PowerShell control result SHA-256:

49fff9c58c937b523d26d2e490da55835c50fba002a6a84f58b2b64ad3511138

• Native control result SHA-256:

5fc26edcd43693e32c58ea71b7d7ec40774e113e3e6f52e559c211a35e2ab997

• All exact temporary roots were removed after result-hash readback; no P5

temporary residue remained.

• This is controlled additional evidence, not a standalone copy-paste

reproducer: the request shape and result hashes were retained, but the
disposable probe script bytes were not retained.

Questions

1. Is Windows PowerShell 5.1 -File expected to be supported by

command/exec under the Windows readOnly or workspaceWrite sandbox?

1. If it is supported, what stable documented invocation avoids this

cross-language-mode failure?

1. If it is intentionally unsupported, could the supported Windows executable

boundary be documented explicitly?

Related historical report: #7777.

Same symptom here, plus a workaround that keeps the sandbox

On this machine the Windows sandbox cannot create a process when the executable is PowerShell.
cmd.exe in the same directory works. Since the sandbox wraps every command in the default shell
(pwsh), every command fails -- including git --version, which makes it look as if the tools
were missing rather than the shell being blocked.

Naming cmd.exe explicitly as the exec shell makes commands succeed with the sandbox still
enforced. That seems materially better than the two workarounds currently documented
(danger-full-access, which removes the sandbox, and switching to WSL2), so I am writing it up in
case it helps others hitting this.

All of the below was measured on 2026-08-26.

Environment

• codex-cli 0.150.0-alpha.8 (VS Code extension openai.chatgpt-26.820.60940-win32-x64)
• Windows 11 Pro 25H2, build 26200
• PowerShell 7.6.5 (Store) and Windows PowerShell 5.1.26100.9168 both present
• config.toml: [windows] sandbox = "unelevated"
• A commercial endpoint-security product is active on this machine (managed by the organisation).

Note that #26896 reports the same failure after removing its antivirus, so that is not by
itself the explanation.

• The account holds neither SeAssignPrimaryTokenPrivilege nor SeIncreaseQuotaPrivilege

(i.e. an ordinary user).

Error

Failed to create unified exec process: CreateProcessAsUserW failed: -1073283067
  | cwd=<redacted> | env_u16_len=6705 | si_flags=256 | creation_flags=525312

-1073283067 is 0xC0070005 -- facility 7 (Win32), code 5 (ERROR_ACCESS_DENIED).
An earlier build reported the same condition as plain 5.

What I ruled out (each measured, not inferred)

| Hypothesis | Result |
|---|---|
| A broken Store-app alias for pwsh | No -- it fails with the real C:\Program Files\WindowsApps\... path too |
| The working directory is unreachable under the restricted token | No -- identical failure with cwd set to a temp dir, C:\, and a user-profile dir |
| ACLs on the executable's directory | No -- cmd.exe and powershell.exe live in the same System32 and only one fails |
| The sandbox mode | Fails under both read-only and workspace-write; succeeds under danger-full-access |

The discriminating measurement

Asking the model to make three exec calls with the shell parameter set explicitly:

CMD=ok
POWERSHELL=exec_command failed: CreateProcessAsUserW failed: -1073283067
PWSH=exec_command failed: CreateProcessAsUserW failed: -1073283067

So what is blocked is the PowerShell executable under a modified token -- not the path, not
the working directory, and not the command.

Why this presents as "the tools are missing"

Because the sandbox routes commands through the default shell, a request to run git becomes:

"C:\Program Files\WindowsApps\Microsoft.PowerShell_...\pwsh.exe" -Command 'git --version'

...which fails on the shell's account. Every probe (git, rg, python, node, where)
returned the identical CreateProcessAsUserW error, and none of those binaries was ever launched.
With shell: "cmd.exe" the same git --version returns git version 2.54.0.windows.1.

The workaround, and what it preserves

With shell: "cmd.exe":

• git works
• reading a UTF-8 file containing Japanese via type comes back byte-identical (the console

code page is already 65001)

• the sandbox is still enforced: writes were refused both inside and outside the workspace,

and -- verified on the filesystem rather than by trusting the model's own report -- no file
appeared

• rg is simply not on PATH here (a not recognized message, not a denial)

Suggestion

This issue already suggests launching PowerShell with -NoProfile, or via a startup path that
avoids the profile/language-mode constraints. Independently of that, it would help a lot if the
exec shell were configurable (for example a [windows] exec_shell = "cmd.exe" key).

Today the model has to discover that PowerShell is blocked and retry with another shell, so
whether a given run succeeds depends on how persistently it retries. On an affected machine that
makes results non-deterministic: in one run the agent reached cmd.exe on its third attempt and
read the file it needed; in another it gave up after two attempts and reported that it could not
read anything -- while still exiting 0.