Elevated Windows sandbox intermittently fails setup refresh with SetNamedSecurityInfoW ERROR_ACCESS_DENIED (5)

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

0.154.0

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

In Codex App for Windows, creating commands consistently fails when the workspace is opened from a location on the C: drive. The same commands work when the workspace is opened from D:\\downloading\\sub2.

The failure happens before PowerShell is created. The app reports:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

Minimal reproduction

1. Use Codex App for Windows.

2. Configure the Windows sandbox as:

   [windows]
   sandbox = "elevated"
   

3. Open a workspace from a C: drive location.

4. Request a minimal command, such as whoami.

5. The command fails before PowerShell starts and reports setup refresh had errors.

6. Control case: open a workspace from D:\\downloading\\sub2 and run the same command successfully.

Actual result

The main sandbox diagnostic log records this failure chain:

write ACE grant failed on <REDACTED_USER_PROFILE_PATH>
SetNamedSecurityInfoW failed: 5
setup refresh completed with errors

Win32 error 5 is Access is denied.

Log correlation:

Working-directory category	setup refresh attempts	Success	Failure	Write-root count
C: drive location	43	0	43	111–116
Other drive location	47	47	0	2

All 43 failures target the same direct child of the user profile. The directory name is redacted; it is neither AppData nor .codex. That target path no longer exists, so its historical ACL cannot be inspected now.

The same target appears in failed records from at least 13 retained daily sandbox logs, from 2026-08-25 through 2026-09-11. This is not a one-off failure.

Environment

• Product: Codex App for Windows
• Codex version: 0.154.0 (from local CODEX_HOME/version.json)
• Windows: Windows 10 Home China, version 25H2
• OS build: 26200.9445
• Sandbox mode: elevated
• User-profile owner: NT AUTHORITY\\SYSTEM
• User-profile DACL: protected
• CODEX_HOME/.sandbox/deny_read_acl_state.json: present, valid JSON, 22 bytes, zero NUL bytes

Expected result

Opening a workspace from a C: drive location should start sandboxed commands normally, just as it does when the workspace is opened from D:\\downloading\\sub2.

If the elevated sandbox cannot grant an ACE to a write root, the app should identify the blocked directory and operation instead of returning only the generic setup refresh had errors before the requested shell process starts.

Attachments

• Redacted codex-sandbox-2026-09-11-redacted.log
  codex-sandbox-2026-09-11-redacted.log

What steps can reproduce the bug?

Steps to reproduce

1. Use Codex App for Windows with:

   [windows]
   sandbox = "elevated"
   
   

2. Open a workspace from a location on the C: drive.

3. Ask Codex to run this minimal command:

   whoami

4. The command fails before PowerShell starts:

   Failed to create unified exec process:
   helper_unknown_error: setup refresh had errors

5. Open a workspace from D:\downloading\sub2 and run the same command. It succeeds.

Relevant log evidence

write ACE grant failed on <REDACTED_USER_PROFILE_PATH>
SetNamedSecurityInfoW failed: 5
setup refresh completed with errors

The sandbox log shows 43 failed setup-refresh attempts for C: drive workspaces, with 111–116 write roots. It shows 47
successful attempts for other-drive workspaces, with 2 write roots.

Session / token information

Not applicable. This is a Windows sandbox setup failure that occurs before PowerShell and the requested command start, so no command-level session ID, token-limit usage, or context-window usage is produced.

What is the expected behavior?

When a workspace is opened from a location on the C: drive, Codex App should initialize the elevated Windows sandbox and run sandboxed commands normally, just as it does when the workspace is opened from D
For example, a minimal command such as whoami should start PowerShell and return its output.
If sandbox initialization cannot grant a required filesystem ACE, Codex should report the exact blocked directory and operation. It should not fail command creation with only the generic message “setup refresh had errors” before the requested shell process starts.

Additional information

• Codex version metadata: 0.154.0
  • Platform: Microsoft Windows NT 10.0.26200.0 x64
  • Sandbox mode: elevated
  • The same failed user-profile child path appears in retained sandbox logs across at least 13 dates, from 2026-08-25 through 2026-09-11.
  • The failing path is now absent, so its historical ACL cannot be inspected. It was neither AppData nor .codex.
  • CODEX_HOME/.sandbox/deny_read_acl_state.json is present, valid JSON, 22 bytes, and contains zero NUL bytes.
  • The user-profile directory is owned by NT AUTHORITY\SYSTEM and has a protected DACL.
  • I am attaching a redacted sandbox log. No .sandbox-secrets content, credentials, tokens, or unredacted private paths are included.

Start with the elevated Windows sandbox setup-refresh path and reproduce the failure using the supplied C: and D:\downloading\sub2 workspace comparison with whoami. Trace the SetNamedSecurityInfoW failure and the write-root handling using the attached diagnostic evidence. Done means C: workspaces initialize successfully, or the blocked directory and operation are reported instead of only setup refresh had errors.