Windows elevated sandbox setup fails after Codex Desktop 26.609 update/reinstall: SetNamedSecurityInfoW failed: 5 on WindowsApps package directory

Windows sandbox initialization fails with SetNamedSecurityInfoW ERROR_ACCESS_DENIED (5)

Summary

The Windows sandbox fails during initialization before any local command is executed.

As a consequence, every local action fails:

• apply_patch
• PowerShell
• Get-Content
• Add-Content
• Any shell command

Environment

• Codex App version: 26.715.2305.0
• Subscription: ChatGPT Plus
• Platform: Windows 11 x64
• Windows sandbox mode: elevated
• Projects marked as trusted
• Reproduced on both C: and G: drives

Steps to reproduce

1. Open the ChatGPT Windows application (Codex integrated).
2. Open any trusted local project.
3. Create a file named test.txt containing:

hello

1. Ask Codex to append one line using apply_patch.

Alternatively, execute:

Add-Content .\test.txt "test ok"

The same failure also occurs with:

Get-Content .\test.txt

Expected behavior

The Windows sandbox initializes successfully.

PowerShell starts normally.

Commands such as:

• apply_patch
• Add-Content
• Get-Content

execute successfully.

Example:

hello
test ok

Actual behavior

No local command is executed.

PowerShell never starts.

The application immediately returns:

execution error: Io(Custom {
  kind: Other,
  error: "windows sandbox: helper_unknown_error: setup refresh had errors"
})

The sandbox log consistently reports:

granting write ACE to G:\_SYSTEM\TEMP
granting write ACE to G:\STACK\odysseus-main-1.0.2

write ACE grant failed:
SetNamedSecurityInfoW failed: 5

setup refresh completed with errors
setup error: setup refresh had errors
ExitStatus(1)

Windows error code 5 corresponds to:

ERROR_ACCESS_DENIED

The failure appears to occur while the sandbox helper attempts to grant NTFS write ACL permissions during sandbox initialization.

Investigation already performed

The following checks have already been completed:

• config.toml verified
• sandbox = "elevated"
• Helper executable exists
• Helper executable signature is valid
• Projects are trusted
• Reproduced on both C: and G: drives
• Reproduced in a brand new folder containing only test.txt
• ChatGPT restarted
• Application reinstalled
• apply_patch fails
• Add-Content fails
• Get-Content fails

The issue always occurs before PowerShell starts.

Comparison with existing issue #27889

My issue appears closely related to #27889 but differs in one important aspect.

Issue #27889 reports:

• failure while granting READ ACLs on the protected WindowsApps package directory.

My issue (version 26.715.2305.0) reports:

• failure while granting WRITE ACLs on normal workspace directories.

Example:

granting write ACE to G:\STACK\odysseus-main-1.0.2
SetNamedSecurityInfoW failed: 5

The final error is identical:

windows sandbox: helper_unknown_error: setup refresh had errors

This suggests the underlying sandbox ACL initialization problem still exists in the latest release, although it now affects workspace directories instead of the WindowsApps package directory.

Attachments

• sandbox.2026-07-17.log
• config_sanitized.toml

Additional note

The issue was reproduced through multiple controlled tests on different drives and clean workspaces.

sandbox.2026-07-17.log

The problem is fully reproducible and independent of the workspace location.

If additional diagnostics or testing are required, I would be happy to provide them.

I can reproduce the WindowsApps ACL failure on the current Windows Store Codex Desktop package 26.715.2305.0 (CLI/helper 0.145.0-alpha.18). I also found a second failure mode that makes the documented unelevated fallback unusable with least-privilege named permission profiles.

Configuration under test: a custom named permission profile with split filesystem permissions (:minimal = read, workspace/temp = write).

[windows] sandbox = "elevated"

apply_patch hangs while codex-windows-sandbox-setup.exe tries to add a read ACE to the protected package resources directory:

read-acl-only mode: applying read ACLs
granting read ACE to C:\Program Files\WindowsApps\OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0\app\resources for sandbox users
grant read ACE failed ... SetNamedSecurityInfoW failed: 5
read ACL run completed with errors
setup error: read ACL run had errors

The setup process can remain active for tens of seconds/minutes, and apply_patch does not return the setup error promptly.

[windows] sandbox = "unelevated"

Creating a brand-new file can succeed, but a patch that must read/update/delete an existing file fails immediately:

apply_patch verification failed: Failed to read <temp-file>:
failed to prepare fs sandbox:
failed to prepare windows sandbox wrapper:
windows unelevated restricted-token sandbox cannot enforce split filesystem read restrictions directly; refusing to run unsandboxed

I searched this repository for that exact error and found no existing open issue.

Workaround

Switching back to the legacy configuration:

sandbox_mode = "workspace-write"

[windows]
sandbox = "unelevated"

makes apply_patch create/read/delete complete in under one second and avoids codex-windows-sandbox-setup, but it restores broad :root read access. Therefore this is not an equivalent least-privilege fallback.

Expected: elevated mode should not need to mutate ACLs inside the protected MSIX/WindowsApps package, or unelevated mode should support/enforce split read/write named permission profiles. At minimum, apply_patch should return the setup error instead of hanging.

Update – Improved fallback behavior in 26.715.52143 (sandbox issue still present)

I retested the issue after updating both ChatGPT Desktop and Windows.

Environment

• ChatGPT Desktop: 26.715.52143
• Windows: fully updated (including KB5121767)
• Full system reboot performed after all updates

---

Summary

The underlying Windows sandbox initialization failure is still present.

However, the behavior has noticeably improved compared to previous builds.

The application can now recover from several operations using fallback mechanisms, although apply_patch remains unusable.

---

Test 1 – Read-only inventory

Request

Perform a read-only inventory of the project.

Result

The sandbox still fails before PowerShell starts:

windows sandbox failed: helper_unknown_error: setup refresh had errors

Instead of aborting completely, Work automatically switches to a read-only fallback and successfully completes the inventory.

Status

• ❌ Windows sandbox initialization
• ✅ Read-only fallback

---

Test 2 – File creation

Request

Create:

nouveau.txt

containing:

bonjour

Result

The verification phase initially reports the same sandbox initialization failure.

A second independent verification is then performed successfully.

The file is correctly created with the expected content.

Status

• ✅ File creation
• ✅ Independent verification
• ❌ Windows sandbox still failing

---

Test 3 – Targeted patch (apply_patch)

Request

Replace:

hello

with

salut

inside test.txt using a targeted patch.

Result

The patch never starts.

The same error is reported:

windows sandbox failed: helper_unknown_error: setup refresh had errors

The assistant correctly refuses to rewrite the entire file as a fallback.

An independent verification confirms that test.txt remains unchanged.

Status

• ❌ apply_patch
• ✅ File integrity preserved

---

Current status

| Feature | Status |
|---------|:------:|
| Windows sandbox initialization | ❌ |
| Read-only fallback | ✅ |
| Simple file creation | ✅ |
| Independent verification | ✅ |
| Targeted patch (apply_patch) | ❌ |

---

Conclusion

This release significantly improves recovery behavior after a sandbox initialization failure.

Compared to previous versions:

• read-only operations can continue through a fallback mechanism;
• simple file creation succeeds;
• verification after failure is robust.

However, the underlying Windows sandbox initialization issue remains unresolved, and apply_patch is still blocked by the same:

helper_unknown_error: setup refresh had errors

If helpful, I can also provide updated diagnostics and logs collected with this version.

I have met the same situation. After I chat with gpt😂, I found my computer does not rename, its name is set as default. And I rename my computer. It actucally works. Here is summary from Codex. All private imformation is exchange with common name.

Resolved: Windows sandbox setup failed because of an ambiguous local security authority name

I was able to resolve this issue on my machine. I am sharing the diagnostics and workaround in case they help others with the same combination of errors.

Environment

• Windows 11 x64, build 26200
• Microsoft Store version of Codex Desktop
• Codex package version: 26.715.10079.0
• Native Windows elevated sandbox

All personal account names, computer names, profile paths, workspace paths, and SID values below have been redacted.

Original symptoms

The elevated sandbox setup partially succeeded:

• CodexSandboxOffline and CodexSandboxOnline were created.
• The firewall/WFP setup completed successfully with 12 filters.
• The setup helper reported that its main setup phase had completed.

It then failed while applying read ACLs to the protected Microsoft Store package directory:

granting read ACE to C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__<publisher>\app for sandbox users
grant read ACE failed ... for sandbox_group: SetNamedSecurityInfoW failed: 5
read ACL run completed with errors
setup error: read ACL run had errors

setup_error.json contained:

{
  "code": "helper_unknown_error",
  "message": "read ACL run had errors"
}

There was also a second ACL problem: the normal desktop user could not read:

%USERPROFILE%\.codex\.sandbox\setup_marker.json

The parent sandbox directory contained an unusual ACL trustee similar to:

<LOCAL_SECURITY_AUTHORITY>\:(OI)(CI)(RX,W)

The account name after the backslash was empty. The SID used by that ACE was only the local machine/domain SID prefix, while the actual desktop user SID had an additional RID suffix. In other words, the permission was not granted to the real desktop user.

Important name mismatch

Windows exposed two different machine names on this system:

hostname / Settings device name:  <generated-hostname>
COMPUTERNAME / USERDOMAIN:         <old-local-security-name>
whoami:                            <old-local-security-name>\<user>

The old local security name and the user account name were identical when compared case-insensitively. My working theory is that the elevated setup helper resolved the unqualified account name to the local machine/domain SID rather than to the user SID. This would explain the missing user RID and the empty trustee shown by icacls.

This is an observed trigger on my system, not a confirmed upstream root-cause analysis.

What fixed it

1. I renamed the PC through Settings > System > About > Rename this PC.
2. I chose a short, unique computer name that did not match the Windows user account name.
3. I rebooted Windows.
4. I fully closed and reopened Codex Desktop, then retried sandbox setup.

After the reboot, the relevant Windows names were consistent and the sandbox account was qualified by the new computer name. Codex then refreshed the sandbox successfully.

The successful log changed to:

setup refresh: processed 4 write roots (read roots delegated); errors=[]
setup binary completed
read-acl-only mode: applying read ACLs
read ACL run completed
helper launch resolution: using copied command-runner path ...

Commands now execute as:

<NEW-COMPUTER-NAME>\CodexSandboxOffline

setup_error.json is no longer present, normal read/write operations work, and the elevated Windows sandbox is active.

I did not take ownership of C:\Program Files\WindowsApps, recursively reset ACLs, or grant danger-full-access.

Optional narrow marker-file repair

If the PC has already been renamed but a stale setup_marker.json is still unreadable, the following community workaround grants read permission to the actual current user SID on that single file. Run it from an elevated PowerShell window:

$marker = Join-Path $env:USERPROFILE '.codex\.sandbox\setup_marker.json'
$userSid = [System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value
icacls $marker /grant "*${userSid}:(R)"

Using the SID avoids another ambiguous account-name lookup. I would not use takeown /R, icacls /T, or modify the entire WindowsApps tree.

Related reports

• https://github.com/openai/codex/issues/27889
• https://github.com/openai/codex/issues/30445
• https://github.com/openai/codex/issues/28566

I hope this gives the maintainers a reproducible clue: when writing the marker ACL, the setup helper should resolve and persist the invoking user's full SID, including the user RID, instead of relying on an ambiguous unqualified account name.

I can reproduce the same issue on the latest Codex Desktop build.

Environment

• Windows 11 Pro x64
• Windows build: 26200
• Codex Desktop package version: 26.721.4979.0
• Package status: Ok
• Installation path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0

• Windows sandbox configuration:

[windows]
sandbox = "elevated"

Error

The elevated Windows sandbox setup repeatedly fails with:

SetNamedSecurityInfoW failed: 5

The Codex Desktop app continues to display “Windows setup incomplete” after selecting “Retry Windows setup” and approving the UAC prompt.

Diagnostics performed

• Confirmed Codex Desktop is already up to date.
• Confirmed the Microsoft Store package status is Ok.
• Removed the previous failed sandbox state and retried initialization.
• Switched config.toml from unelevated back to elevated.
• Confirmed that the following local sandbox accounts exist and are enabled:
• CodexSandboxOffline
• CodexSandboxOnline
• Retried Windows setup multiple times with administrator approval.
• The elevated sandbox still cannot complete initialization.
• The app currently works only by falling back to:

[windows]
sandbox = "unelevated"

This appears to be the same WindowsApps ACL failure reported here, still reproducible in Codex Desktop 26.721.4979.0 on Windows build 26200.

Please investigate a fix that does not require modifying the protected WindowsApps ACL manually.

Confirmed the workaround on Windows.

The original error was:

windows sandbox: helper_unknown_error: apply deny-read ACLs

I closed Codex and renamed:

$HOME\.codex\.sandbox\deny_read_acl_state.json

After reopening Codex, the original thread changed to:

windows sandbox: helper_unknown_error: setup refresh had errors

That thread remained unable to spawn even a minimal command.

I then created a completely new Codex thread and ran:

cmd.exe /d /c echo codex-sandbox-ok

The command completed successfully.

So recovery required both:

1. Renaming/deleting the corrupted deny_read_acl_state.json so Codex rebuilds it.
2. Abandoning the affected thread and creating a new one, because the old thread remained attached to an unhealthy sandbox broker.

This appears consistent with the thread-scoped broker behavior described in #34842.

Renaming the state file instead of deleting it is useful because it preserves the corrupted file for diagnostics.

Still reproducible on Windows 11 Enterprise 25H2. Running /setup-default-sandbox failed twice. The setup created the sandbox users and firewall rules, but failed while applying the required permission to the protected WindowsApps directory.

After selecting Quit, %USERPROFILE%\.codex\config.toml still contains:

[windows]
sandbox = "unelevated"

No %USERPROFILE%\.codex\.sandbox\sandbox.log was created at the checked path.

I uploaded the session diagnostics using /feedback.

Session ID: 019ff3d4-39d5-7a13-8891-d84179e29e54

I can reproduce the same issue on a clean Windows 10 installation with a newer Codex build.

Environment:

• Windows 10 Education 22H2 x64
• OS Build 19045.6456
• Codex App: 26.810.7004.0
• Package: OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0
• Windows sandbox mode: elevated

The sandbox infrastructure is created successfully:

• CodexSandboxOffline exists and is enabled
• CodexSandboxOnline exists and is enabled
• Both users are members of CodexSandboxUsers
• Firewall/WFP setup succeeds
• setup_marker.json is created with version 5

However, sandbox refresh still fails during the read-ACL phase.

setup_error.json:

{
"code": "helper_unknown_error",
"message": "read ACL run had errors"
}

Relevant sandbox log:

granting read ACE to C:\Program Files\WindowsApps\OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0\app for sandbox users

grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0\app for sandbox_group: SetNamedSecurityInfoW failed: 5

read ACL run completed with errors
setup error: read ACL run had errors

I also verified:

• The target app path is a normal directory, not a junction/reparse point.
• The directory is owned by SYSTEM and has the normal protected WindowsApps / TrustedInstaller ACL.
• CodexSandboxUsers has no explicit ACE on the directory.
• deny_read_acl_state.json contains no principals.
• I have not used takeown, icacls, or manually modified WindowsApps permissions.

So this appears to still reproduce in Codex App 26.810.7004.0 on a clean Windows 10 installation.

I can confirm this is still reproducible on a newer Codex Desktop package.

Observed package path in my logs:

C:\Program Files\WindowsApps\OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0\...

With:

[windows]
sandbox = "elevated"

Codex Desktop stopped being able to start agent/chat turns.

The sandbox log repeatedly showed:

grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0\app\resources\codex.exe for sandbox_group:
SetNamedSecurityInfoW failed: 5

read ACL run completed with errors
setup error: read ACL run had errors

In the same setup cycle I also got:

deny ACE failed on E:\PythonProject\Scripts\delphi-agent-arena\.git:
SetNamedSecurityInfoW failed for E:\PythonProject\Scripts\delphi-agent-arena\.git: 5

setup refresh completed with errors
setup error: setup refresh had errors

Earlier, the same failure had occurred while applying deny-read ACLs to the repository's .env.

One notable side effect was that files/directories touched by the sandbox ended up owned by CodexSandboxOffline. In particular, .git was left owned by the sandbox account, which then triggered Git's detected dubious ownership protection when Codex Desktop ran as my normal Windows user.

Changing ownership of the affected .env/.git back to my interactive user fixed those individual filesystem failures, but did not fix the elevated sandbox because the WindowsApps codex.exe ACL operation still failed with error 5.

Temporary recovery was:

sandbox_mode = "danger-full-access"
approval_policy = "on-request"

[windows]
sandbox = "unelevated"

I also had to stop selecting a custom default_permissions profile that required deny-read restrictions, because the unelevated restricted-token sandbox correctly refused to run when those restrictions were still requested.

After that change, new and existing Codex chats started working again. I did not delete or repair any session data.

So this appears to still affect the 26.818 package line and is not limited to the older 26.609 build reported originally.

I can provide sanitized sandbox/Desktop logs if useful.

I found a workaround that restored the elevated Windows sandbox on my PC.

In my original setup, the Windows account name and the computer name
were the same. I did not rename the computer. Instead, I did the
following:

1. Created a new local Windows user named "Codex Worker", so the

Windows user name and computer name were different.

1. Temporarily added that new user to the local Administrators group.
2. Signed in with the new user and installed/reinstalled Codex Desktop there.
3. Completed the Codex setup and verified that the sandbox worked.
4. Removed the administrator rights from "Codex Worker" again.

The sandbox has continued to work under that account after it was
changed back to a standard user. I did not take ownership of, or
manually modify ACLs inside, the WindowsApps package directory.

This is only a workaround, not proof of the root cause. However, it
suggests that either a collision between the Windows user name and
computer name, stale per-user state, or the initial elevated
installation/setup path may be relevant. It may be useful for others
affected by SetNamedSecurityInfoW failed: 5 to test the same sequence.