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

What version of the Codex App are you using (From “About Codex” dialog)?

26.325.31654

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On Windows, Codex fails in sandbox_mode = "workspace-write" because commands appear to be launched through a PowerShell path that triggers profile loading / constrained-language-style startup errors.

The same setup works with:

sandbox_mode = "danger-full-access"
allow_login_shell = false

So this looks specific to the Windows sandboxed execution path, not to my PowerShell profile itself.

Environment

• OS: Windows
• Codex: latest available at the time of filing
• Shell involved: PowerShell
• Config variations tested:

• sandbox_mode = "workspace-write" -> fails
• sandbox_mode = "danger-full-access" -> works
• allow_login_shell = false helps in the non-sandboxed/full-access path, but does not fully prevent the error in workspace-write

Symptoms

With sandbox_mode = "workspace-write", commands fail with errors like:

.: Access to the path 'C:\Users\nick\Documents\PowerShell\Microsoft.PowerShell_profile.ps1' is denied.

Earlier variants of the same failure also included PowerShell language mode errors such as:

Cannot dot-source this command because it was defined in a different language mode.
Cannot set property. Property setting is supported only on core types in this language mode.

What I tested

1. My PowerShell profile itself is not the root cause

I removed my user profile file entirely, and the same startup/language-mode style errors still occurred in the failing path.

So this does not seem to be caused by the contents of:

C:\Users\nick\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

2. Changing the terminal UI setting was not sufficient

Even when selecting other terminal types, Codex still appeared to execute through PowerShell on the actual command path, and the same problem remained.

3. danger-full-access works, workspace-write fails

This is the most reproducible distinction:

• danger-full-access + allow_login_shell = false -> works
• workspace-write -> PowerShell profile access error returns

4. allow_login_shell = false partially helps

This appears to avoid the issue in the full-access path, likely because PowerShell is started without loading the normal profile path there.

However, in workspace-write, the sandboxed path still seems to hit a PowerShell startup/profile-loading behavior that causes failure.

Request

Could you investigate whether the Windows workspace-write sandbox path is launching PowerShell differently from the danger-full-access path, especially around:

• profile loading
• -NoProfile
• PowerShell language mode / constrained language behavior
• any startup wrapper or injected script used only in the sandboxed path

This looks like a Windows sandbox integration bug rather than a user profile configuration problem.

What steps can reproduce the bug?

Repro config

A minimal failing config is roughly:

sandbox_mode = "workspace-write"
allow_login_shell = false

A working config is roughly:

sandbox_mode = "danger-full-access"
allow_login_shell = false

What is the expected behavior?

Expected behavior

On Windows, workspace-write should not fail merely because PowerShell has a profile path in the user Documents directory.

Ideally, the sandboxed Windows execution path should do one of the following:

1. launch PowerShell with -NoProfile, or
2. avoid touching the user profile path entirely, or
3. use a startup path that does not trip language-mode / profile-access behavior inside the sandbox

Actual behavior

workspace-write fails before normal command execution with PowerShell startup/profile errors, while danger-full-access works.

Additional information

_No response_