Windows sandbox can leave workspace owned by CodexSandboxOnline, then setup refresh fails with SetNamedSecurityInfoW 5

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

Observed from sandbox log path:

OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0
codex-command-runner-0.142.0.exe

The in-app/browser environment previously reported BROWSER_USE_CODEX_APP_VERSION=26.616.71553, but the current sandbox helper path in the log is the AppX package above.

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows desktop app, Windows x64.

What issue are you seeing?

Codex Windows sandbox setup started failing before ordinary commands and apply_patch could run. The important part is that the workspace directory owner had become a Codex sandbox account.

Before manual repair, read-only commands and apply_patch were blocked with:

windows sandbox: helper_unknown_error: setup refresh had errors

The current setup error file contained:

{
  "code": "helper_unknown_error",
  "message": "setup refresh had errors"
}

The sandbox log showed repeated failures while trying to grant write ACEs to the workspace root:

setup refresh: spawning C:\Program Files\WindowsApps\OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe

granting write ACE to <WORKSPACE_ROOT> for sandbox group and capability SID
write ACE grant failed on <WORKSPACE_ROOT>: SetNamedSecurityInfoW failed: 5
setup refresh: processed 2 write roots (read roots delegated); errors=["write ACE failed on <WORKSPACE_ROOT>: SetNamedSecurityInfoW failed: 5"]
setup refresh completed with errors: ["write ACE failed on <WORKSPACE_ROOT>: SetNamedSecurityInfoW failed: 5"]
setup error: setup refresh had errors
setup refresh: exited with status ExitStatus(ExitStatus(1))

ACL inspection showed the project path had unexpected owners:

<WORKSPACE_PARENT> Owner: <MACHINE>\CodexSandboxOffline
<WORKSPACE_ROOT>   Owner: <MACHINE>\CodexSandboxOnline

The user did not intentionally set these owners. The workspace is a normal local project directory, not something that should be owned by sandbox service accounts.

After the user manually reset ownership back to their Windows user, the same Codex thread recovered immediately:

<WORKSPACE_PARENT> Owner: <MACHINE>\<USER>
<WORKSPACE_ROOT>   Owner: <MACHINE>\<USER>

Post-repair verification:

Get-Location => success inside sandbox
git status --short --untracked-files=all => success inside sandbox
apply_patch add temporary probe file => success
Get-Content temporary probe file => success
apply_patch delete temporary probe file => success

The sandbox log after the owner repair shows setup refresh succeeding again:

setup refresh: processed 2 write roots (read roots delegated); errors=[]
codex-windows-sandbox-setup.exe] setup binary completed

This strongly suggests the failure was not a project file problem or patch-content problem. It was caused by the workspace or parent directory being left owned by CodexSandboxOnline / CodexSandboxOffline, after which the sandbox helper could no longer grant the required ACE and every command path failed.

What steps can reproduce the bug?

I do not yet have a deterministic fresh reproduction for the ownership change itself. The observed sequence was:

1. Use Codex Desktop on Windows with workspace-write and [windows] sandbox = "elevated".
2. Work in a normal local project directory.
3. After recent Windows Desktop sandbox/helper activity, commands and apply_patch start failing before execution with helper_unknown_error: setup refresh had errors.
4. Inspect ACL ownership for the workspace and parent directory.
5. Observe owner values of CodexSandboxOnline / CodexSandboxOffline instead of the user account.
6. Manually reset owners back to the user account.
7. Retry ordinary sandbox commands and apply_patch; they succeed, and setup refresh logs errors=[].

What is the expected behavior?

Codex sandbox may create sandbox users, add temporary ACL entries, or create junctions as needed, but it should never leave a user workspace or workspace parent directory owned by CodexSandboxOnline / CodexSandboxOffline.

If ownership or ACL state is abnormal, Codex should report a clear diagnostic and remediation, rather than failing as a generic helper_unknown_error.

Additional information

Local config included:

sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"

[sandbox_workspace_write]
network_access = true

There was no C:\Users\<USER>\.codex\.env file, so this does not appear to be the proxy-env helper regression path.

This is high severity because it mutates or leaves behind Windows ownership state on user workspace directories. Even after the immediate failure is fixed by resetting the owner, users may not realize their project tree or parent directory is owned by a Codex sandbox account.