Windows Codex App: sandbox setup fails globally in clean C:\temp workspace

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

• #26186
• #25436
• #26619
• #26158
• #26416

Powered by Codex Action

i do not need assistance anymore. codex is now working as normal. i used a
different ai agent to fix the codex issue

here is what the ai agent said: "Fixed.

The error "invalid configuration: invalid transport in
'mcp_servers.director-bridge'" (on "Error starting chat") came from
~/.codex/config.toml.

Root cause
At the end of the file there was this:

[plugins."creative_production_mcp".mcp_servers."director-bridge"]
enabled = false

[mcp_servers."director-bridge"]
enabled = false # ← this is the problem

A top-level [mcp_servers."xxx"] entry requires a transport:
• command + args (stdio, the common case), or
• url (HTTP/SSE / streamable HTTP).

Just enabled = false (with no transport) is invalid and the Codex desktop
app rejects the whole config when starting a chat/session.
"director-bridge" appears to be an internal bridge (tied to the
creative-production curated plugin or Codex's internal director/agent
wiring).

(The namespaced
[plugins."creative_production_mcp".mcp_servers."director-bridge"] entry is
fine — that's how Codex tracks per-plugin MCP enablement.)

What I did
Removed only the invalid bare [mcp_servers."director-bridge"] block from
C:\Users\danie\.codex\config.toml.

The file now ends cleanly with the (harmless) plugin override entry.

Next step

1. Fully restart the Codex desktop app (quit completely, not just close a

window).

1. Try starting a new chat.

It should work now.

───

If the error returns on the next launch (the app might try to
re-materialize the entry from plugin state / global state), let me know and
we can:
• Add a dummy valid-but-disabled transport, or
• Disable the creative_production_mcp plugin entirely, or
• Clean related entries from ~/.codex/.codex-global-state.json (more
aggressive).

Let me know what happens after the restart!"

On Fri, Jun 5, 2026 at 9:28 PM github-actions[bot] @.***>
wrote:

github-actions[bot] left a comment (openai/codex#26737) <https://github.com/openai/codex/issues/26737#issuecomment-4637371756> Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #26186 <https://github.com/openai/codex/issues/26186> - #25436 <https://github.com/openai/codex/issues/25436> - #26619 <https://github.com/openai/codex/issues/26619> - #26158 <https://github.com/openai/codex/issues/26158> - #26416 <https://github.com/openai/codex/issues/26416> Powered by Codex Action <https://github.com/openai/codex-action> — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/26737?email_source=notifications&email_token=B7RR2YRHP5MZMF2A2XMQWQL46OMVXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTG4ZTOMJXGU3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4637371756>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7RR2YS3YHRARP6B7SESHB346OMVXAVCNFSM6AAAAACZ4Y75COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMZXGM3TCNZVGY> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B7RR2YQWHVZHMQ4D2PDUO2T46OMVXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTG4ZTOMJXGU3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/B7RR2YURWA463OE4ULMXRK346OMVXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRTG4ZTOMJXGU3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

Same symptom on another machine — adding A/B isolation results and .sandbox evidence in case it helps narrow this down.

Summary

With [windows] sandbox = "elevated", every command fails with windows sandbox: runner error: CreateProcessAsUserW failed: 5. Switching to [windows] sandbox = "unelevated" allows the same non-elevated commands to run. Re-enabling elevated mode and restarting the app does not show a setup screen or UAC prompt, so the elevated sandbox setup path appears stuck after failure.

Environment

• OS: Windows 11 Pro 25H2, OS build 26200.8655 (note: the registry ProductName still reads "Windows 10 Pro", which is a known Windows 11 quirk)
• Install type: MSIX/Store package. The app resides under C:\Program Files\WindowsApps (OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0). Get-AppxPackage reports OpenAI.Codex 26.608.1337.0, matching the package name in the failing ACE path.
• App/version evidence is mixed in this environment:
• Settings screen previously showed 26.601.10930.
• Live config contains BROWSER_USE_CODEX_APP_VERSION = "26.608.12217".
• .sandbox logs reference package OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0.
• Codex home is configured at a non-default location. .sandbox state exists both under the custom Codex home and under the default C:\Users\<user>\.codex; setup_error.json was present only in the default location.
• Related issues: #26803, #10090, #9062.

A/B result

1. Set [windows] sandbox = "unelevated".
2. Restart Codex App.
3. Run lightweight read-only commands such as Get-Location and git status --short --branch.
4. Commands succeed without an elevation prompt.
5. Set [windows] sandbox = "elevated".
6. Restart Codex App.
7. Run the same class of command.
8. Command execution fails with windows sandbox: runner error: CreateProcessAsUserW failed: 5.
9. In elevated mode, every command fails at process creation, regardless of working directory (workspaces on both C: and D: are affected).

Expected behavior

Elevated sandbox setup should either complete and allow command execution, or the app should present a clear setup/UAC recovery path when setup state is missing or failed.

Actual behavior

After elevated setup failure, command execution fails with CreateProcessAsUserW failed: 5. Re-enabling elevated sandbox and restarting does not show a setup screen or UAC prompt, so there is no obvious way to repair the elevated sandbox state from the app.

.sandbox evidence

grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0\app for sandbox_group: SetNamedSecurityInfoW failed: 5
read ACL run completed with errors: ["grant read ACE failed on C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0\\app for sandbox_group: SetNamedSecurityInfoW failed: 5"]
setup error: read ACL run had errors

C:\Users\<user>\.codex\.sandbox\setup_error.json contained:

{
  "code": "helper_unknown_error",
  "message": "setup refresh had errors"
}

Root-cause hypothesis

The failing ACE target is under C:\Program Files\WindowsApps. Windows blocks ACL modification inside WindowsApps by design (owned by SYSTEM/TrustedInstaller), even for elevated administrators. If elevated sandbox setup needs to grant the custom sandbox group a read ACE on the package install directory, that step cannot succeed on MSIX/Store installs. The sandbox user would then be unable to read the runner binaries, which matches the runtime CreateProcessAsUserW failed: 5. This is an inference from the log lines above, not verified against source.

Notes

• sandbox_private_desktop = false was tried and did not change the result (it has since been removed from config).
• This report intentionally omits local repository paths, raw logs, tokens, and chat content.

Closing as resolved.

Adding another resolved Windows case with the same sandbox setup symptom, in case it helps future diagnostics or users who find this issue.

Symptoms

Codex Desktop App on Windows could not start chats or load plugins. The app showed sandbox setup failures including:

• Couldn't set up Agent sandbox with Admin permissions
• Couldn't set up non-admin sandbox

Root cause in this case

The Windows virtualization/sandbox prerequisites were not enabled or installed:

• Hyper-V was disabled
• Windows Sandbox / Containers-DisposableClientVM was disabled
• Virtual Machine Platform was disabled
• WSL2 was not installed
• No Linux distro was installed

Fix applied

Enabled the required Windows features from an Administrator PowerShell session:

• Microsoft-Hyper-V-All
• Containers-DisposableClientVM
• VirtualMachinePlatform
• Microsoft-Windows-Subsystem-Linux

Then installed Ubuntu:

wsl --install -d Ubuntu

After rebooting Windows, created/updated %USERPROFILE%\.codex\config.toml with:

[windows]
sandbox = "unelevated"
sandbox_private_desktop = false

Then fully quit and reopened Codex Desktop App. After that, chats started normally and plugins loaded again.

System

• Windows 11 Pro
• Build 26200
• VirtualizationBasedSecurity = 2 / VBS enabled

This was a separate user machine from the earlier comments. The main takeaway is that the app's generic sandbox setup errors may also be caused by missing Windows optional features / WSL2 setup, not only Codex config corruption or elevated ACL setup failure.

One additional note from the affected user: this took about an hour of assisted debugging and consumed paid Codex/ChatGPT usage before the actual prerequisite issue was identified.

The app surfaced only generic sandbox setup errors:

• Couldn't set up Agent sandbox with Admin permissions
• Couldn't set up non-admin sandbox

In this case, the actionable fix was to enable/install the missing Windows prerequisites: Hyper-V, Windows Sandbox / Containers-DisposableClientVM, Virtual Machine Platform, WSL2, and an Ubuntu distro, then restart and use the unelevated sandbox config.

It would be helpful if the app's setup diagnostics could explicitly detect and report missing Windows features/WSL prerequisites before users spend paid usage debugging a generic sandbox failure. If there is an appropriate support/credit path for users who spent significant paid usage on this unclear setup failure, please consider this case as well.