Windows elevated sandbox permanently fails with SetNamedSecurityInfoW error 5 on C:\ProgramData\Temp

Open 💬 2 comments Opened Jul 15, 2026 by BennetYrWang

Description

Codex Desktop's Windows elevated sandbox stopped working permanently after one transient sandbox failure.

Before the failure, new sessions worked normally. After one failure, every new session failed during sandbox initialization.

The failure persisted after:

  • Restarting Codex Desktop
  • Rebooting Windows
  • Repairing the workspace owner and ACLs
  • Resetting the ACLs on C:\ProgramData\Temp

Switching to the unelevated Windows sandbox makes normal sandbox commands work again.

Environment

  • Codex Desktop version: 26.707.9981.0
  • Windows
  • Model: 5.6-luna medium fast
  • Sandbox mode: workspace-write
  • Windows sandbox mode: elevated
  • Workspace: local NTFS path

I do not currently believe the model is causal, because the failure occurs during Windows sandbox ACL initialization before command execution.

Error

The sandbox log reports:

write ACE grant failed on C:\ProgramData\Temp:
SetNamedSecurityInfoW failed: 5

setup refresh completed with errors:
["write ACE failed on C:\\ProgramData\\Temp: SetNamedSecurityInfoW failed: 5"]

setup error: setup refresh had errors

The initial failure also involved the workspace path:

write ACE grant failed on D:\Projects\Portfolio\Master Application\Midnight-Cafeteria-V2:
SetNamedSecurityInfoW failed: 5

After repairing the workspace ACL, the workspace error disappeared. The remaining failure was consistently on C:\ProgramData\Temp.

At the time of the test, C:\ProgramData\Temp had:

  • Owner: BUILTIN\Administrators
  • SYSTEM: Full Control
  • BUILTIN\Administrators: Full Control
  • BUILTIN\Users: Modify
  • Noct\CodexSandboxUsers: Modify

Despite these permissions, the elevated sandbox helper continued to fail when trying to grant its ACE.

Workaround

Changing the configuration to:

[windows]
sandbox = "unelevated"

allows normal sandbox commands to run again.

However, this is only a workaround because it does not provide the elevated Windows sandbox setup path needed for administrator-level operations.

Expected behavior

The elevated sandbox should either:

  1. Refresh the ACLs successfully, or
  2. Report which account, SID, or security policy prevents the ACE update.

Related issue: #22428

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗