[FIX Request] Codex Windows sandbox networking fails due to ACL error

Resolved 💬 3 comments Opened Apr 21, 2026 by mickitty0511 Closed Apr 21, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.417.5275.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On my Windows machine, Codex Desktop cannot use networked child-process commands inside the sandbox even though network_access = true is enabled.

Manual PowerShell outside Codex works normally:

  • nslookup registry.npmjs.org succeeds
  • node DNS lookup succeeds

But commands launched through Codex fail consistently:

  • nslookup registry.npmjs.org -> No response from server
  • node dns.lookup('registry.npmjs.org') -> EAI_FAIL
  • direct TCP connect to 104.16.0.34:443 -> UNKNOWN:connect UNKNOWN ...

The direct root cause appears to be that the Windows sandbox setup helper cannot grant a read ACE on the installed app resources directory under C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources.

I found the following persistent local state:

  • ~/.codex/.sandbox/setup_error.json contains:
  • {"code":"helper_unknown_error","message":"read ACL run had errors"}
  • ~/.codex/.sandbox/sandbox.log repeatedly shows:
  • grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.417.5275.0_x64__2p2nqsd0c76g0\app\resources for sandbox_group: SetNamedSecurityInfoW failed: 5

I also confirmed that the command-runner request payload still contains network_access:true, so this does not look like a config propagation problem.

Why I believe this is a Codex desktop bug

I tried all of the following and the exact same ACL failure still reproduces:

  • app restart
  • sign out / sign in
  • Windows Firewall rule review
  • Codex Repair
  • deleting / regenerating ~/.codex/.sandbox, .sandbox-bin, .sandbox-secrets
  • Windows reboot
  • reinstall on a newer package version

After reinstall, the package version changed, but the same SetNamedSecurityInfoW failed: 5 error still occurred on the new WindowsApps\...\app\resources path.

So at this point the failure seems to be in the Windows desktop sandbox helper / ACL setup path itself, not in my network_access setting.

Impact

This breaks common networked commands from Codex Desktop on Windows, for example:

  • npm install
  • DNS lookups from node
  • direct outbound TCP from child processes (pip and others)

As a practical workaround, I can run those commands in normal PowerShell outside Codex, but the more workloads we have, the more burdens we are causing to maintain codex-backed development.

Evidence

Representative local evidence:

  • ~/.codex/.sandbox/setup_error.json setup_error.json
  • ~/.codex/.sandbox/sandbox.log with the logs attached below
  • Codex child-process failures:
  • EAI_FAIL:getaddrinfo EAI_FAIL registry.npmjs.org
  • UNKNOWN:connect UNKNOWN 104.16.0.34:443 - Local (undefined:undefined)
  • manual PowerShell on the same machine succeeds for the equivalent DNS checks
[2026-04-21 17:03:18.874 codex.exe] helper launch resolution: using copied command-runner path <USER_HOME>\.codex\.sandbox-bin\codex-command-runner.exe
[2026-04-21T08:03:18.874577500+00:00] granting read ACE to C:\Program Files\WindowsApps\OpenAI.Codex_26.417.5275.0_x64__2p2nqsd0c76g0\app\resources for sandbox users
[2026-04-21 17:03:18.874 codex.exe] runner launch: exe=<USER_HOME>\.codex\.sandbox-bin\codex-command-runner.exe cmdline=<USER_HOME>\.codex\.sandbox-bin\codex-command-runner.exe --pipe-in=\\.\pipe\codex-runner-5809c2ef6472c17b42fd7b5971d1c1cf-in --pipe-out=\\.\pipe\codex-runner-f71e23823f15274712e437030b7b046-out cwd=<WORKSPACE>
[2026-04-21T08:03:18.874678500+00:00] grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.417.5275.0_x64__2p2nqsd0c76g0\app\resources for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-04-21T08:03:18.879815800+00:00] read ACL run completed with errors: ["grant read ACE failed on C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.417.5275.0_x64__2p2nqsd0c76g0\\app\\resources for sandbox_group: SetNamedSecurityInfoW failed: 5"]
[2026-04-21T08:03:18.879837500+00:00] setup error: read ACL run had errors
[2026-04-21 17:03:18.879 codex-windows-sandbox-setup.exe] setup error: read ACL run had errors

What steps can reproduce the bug?

  1. Install Codex Desktop on Windows.
  2. Enable network_access = true in user config.
  3. Launch a networked command through Codex Desktop sandbox / shell tool.
  4. Observe that Codex child-process networking fails.
  5. Check ~/.codex/.sandbox/setup_error.json and ~/.codex/.sandbox/sandbox.log.
  6. Observe repeated SetNamedSecurityInfoW failed: 5 on ...\app\resources.

What is the expected behavior?

If network_access = true is enabled and the machine itself has working DNS/networking, Codex Desktop child processes should be able to perform outbound networking normally.

Additional information

Suggested labels:

  • bug
  • sandbox
  • windows-os

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17901
  • #17612
  • #18675

Powered by Codex Action

mickitty0511 · 4 months ago

#17921, #18675 are the same issues as mine, so will close it

leeseungwoo0817-design · 1 month ago

I am experiencing the same Windows sandbox helper failure in the Codex desktop app, but the suggested unelevated workaround does not resolve it in my environment.

Environment:

  • Codex Desktop: 26.715.4045.0
  • Codex CLI: 0.145.0-alpha.18
  • Platform: Windows
  • Repository: local Windows repository
  • Permission mode: Workspace (Ask for approval)

Observed behavior:

  • Codex can read app.js successfully.
  • The file is valid UTF-8 and Git reports it as unchanged.
  • Any apply_patch operation fails before modifying the file.
  • The reported error is:

fs sandbox helper failed
helper_unknown_error
setup refresh had errors

Troubleshooting already performed:

  1. Fully restarted Codex Desktop.
  2. Created a new task.
  3. Reconnected the actual repository as the workspace.
  4. Tested a separate repository copy outside OneDrive.
  5. Confirmed that file reading works.
  6. Started Codex CLI with:

codex -c 'windows.sandbox="unelevated"' --sandbox workspace-write

  1. Confirmed in /status that the correct repository directory and Workspace permission mode were active.
  2. Retried a minimal no-content-change apply_patch operation.

Result:

  • apply_patch still failed.
  • No source files were modified.
  • The repository and application data remain intact.

Expected behavior:
Codex should be able to apply patches to files inside the selected writable workspace, or return an actionable error identifying the path or ACL that prevents the operation.

The unelevated workaround reported in related issues does not work for this Codex Desktop/CLI version combination. Please let me know which sandbox logs or diagnostic files would be useful for further investigation.