Hi guys,
I noticed recently the Codex cli on windows on start when there is an update now it has a menu of three items one of them is run the update.
Previously it was displaying a message with the exact command to run the update. Now that message is gone.
When you select the first item to run the update, the update fails because codex is running it from its own sandbox and hits the permission wall. While trying to update it displays the command to run.
Basically you need to close the terminal open a new session run that command to update…
Ideally I would love to have the exact command displayed above the list of three items so that I can copy it from there update codex and restart.
Thanks for the update. I use Codex on Windows as well, which makes us part of a fairly rare group.
I haven’t upgraded my version yet today, and since I use the VS Code extension, I’ll keep an eye out for any errors.
I also checked the Codex issues page , and some of the recently reported problems appear to be related to Windows updates, so I’ll be keeping those in mind as well.
Does this issue appear to be the same?
opened 12:49AM - 20 May 26 UTC
bug
windows-os
sandbox
app
# Codex Windows sandbox setup refresh failure on v0.131.0
Date: 2026-05-20
## … Summary
After updating to OpenAI Codex v0.131.0 on Windows, all non-escalated shell commands failed before the command process started.
The failure message was:
```text
windows sandbox: setup refresh failed with status exit code: 1
```
The issue was reproduced both in an existing workspace and in a newly created empty workspace. The same command succeeded when explicitly approved to run outside the sandbox.
After changing Windows sandbox-related settings and fully restarting Codex, the original pre-execution failure was no longer reproduced. Non-escalated shell commands now run, but PowerShell still emits a language mode-related `InvalidOperation` message before command output.
Current status: mitigated, with a remaining warning.
## Environment
- Codex version: OpenAI Codex v0.131.0
- Model: gpt-5.5
- Platform: Windows
- Windows version: 25H2 (OS Build 26200.8457)
- Shell: PowerShell
- PowerShell version: 7.6.0
- Sandbox mode: workspace-write
- Main workspace: `C:\Users\taku_\Documents\radiology-ops`
- Main workspace shown by Codex: `~\Documents\radiology-ops`
- Empty test workspace: `~\Documents\codex-sandbox-test`
## Impact
The failure blocked ordinary local repository inspection and normal workflow execution. In the affected workspace, Codex could not safely run even simple read-only commands needed to inspect local workflow files such as:
- `tools/prompts/daily-schedule-workflow.md`
- `DAILY.md`
- `00_context/local/calendar_ids.json`
Because the failure occurred during sandbox setup or refresh, it was not specific to a particular command, file path, or repository.
## Original Reproduction
In Codex on Windows, run a simple non-escalated shell command:
```powershell
$PSVersionTable.PSVersion
```
Observed result:
```text
execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })
```
The same error occurred with:
- `workdir` set to `C:\Users\taku_\Documents\radiology-ops`
- no explicit `workdir`
- `workdir` set to `C:\Users\taku_\.codex\memories`
- a new empty workspace at `~\Documents\codex-sandbox-test`
In the new empty workspace, the same command succeeded when the user explicitly approved running it outside the sandbox:
```text
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 6 0
```
## Expected Behavior
Simple read-only shell commands should execute normally inside the workspace sandbox. If a command fails, the failure should come from the command itself, not from Windows sandbox setup before execution.
## Original Observed Behavior
The command did not appear to start. The failure happened during Windows sandbox setup or refresh, before PowerShell command execution.
## Things Tried Before Mitigation
- Restarted the Codex app completely.
- Retried the same simple command after restart.
- Tried the command with different working directory settings.
- Confirmed the error was not specific to `Get-Content`, `daily-schedule-workflow.md`, `DAILY.md`, or the repository path.
- Confirmed the same error occurred in a new empty workspace.
- Confirmed the same command succeeded outside the sandbox after explicit user approval.
## Mitigation Attempted
The likely mitigation was changing Windows sandbox-related settings and then fully restarting Codex.
The candidate setting change was:
```toml
[windows]
sandbox = "unelevated"
```
or the equivalent UI setting:
- Elevated Windows sandbox: off
- Windows sandbox: unelevated
The exact before and after values were not captured in the final pasted result, so the mitigation cannot yet be attributed definitively to one specific setting. The timing strongly suggests that the Windows sandbox setting change plus full Codex restart resolved or bypassed the setup refresh failure.
Broad PowerShell allow rules and disabling the sandbox permanently were intentionally avoided.
## Post-Restart Result
User-provided result after the setting change and full Codex restart:
```text
Command: $PSVersionTable.PSVersion
Result: command completed and printed PowerShell version 7.6.0
Additional stderr/stdout:
InvalidOperation: Cannot set property. Property setting is supported only on core types in this language mode.
```
Codex also verified the same minimal read-only command in the `radiology-ops` workspace:
```text
Workspace: C:\Users\taku_\Documents\radiology-ops
Command: $PSVersionTable.PSVersion
Exit code: 0
Output:
InvalidOperation: Cannot set property. Property setting is supported only on core types in this language mode.
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 6 0
```
## Current Interpretation
The original blocker appears to be mitigated:
- The previous error, `windows sandbox: setup refresh failed with status exit code: 1`, no longer appears in the tested session.
- The non-escalated command now starts and exits successfully inside the sandbox.
- The command output is available.
A separate warning remains:
```text
InvalidOperation: Cannot set property. Property setting is supported only on core types in this language mode.
```
This appears to be a different symptom from the original sandbox setup/refresh failure. It may be related to PowerShell language mode or shell initialization inside the sandbox. For the minimal command tested here, it did not prevent execution or output collection.
## Related Public Issues
Related issues already checked during triage:
- https://github.com/openai/codex/issues/15809
- https://github.com/openai/codex/issues/10090
- https://github.com/openai/codex/issues/9062
- https://github.com/openai/codex/issues/14409
No confirmed official fix was identified during the prior investigation. Similar reports suggested trying the unelevated Windows sandbox setting, re-running sandbox onboarding, or rolling back/reinstalling if the problem persists.
## Recommended Next Steps
For local operation:
- Continue using the least-permissive Windows sandbox setting that allows non-escalated shell commands to run.
- Do not use broad PowerShell allow rules.
- Do not permanently disable the sandbox unless there is no other temporary workaround.
- Treat the remaining PowerShell language mode warning as a separate, lower-priority issue unless it starts breaking real commands.
If reporting upstream:
- Include the original failure message.
- Include both workspaces where the issue reproduced.
- Include that outside-sandbox approved execution succeeded.
- Include the post-restart mitigation result and the remaining language mode warning.
- Add exact Windows sandbox setting values before and after if they can be recovered from UI history or user notes.
If the setup refresh failure returns:
1. Try Windows sandbox re-onboarding.
2. If that fails, consider rollback or reinstall.
3. If still reproducible, file or update an official GitHub issue with this report.
Well it might be both related to the Sandbox permissions I’m running it in auto-approve mode.
For me it was more the UI question as codex have removed the exact command to update replacing it by a list of items where the first one is supposed to replace the command and does not work out of the box…
Then yes we already had a discussion about sandbox permissions so I’m trying to figure that out. What I see often is that when codex spawns us up process that sub-process is mostly failing on the first run.
I updated VS Code, the Codex extension, and the Claude Code extension without any problems.
That said, I only update when I’m about to start a new session or chat, with nothing running in the background, so that may have helped avoid the issue.
@sergeliatko are you using it within WSL?
have you tried a quick: npm install -g @openai/codex?
They may be working on this and may have fixed it.
committed 05:30PM - 20 May 26 UTC
## Why
The Windows sandbox migration away from the legacy `SandboxPolicy`
abstr… action needs a small local bridge before IPC and core wiring can
move to `PermissionProfile`. Leaf helpers currently branch directly on
`WorkspaceWrite`, which spreads legacy assumptions through path planning
and token setup code.
This PR introduces a Windows-local resolved permissions view so those
helpers can ask Windows-specific questions about runtime
filesystem/network permissions without matching on the legacy policy
enum everywhere.
## What changed
- Added `ResolvedWindowsSandboxPermissions` in
`windows-sandbox-rs/src/resolved_permissions.rs`, with legacy
`SandboxPolicy` constructors for the current call sites.
- Moved `allow.rs` writable-root and read-only-subpath planning onto the
resolved permissions type.
- Preserved Windows `TEMP`/`TMP` writable-root behavior when the
effective policy includes writable tmpdir access.
- Avoided resolving Unix `:slash_tmp` or parent-process `TMPDIR` while
computing Windows writable roots.
- Reused the shared allow-path result for setup write-root gathering and
routed network-block selection through the resolved abstraction.
## Verification
- `cargo test -p codex-windows-sandbox`
- `just fix -p codex-windows-sandbox`
- GitHub CI restarted on the amended commit; Windows Bazel is the
required signal for the Windows-only code paths.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22896).
* #23715
* #23714
* #23167
* #22923
* #22918
* __->__ #22896
no, inside PHPStorm that runs in in poweshell
npm install -g @openai /codex
Yes, that’s the only way to make it work, the post was more about the logic: let’s hide the convenient command display behind “automated” option that does not work…
Ah ok. The automated system appears to work reliably inside Ubuntu WSL