Windows Codex CLI 0.155.0 Sandbox fails with SetNamedSecurityInfoW error 5 when workspace owner is BUILTIN\Administrators

What version of Codex CLI is running?

codex-cli 0.155.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal, PowerShell 7.6.6

What issue are you seeing?

Codex CLI 0.155.0 fails to initialize the Windows elevated sandbox when the workspace owner is BUILTIN\Administrators.

The startup UI shows:

Couldn't set up your sandbox with Administrator permissions

The sandbox log shows:

granting write ACE to WORKSPACE_PATH
write ACE grant failed on WORKSPACE_PATH:
SetNamedSecurityInfoW failed: 5

setup refresh had errors

Windows error 5 means Access Denied.

I checked the workspace ACL and found:

Owner: BUILTIN\Administrators

Codex is running as a normal, non-elevated user process. During sandbox setup, Codex needs to modify the workspace DACL to add sandbox ACEs. When the workspace is owned by BUILTIN\Administrators, this operation fails with ERROR_ACCESS_DENIED (5).

I reproduced this behavior with an A/B test on the same machine:

Workspace owner = BUILTIN\Administrators
→ Sandbox setup fails with SetNamedSecurityInfoW failed: 5

Workspace owner = current Windows user
→ Sandbox ready

I then changed only the owner of the original workspace to the currently logged-in Windows user, leaving the rest of the ACL unchanged.

After that, Codex CLI 0.155.0 initialized the sandbox successfully and reported:

Sandbox ready
Permissions: Workspace (Ask for approval)

I also verified that the sandbox security boundary still works correctly:

Writing inside the workspace succeeds.
A second write inside the workspace does not trigger another UAC prompt.
Writing outside the workspace still requires explicit approval.
If approval is denied, the outside file is not created.

What steps can reproduce the bug?

1. On Windows 11, use Codex CLI 0.155.0 with the Windows elevated sandbox.

2. Use a workspace whose NTFS owner is:

BUILTIN\Administrators

3. Start Codex normally as a non-elevated user.

4. Codex fails to initialize the sandbox. The sandbox log contains:

granting write ACE to WORKSPACE_PATH
write ACE grant failed on WORKSPACE_PATH:
SetNamedSecurityInfoW failed: 5

setup refresh had errors

5. Check the workspace owner with PowerShell:

(Get-Acl "WORKSPACE_PATH").Owner

6. Change only the workspace owner to the currently logged-in Windows user, leaving the rest of the ACL unchanged:

icacls "WORKSPACE_PATH" /setowner "$env:USERDOMAIN$env:USERNAME"

7. Start Codex normally again.

8. The sandbox now initializes successfully and reports:

Sandbox ready
Permissions: Workspace (Ask for approval)

9. Verify the sandbox boundary:

• writing inside the workspace succeeds;
• writing outside the workspace requires explicit approval;
• if approval is denied, the outside file is not created.

What is the expected behavior?

Codex should either initialize the Windows sandbox successfully or clearly detect that the current user cannot modify the workspace DACL.

Instead of failing with the generic error:

SetNamedSecurityInfoW failed: 5
setup refresh had errors

Codex should provide a clear, actionable message explaining that the workspace ownership or DACL prevents sandbox setup.

Ideally, Codex could offer a UAC-assisted repair or guide the user to change the workspace owner to the current Windows user while preserving the existing ACL and sandbox security boundary.

Additional information

I verified the workaround without disabling the sandbox or granting Codex Full Access.

After changing only the workspace owner from BUILTIN\Administrators to the current Windows user:

• Codex CLI 0.155.0 reported Sandbox ready.
• /status reported Permissions: Workspace (Ask for approval).
• Writing files inside the workspace succeeded.
• A second write inside the workspace did not trigger another UAC prompt.
• Writing outside the workspace still required explicit approval.
• After denying that approval, the outside file was not created.

The rest of the workspace ACL was left unchanged.

This strongly suggests that the workspace ownership / WRITE_DAC state is the trigger in this reproducible case.

Start by reproducing the Windows elevated-sandbox setup with a workspace owned by BUILTIN\Administrators, then compare it with a workspace owned by the current user and inspect the sandbox log for SetNamedSecurityInfoW error 5. Done means the CLI either initializes the sandbox successfully or reports a clear, actionable ownership or DACL limitation without weakening the sandbox boundary.