Windows workspace-write sandbox can change project ownership to CodexSandboxOffline and cause persistent write failures

What version of the IDE extension are you using?

VS Code extension version: 26.318.11754

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

Antigravity, VS Code

What platform is your computer?

Windows

What issue are you seeing?

Title

Windows sandbox workspace-write can corrupt directory ownership to CodexSandboxOffline, causing persistent write failures until manual admin ACL repair

Summary

I hit a Windows-specific issue where Codex could write successfully in full access mode, but failed in workspace-write / custom sandbox mode for files inside my project.

The failure persisted across:

waiting and retrying later
restarting the computer
switching IDEs from Antigravity to VS Code

The problem was eventually traced to directory ownership / ACL corruption inside the project. Some directories and files had their owner changed to CodexSandboxOffline instead of the normal Windows user account. While that state remained, sandbox setup failed and Codex could not edit files in those locations.

Manual repair from an Administrator PowerShell session restored normal behavior.

Environment

OS: Windows
Codex sandbox mode: workspace-write
Approval policy: never
Windows sandbox setting: elevated
IDEs tested:
- Antigravity
- Visual Studio Code

Config

This is the relevant Codex config shape:

model = "gpt-5.4"
model_reasoning_effort = "low"
approval_policy = "never"
sandbox_mode = "workspace-write"

writable_roots = [
    '<PROJECT_ROOT>',
    '<ANOTHER_WORKSPACE_ROOT>'
]

[features]
multi_agent = true

[windows]
sandbox = "elevated"

What happened

I was working normally, and file edits had worked previously.

At some point:

the internet connection dropped
an IDE update had happened a few hours earlier
later, Codex started failing to edit a file inside the project in custom / workspace-write sandbox mode

I do not know whether the network interruption was causal, but the timeline suggests that sandbox state may have been left half-updated or recovered incorrectly after an interruption.

Initial symptoms

When Codex tried to edit a file with apply_patch, it failed with:

windows sandbox: setup refresh failed with status exit code: 1

When Codex tried a direct PowerShell rewrite of the same file, it failed with:

Access to the path '...AppConfig.ahk' is denied.

In full access mode, the same edit succeeded immediately.

Important behavior difference

full access: file edits succeeded
workspace-write / custom sandbox: file edits failed

This strongly suggested a sandbox setup / ACL issue rather than a file-content issue.

IDE switching did not fix it

I changed from Antigravity to Visual Studio Code and reopened the same chat/session context.

The failure reproduced in VS Code as well:

apply_patch still failed with sandbox setup refresh errors
direct file writes still failed with Access denied

This suggests the issue is not specific to one IDE frontend.

Restarting did not fix it

After a full machine reboot, the same write failure still happened in sandboxed mode.

In one attempt, a related launcher failure also appeared:

CreateProcessWithLogonW failed: 1056

Even after that, the underlying issue remained: sandboxed writes to the affected project path were broken.

Sandbox log evidence

The most important evidence came from the sandbox log. It showed that sandbox setup was trying to grant a write ACE to a project subdirectory and failing with Windows error 5 (Access is denied):

granting write ACE to <PROJECT_ROOT>\src\Core for sandbox group and capability SID
write ACE grant failed on <PROJECT_ROOT>\src\Core: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors
setup error: setup refresh had errors

This lines up exactly with the user-visible apply_patch failure.

ACL / ownership inspection

Inspecting the project showed that:

the project root owner was the normal user account
some subdirectories were owned by CodexSandboxOffline
affected files under those directories were also owned by CodexSandboxOffline

Example pattern:

<PROJECT_ROOT> owner: normal user account
<PROJECT_ROOT>\src owner: CodexSandboxOffline
<PROJECT_ROOT>\src\Core owner: CodexSandboxOffline

This seems wrong and likely explains why sandbox ACL refresh could not proceed.

Scope of corruption

After scanning the whole project, many items had the wrong owner. In my case the scan found hundreds of mismatches, concentrated in directories like:

temp
tests
runtime
materials
some tracked files in project root and docs

The wrong owner observed was consistently:

CodexSandboxOffline

Repair attempt

Normal non-admin repair attempts failed:

icacls /setowner ... returned Access is denied
takeown reported that the current user did not have administrative privileges

Repair only worked from an Administrator PowerShell session.

These commands were used successfully:

takeown /F "<PROJECT_ROOT>" /R /D Y
icacls "<PROJECT_ROOT>" /setowner "<MACHINE>\<USER>" /T /C
icacls "<PROJECT_ROOT>" /inheritance:e /T /C

After that:

affected directories were owned by the normal user again
sandboxed apply_patch started working again
sandboxed writes to the previously failing file succeeded

Strong suspicion

My current suspicion is:

Codex sandbox touched project ACLs / ownership during a degraded or interrupted state
ownership on some paths was left as CodexSandboxOffline
later sandbox setup attempts could no longer repair those paths
full access worked because it bypassed the failing sandbox ACL setup path

I cannot prove that the network drop caused it, but the timing is suspicious. The IDE update may also have changed sandbox behavior or made a previously latent ACL problem visible.

Expected behavior

workspace-write should never leave project files or directories owned by a transient sandbox identity like CodexSandboxOffline
sandbox setup failure should not permanently poison a workspace until manual admin ACL repair is performed
if ACL modification fails, Codex should provide a more explicit diagnosis

Actual behavior

ownership of project files/directories changed to CodexSandboxOffline
sandbox setup started failing with SetNamedSecurityInfoW failed: 5
apply_patch failed with setup refresh failed
file writes in sandboxed mode became impossible until manual admin repair

Suggested areas to investigate

sandbox ownership / ACL mutation on Windows
recovery behavior after interrupted sandbox setup
behavior differences between normal online state and any offline / degraded fallback identity
why CodexSandboxOffline can become the owner of user project paths
whether IDE update + sandbox helper version change can expose or create this state

Minimal repro shape

I do not yet have a fully deterministic repro from scratch, but this was the observed sequence:

Use Codex on Windows with workspace-write
Successfully edit files in a project for a while
Experience an interruption such as network drop and/or IDE update / restart during the same general period
Later attempt an edit in the same project
Observe sandbox refresh failure and Access denied
Inspect owners on subdirectories and find CodexSandboxOffline

End result

The issue was only resolved after manual Administrator-level ownership repair of the project tree.

What steps can reproduce the bug?

I was using Codex on Windows with sandbox_mode = "workspace-write" and approval_policy = "never".

At first, file editing worked normally.

Later, after a period that included a network interruption and an IDE update, Codex stopped being able to edit files in the project when running in sandboxed mode.

Symptoms:

apply_patch failed with:
windows sandbox: setup refresh failed with status exit code: 1
direct file rewrite attempts failed with:
Access to the path '...AppConfig.ahk' is denied.

I confirmed that the same edit succeeded immediately in full access mode.

I also reproduced the same sandboxed write failure after:

waiting and retrying later
rebooting the computer
switching IDEs from Antigravity to VS Code

I inspected the sandbox log and found:

granting write ACE to <PROJECT_ROOT>\src\Core for sandbox group and capability SID
write ACE grant failed on <PROJECT_ROOT>\src\Core: SetNamedSecurityInfoW failed: 5

I then inspected file ownership and found that some project paths were owned by CodexSandboxOffline instead of my normal Windows user account.

Example:

<PROJECT_ROOT> owner: normal user
<PROJECT_ROOT>\src owner: CodexSandboxOffline
<PROJECT_ROOT>\src\Core owner: CodexSandboxOffline

After manually repairing ownership and ACLs from an Administrator PowerShell session, sandboxed writes started working again.

Uploaded thread: 019d6ccf-f4c0-72c2-9943-26f7321c67ad

What is the expected behavior?

workspace-write mode should not change project files or directories to be owned by a transient sandbox identity such as CodexSandboxOffline.

If sandbox ACL setup fails, it should not leave the workspace in a permanently broken state where Codex can no longer edit files until manual Administrator-level repair is performed.

Codex should either:

preserve the original ownership correctly, or
fail safely without corrupting ownership / ACL state, and
report a clearer diagnostic if Windows ACL mutation fails.

Additional information

The issue appeared to be environment-independent at the IDE layer:

it happened in Antigravity
it also happened in VS Code

Rebooting did not fix it.

The issue was only resolved after running Administrator-level repair commands on the project tree, for example:

takeown /F "<PROJECT_ROOT>" /R /D Y
icacls "<PROJECT_ROOT>" /setowner "<MACHINE>\<USER>" /T /C
icacls "<PROJECT_ROOT>" /inheritance:e /T /C

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Codex sandbox installation corrupts ACL on AppData #15777
windows sandbox: setup refresh failed exit code: 1 #17065
Windows sandbox instability: apply_patch intermittently fails with "windows sandbox: setup refresh failed with status exit code: 1" #16643
Windows desktop: apply_patch intermittently fails with "windows sandbox: setup refresh failed" after directory refresh #16347
Windows workspace-write sandbox still broken in 0.116.0 after state reset; bypass mode works #15850

Powered by Codex Action

For windows users, worktrees development are not functioning. this issue is applied to me currently since the first launch of codex. This situation getting us worse in productivity and ci/cd. Those who see this issue and are on the same situation, give thumbs up to the issue; otherwise we won't get a full functionality with codex.

I can provide a deterministic reproduction for this issue.

Environment:

Codex Desktop for Windows: 26.818.8289.0
command runner: 0.149.0-alpha.4.3
sandbox mode: workspace-write
Windows user: domain account
workspace on a local drive

Reproduction:

Start with an existing empty directory owned by the normal Windows user:
```
D:\Projects\secondary-repository
```
Add it as an additional writable workspace root to an existing Codex task.

Let Codex execute the following through a normal sandboxed command:

git -C "D:\Projects\secondary-repository" init -b main
Copy-Item "D:\Projects\source\README.md" `
    "D:\Projects\secondary-repository\README.md"

The command initially succeeds.
Inspect ownership afterwards:
- workspace root: normal Windows user
- newly created .git tree: CodexSandboxOffline
- copied README.md: CodexSandboxOffline
Execute any subsequent sandboxed command.

The next sandbox refresh fails before the requested command starts:

deny ACE failed on D:\Projects\secondary-repository\.git:
SetNamedSecurityInfoW failed for D:\Projects\secondary-repository\.git: 5
setup refresh completed with errors
setup error: setup refresh had errors

A single affected additional write root then prevents commands from starting even when the current working directory is a different, healthy repository.

In this reproduction, multiple objects were owned by CodexSandboxOffline, including .git, its contents, and the copied README. The pre-existing workspace root remained owned by the normal user.

Recovery was possible only after fully closing Codex and running an owner-only repair from a separate elevated PowerShell:

icacls "D:\Projects\secondary-repository" `
    /setowner "DOMAIN\USERNAME" /T /C

No ACL reset, inheritance change, or DACL modification was required. After restarting Codex, the sandbox smoke tests succeeded again.

This was not caused by a Git or commit skill. The repository was initialized directly by a sandboxed git init command. The critical transition is creating a new repository or file inside an added write root under the sandbox identity.

Expected behavior:

Files and .git created through workspace-write should not be left owned by CodexSandboxOffline.
A newly created repository should remain usable by later sandbox refreshes.
One broken secondary write root should produce a precise path and ACL diagnostic instead of only helper_unknown_error.

Confirmed again on Codex Desktop for Windows, app package version 26.818.8289.0 (bundled command runner 0.149.0-alpha.4.3).

The local executor fails before creating even a read-only process:

helper_unknown_error: setup refresh had errors

The underlying sandbox log is explicit (workspace path redacted):

deny ACE failed on <WORKSPACE>\.codex: SetNamedSecurityInfoW failed: 5
setup refresh: processed 3 write roots (read roots delegated)
setup refresh completed with errors
setup error: setup refresh had errors

Filesystem inspection of the failing directory:

owner: CodexSandboxOffline
ACL inheritance: enabled
no explicit deny ACE present
not a junction or symlink
directory is empty
workspace root is owned by the normal Windows user

The failure repeats on every sandbox setup refresh. Running the same read-only command outside the broken sandbox succeeds, confirming that the command and workspace are otherwise accessible.

The user reports that this is not limited to the current release: the same class of failure has recurred across multiple Codex updates, and updating has not repaired the poisoned ownership state.

Manual Administrator-level takeown / icacls repair is not an acceptable product remediation. Codex created or retained the CodexSandboxOffline ownership state, so the sandbox setup must detect and recover from it itself. At minimum, setup should:

avoid leaving user project paths owned by a transient sandbox identity;
recover stale CodexSandboxOffline ownership safely during refresh;
show the exact failing ACL operation in the UI instead of the opaque helper_unknown_error;
provide a supported automatic repair path that does not require users to modify NTFS ACLs manually.

This currently makes Codex Desktop unable to run any local command in the affected workspace.

This bug is so annoying, and it has started happening all the time with 5.6 Luna. Please prioritize fixing it, because it's getting really difficult to work with 🙏

So, I canceled my Pro subscription to Codex today, no more ideas to accept such kind of quality in Win11, welcome back Claude :)

This issue is the only thing keeping me from subscribing to Codex.

Confirming on codex-cli 0.150.1 (Windows 11 10.0.26200), same class as
the Aug 25 .codex comment and the Aug 24 git init repro.

Deterministic trigger here:

Repo lives under a drive-root folder (C:\projects\<repo>), so it inherits
the default C:\ ACL (Authenticated Users:(M), no WRITE_DAC).
A sandboxed command creates .codex (New-Item .codex\tasks).
Owner becomes CodexSandboxOnline.
Every later refresh fails:

deny ACE failed on C:\projects<repo>.codex: SetNamedSecurityInfoW ... : 5
helper_unknown_error: setup refresh had errors

Control: scanned 44 repos under C:\projects. The only repo that never failed
already had an explicit <user>:(OI)(CI)(F) ACE on the project root, so .codex
inherited WRITE_DAC even when created by the sandbox account.

Workaround: icacls C:\projects /grant "*<SID>:(OI)(CI)(F)" plus recreate any
already-poisoned .codex as the host user. This should not be required of users.

I can reproduce a closely related failure on Windows and have a fairly clean elevated/unelevated A/B result.

Environment

Windows: 10.0.26200.9168 (x64)
Git: 2.55.0.windows.3
WSL: 2.7.12.0
Codex CLI installed separately: codex-cli 0.149.0
Codex Desktop bundled runner observed: codex-command-runner-0.150.0-alpha.12.2
Workspace: ordinary NTFS Git repository at D:\FlowTracer

Git/WSL/Docker and the repository itself all work normally outside Codex.

Symptom

With:

sandbox = "elevated"

Codex became unable to create any local process, including read-only commands such as git status.

The surfaced error was:

helper_unknown_error: setup refresh had errors

Remote GitHub access still worked.

Underlying sandbox error

The current sandbox log under %USERPROFILE%\.codex\.sandbox showed the actual failure while refreshing ACLs for the repository:

deny ACE failed on D:\FlowTracer\.git:
SetNamedSecurityInfoW failed for D:\FlowTracer\.git: 5

Windows error 5 is ERROR_ACCESS_DENIED.

ACL inspection then showed an unexpected ownership difference:

D:\FlowTracer
Owner: LAPTOP-M793R19O\liuj

D:\FlowTracer\.git
Owner: LAPTOP-M793R19O\CodexSandboxOffline

The user did not intentionally change the ownership of .git.

A/B test

I changed only:

sandbox = "elevated"

to:

sandbox = "unelevated"

and restarted Codex Desktop.

The same workspace immediately recovered:

git status — PASS
git branch --show-current — PASS
git log — PASS
local README.md read — PASS
local project docs read — PASS

No repository repair, ACL rewrite, takeown, Git reinstall, WSL reinstall, or Docker reinstall was performed between the failing and successful tests.

So on this machine the behavior is consistently:

elevated sandbox   -> setup refresh fails on .git ACL
unelevated sandbox -> local execution works

This makes me suspect that the elevated Windows sandbox can leave or encounter a stale ownership/ACL state involving CodexSandboxOffline, then fail a later ACL refresh when applying the deny ACE to .git.

One additional observation: earlier sandbox setup refreshes on the same machine had succeeded; the failure appeared later during normal Codex use. I have not yet identified the exact operation that first changed the .git owner, so that part remains a hypothesis rather than a confirmed reproduction-from-clean-state.

The unelevated sandbox is currently an effective workaround.

Confirmed workaround: switch Windows sandbox from `elevated` to `unelevated`

Adding the actual recovery procedure prominently in case it helps other Windows users hitting:

helper_unknown_error: setup refresh had errors

In my case the repository itself was healthy and Git worked normally from external PowerShell. The Codex sandbox log showed:

deny ACE failed on D:\FlowTracer\.git
SetNamedSecurityInfoW failed for D:\FlowTracer\.git: 5

and .git was unexpectedly owned by CodexSandboxOffline.

Workaround that restored Codex immediately:

Open:

%USERPROFILE%\.codex\config.toml

Change:

sandbox = "elevated"

to:

sandbox = "unelevated"

Completely restart Codex Desktop.

On the same machine/repository, before the change local process creation, git status, and local file reads all failed. After switching to unelevated, git status, git branch, git log, and local project file reads all passed immediately.

No Git/WSL/Docker reinstall, repository recreation, takeown, or recursive ACL reset was required.

For diagnostics before changing ACLs:

Get-Acl .git | Format-List Owner,AccessToString
icacls .git
Get-Content "$env:USERPROFILE\.codex\.sandbox\setup_error.json"
Get-Content "$env:USERPROFILE\.codex\.sandbox\sandbox.$(Get-Date -Format yyyy-MM-dd).log" -Tail 100

I would recommend trying the unelevated workaround before doing a recursive ownership/ACL rewrite, and preserving the logs/ACL state for diagnosis.

This is a workaround rather than a confirmed upstream fix: ideally the elevated Windows sandbox should recover from stale ACL/ownership state without preventing all local process creation.

I've had to integrate an intermittent check on file ownership to detect changes early because of this issue

Additional reproduction variant: stale owner SID after Windows reinstall

I can reproduce the same failure when a data/workspace drive is retained across a Windows reinstall.

Environment/details:

Windows desktop app
Native Windows sandbox: elevated
Workspace root: <WORKSPACE_ROOT>
The workspace root was retained from the previous Windows installation
Its NTFS owner was an old, unresolved SID and did not match the current Windows user's SID

The current sandbox log reported:

write ACE failed on <WORKSPACE_ROOT>: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors
setup error: setup refresh had errors

After this, even a trivial sandboxed command such as Get-Location failed before the target process started. The same directory was accessible from an elevated external PowerShell.

The owner-only repair was sufficient; no ACL reset or repository recreation was needed:

$account = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
icacls '<WORKSPACE_ROOT>' /setowner $account

After restarting Codex, the sandbox worked again.

This suggests a second recovery path for the same class of bug: a stale owner SID left by a Windows reinstall can prevent the elevated sandbox setup helper from writing the required ACE, while the UI only reports the opaque helper_unknown_error: setup refresh had errors.

The product should detect this condition and report the exact path and ownership/ACL failure, or provide a safe repair flow. A recursive ACL reset across an entire drive should not be required.

No personal account names, machine names, full SIDs, repository contents, or private log files are included here.

Ownership of a large part of the workspace was transferred to `CodexSandboxOffline`, and 65 directories were additionally left inaccessible to the interactive user

Same class as #17179, but the footprint is much larger and there are two distinct end states, only one of which is user-visible. The second state breaks tooling that has nothing to do with Codex, and cannot be detected from inside Codex.

Environment

Windows 11 家庭版 (Chinese), 10.0.26200, build 26200, x64
Config: sandbox_mode = "workspace-write", [windows] sandbox = "elevated"
Workspace: local NTFS, C:\Dev\Project\Python\cup_det, a normal directory created by the interactive user
Sandbox runtime in the evidence window:
- 2026-09-06 → codex-command-runner-0.153.4.exe, app bin dir %LOCALAPPDATA%\OpenAI\Codex\bin\8e5b6932251c2c1c
- 2026-09-15 → codex-command-runner-0.154.0-alpha.6.2.exe, app bin dir %LOCALAPPDATA%\OpenAI\Codex\bin\bffc5354119c8421
- the app's bin directory was written again on 2026-09-16, so the runtime may have moved on again after this excerpt
codex-cli 0.147.0 is also on PATH; that is a separate install, presumably unrelated
setup_marker.json: version 5, offline_username: CodexSandboxOffline, online_username: CodexSandboxOnline, created_at: 2026-07-16T05:58:12Z, read_roots: [], write_roots: [], allow_local_binding: false
deny_read_acl_state.json: {"principals": {}}

Note: the log directory contains one file per day (sandbox.YYYY-MM-DD.log), not a single sandbox.log.

Summary

After using Codex against this project, 4,885 directories are owned by CodexSandboxOffline, and 65 of them additionally carry a DACL with no entry for the interactive user, so non-elevated access is denied.

Ownership only (4,885 dirs): the owner is the sandbox account, but the DACL still lets the interactive user in. Reads and writes work, so this is completely silent.
Ownership + hardened DACL (65 dirs): there is no ACE for the interactive user at all.

State 2 is what surfaced the problem: a third-party Python tool doing a normal recursive walk over the project aborts with Access is denied. (os error 5).

The workspace root and `.git` are NOT affected

<MACHINE>\<USER>  = owner of  C:\Dev\Project\Python\cup_det
<MACHINE>\<USER>  = owner of  C:\Dev\Project\Python\cup_det\.git

So this is not the "workspace root / parent taken over" pattern from #29867. Git's dubious-ownership check passes and Git works fine. The mutation is entirely in subdirectories.

State 1: 4,885 directories owned by the sandbox account

Ownership scan (run elevated, so that directories that deny the user can also be inspected):

$root = "C:\Dev\Project\Python\cup_det"

$bad = Get-ChildItem -LiteralPath $root -Recurse -Force -Directory -ErrorAction SilentlyContinue |
  ForEach-Object {
    $p = $_.FullName
    try { if ((Get-Acl -LiteralPath $p -ErrorAction Stop).Owner -match 'CodexSandbox') { $p } } catch {}
  }

"count: $($bad.Count)"
$bad | Group-Object { Split-Path $_ -Parent } | Sort-Object Count -Descending |
  Select-Object -First 15 Count, Name

Result: count: 4885

Concentrations:

Count  Parent directory
  383  data\birdsai\real\train\annotations\tracking\data_split_perfect
  268  data\birdsai\real\train\annotations\tracking\data_split_full
  163  data\birdsai\real\test\annotations\tracking\data_split_perfect_test
   96  data\birdsai\real\test\annotations\tracking\data_split_full_test
   61  output\final\annotation\runtime\torch
   61  output\final\annotation\runtime
   41  output\final\annotation\runtime\sympy
   32  data\birdsai\real\train\images
   27  output\final\annotation\runtime\numpy\f2py\tests\src
   26  output\small_object_eval\map50_protocol\baseline
   24  output\final\annotation\runtime\cv2
   23  output\final\annotation\runtime\fontTools
   22  output\small_object_eval
   22  output\final\annotation\runtime\numpy
   22  output\final\annotation\runtime\scipy

A workspace-wide recursive pass is a much better fit for this scale than "a few directories got hit" (#29063).

State 2: 65 of them deny non-elevated access

All 65 sit under exactly three subtrees, and their names are a Python package set — torch, numpy, cv2, scipy, sympy, fontTools, matplotlib, contourpy, plus the matching *.dist-info directories:

output\birdsai\comparison_verification_deps\*
output\final\annotation\runtime\*
output\tool_dependencies\*

Access scan — must be run from a non-elevated shell, because elevation masks the failure (BUILTIN\Administrators has Full Control):

$root = "C:\Dev\Project\Python\cup_det"

$denied = @(
  Get-ChildItem -LiteralPath $root -Recurse -Force -Directory -ErrorAction SilentlyContinue |
    ForEach-Object {
      $p = $_.FullName
      try { Get-ChildItem -LiteralPath $p -Force -ErrorAction Stop | Out-Null }
      catch { $p }
    }
)

"count: $($denied.Count)"

Result: count: 65 — reproduced from a confirmed non-elevated shell (IsInRole(Administrator) = False).

The DACL on the access-denied directories

Example path output\tool_dependencies\yaml, owner <MACHINE>\CodexSandboxOffline, CreationTime 2026-09-06 22:17:23.

IdentityReference       FileSystemRights  IsInherited  AccessControlType
-----------------       ----------------  -----------  -----------------
OWNER RIGHTS            FullControl       False        Allow
NT AUTHORITY\SYSTEM     FullControl       False        Allow
BUILTIN\Administrators  FullControl       False        Allow

Every ACE is explicit (IsInherited = False), consistent with a protected DACL that no longer receives entries from its parent. There is no ACE for the interactive user, and the interactive user is not the owner — so the only way in is elevation, via BUILTIN\Administrators.

The OWNER RIGHTS (S-1-3-4) entry is unusual to see persisted in a filesystem DACL and looks like a deliberately constructed security descriptor rather than an incidental side effect. Note that with the owner set to the sandbox account, an OWNER RIGHTS ACE grants full control to the sandbox account, not to the user.

Timeline: the directories were created in the same second as a sandboxed command

Directories left owned by CodexSandboxOffline report CreationTime 2026-09-06 22:17:23 (sample: output\tool_dependencies\yaml)
In sandbox.2026-09-06.log, sandboxed commands start every ~12 s in that window; two of them start at 22:17:21.288 and 22:17:23.639:

[2026-09-06 22:17:21.288 codex.exe] START: ...\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
& 'C:/
[2026-09-06 22:17:23.639 codex.exe] START: ...\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
& 'C:/

The last setup refresh with the workspace as cwd before that ran at 22:16:43.007, and the next one at 22:17:38.073:

[2026-09-06 22:16:43.007 codex.exe] setup refresh: spawning ...\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06 22:17:38.073 codex.exe] setup refresh: spawning ...\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)

Combined with the fact that all 65 inaccessible directories are pip-style package directories (<pkg>\ plus <pkg>-<version>.dist-info\), the shape of it is: a sandboxed command invoked from C:/... (see the START lines), installing or unpacking a Python environment under output\, and the directories it created came out owned by the sandbox account — 65 of them with a DACL that excludes the interactive user.

The full command lines follow the START lines in the log; I can attach sandbox.2026-09-06.log if that helps.

Additional observation (may deserve its own issue): persistent `read ACL run had errors`

setup_error.json has read read ACL run had errors continuously (last written 2026-09-15 15:25:48). The failing operation is not on the workspace:

[2026-09-06T14:24:17.655Z] read-acl-only mode: applying read ACLs
[2026-09-06T14:24:17.660Z] granting read ACE to C:\Users\<USER>\PCManger for sandbox users
[2026-09-06T14:24:17.660Z] grant read ACE failed on C:\Users\<USER>\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06T14:24:17.660Z] read ACL run completed with errors: ["grant read ACE failed on C:\\Users\\<USER>\\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5"]
[2026-09-06T14:24:17.660Z] setup error: read ACL run had errors

Byte-identical lines appear nine days later on 2026-09-15, on every setup refresh. In the same refresh, the write-root work succeeds:

[2026-09-06 22:24:17.579 codex.exe] setup refresh: spawning ...\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:24:17.630Z] setup refresh: processed 3 write roots (read roots delegated); errors=[]

C:\Users\<USER>\PCManger is where the helper cannot set a security descriptor:

Attributes    : Directory      (not a reparse point, not a symlink, no target)
CreationTime  : 2026-07-14 22:32:55      (predates sandbox provisioning on 2026-07-16)
Owner         : BUILTIN\Administrators

Everyone:(R)
Everyone:(OI)(CI)(IO)(GR)
BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)

There is no ACE for the interactive user, and the user is not the owner, so a non-elevated process has read-only access and no WRITE_DAC. This is the mechanism described in #31620. It appears to be a separate problem from the ownership mutation above — I am including it only because it is reproducible on this machine and it shows the setup helper running with the user's filtered (non-elevated) token for this pass.

On 0.154.0-alpha.6.2 this read-ACL failure appears to be non-fatal — 0.3 s later the log shows the shell starting anyway (START: ...\pwsh.exe), and the harness stays usable. Reporting it as persistent degraded state, not a hard failure.

Also logged on every refresh (possibly #35737, mentioned only for completeness):

[codex-command-runner-0.154.0-alpha.6.2.exe] hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default: 5

Minor, separate: log lines embed the localized OS message, and on this Chinese-locale system it is written as mojibake (鎷掔粷璁块棶銆? for 拒绝访问。), i.e. GBK bytes decoded as UTF-8.

Impact outside Codex

A third-party Python-based export/migration tool performs a normal recursive walk over the project and aborts with:

Access is denied. (os error 5)

A user has essentially no chance of connecting this to Codex:

the workspace root and .git look completely normal (owner is the user, Git works),
Codex itself reports nothing,
the damage only shows up when some other tool walks the tree.

The user-visible symptom is "an unrelated tool fails on my project", not "Codex broke something".

Repair

Minimal repair, from an elevated shell, with Codex and any host IDE fully closed:

$root = "C:\Dev\Project\Python\cup_det"
$me   = "$env:COMPUTERNAME\$env:USERNAME"

takeown /F "$root" /R /D Y

# only the 65 directories that deny access
Get-Content "$env:USERPROFILE\Desktop\codex-acl-evidence\03-access-denied-dirs.txt" |
  ForEach-Object { icacls "$_" /grant "${me}:(OI)(CI)F" /C }

The broader workaround from #17179 (reset ownership, then re-enable inheritance across the tree) also works but is more invasive.

What I could not determine

Whether the sandbox created these directories under its own identity, or took ownership of pre-existing ones. The data\...\tracking\* subtrees were populated from a Linux server via an IDE sync, which would normally write them as the interactive user.
I have not scanned files — both scans above were -Directory only. The file-level footprint is unknown and may be larger.
I do not have a minimal repro, only the resulting state. I can attach the full directory lists, the ACL dump for all 65 paths, and sandbox.2026-09-06.log / sandbox.2026-09-15.log on request.

Question for maintainers

Is OWNER RIGHTS + NT AUTHORITY\SYSTEM + BUILTIN\Administrators, all-explicit, something codex-windows-sandbox-setup.exe writes deliberately? And does the setup path intend to change ownership at all, or only to add ACEs?
The read-ACL pass demonstrably runs without WRITE_DAC on paths the user does not own (the PCManger case), which suggests it runs with the user's filtered token. How does the same component end up setting the owner to CodexSandboxOffline? The ownership change is what makes this unrecoverable without an elevated repair, since the user stops being the owner and icacls from a normal shell returns Access is denied.

Windows workspace-write sandbox can change project ownership to CodexSandboxOffline and cause persistent write failures #17179 (ownership changed to CodexSandboxOffline)
Windows sandbox can leave workspace owned by CodexSandboxOnline, then setup refresh fails with SetNamedSecurityInfoW 5 #29867 (workspace root / parent taken over)
Codex Desktop Windows sandbox setup fails on NTFS ACL / SetNamedSecurityInfoW error 5, then agents fall back to unsandboxed PowerShell escalation #31620 (SetNamedSecurityInfoW failed: 5 on paths owned by BUILTIN\Administrators)
Windows: .git owned by CodexSandboxOffline causes Codex project detection and Git clients to reject repository #37965 (.git variant, breaks Git)
Windows sandbox ACL setup sets the Archive attribute on every workspace file #29063 (recursive metadata mutation workspace-wide)
Windows desktop 26.730.8199.0: Stop/network interruption leaves task stuck as codexsandboxoffline #37187 (read ACL run had errors)
Add managed policy option to disable Windows sandbox ACL/DACL mutation #29415 (feature request: policy to disable Windows sandbox ACL/DACL mutation)

02-timestamps.csv
03-access-denied-dirs.txt
04-acls-of-denied.txt
01-owners-CodexSandbox.txt

Follow-up: when the sandbox-owned directories were created

CreationTime distribution across all 4,885 sandbox-owned directories, top 20 minutes:

  1095  2026-09-14 16:42
   911  2026-09-14 16:41
   773  2026-08-22 21:09
   663  2026-09-09 18:59
   302  2026-08-26 04:06
   280  2021-09-22 00:30
   249  2026-09-06 22:17
   122  2026-08-23 18:09
   120  2026-08-26 04:35
    95  2026-09-14 16:40
    50  2026-08-22 22:53
    39  2026-09-06 22:18
    29  2026-09-15 14:32
    25  2026-09-09 19:00
    11  2026-08-22 21:10
     9  2026-09-15 14:35
     7  2026-08-29 02:41
     7  2026-09-15 14:57
     6  2026-09-09 19:49
     6  2026-09-09 18:51

Earliest: 2021/9/22 0:30:52

Latest: 2026/9/15 14:58:00

On 2026-09-06, grouped by second:

    70  22:17:45
    39  22:17:52
    35  22:18:00
    33  22:17:51
    27  22:17:59
    10  22:17:46
     9  22:17:53
     9  22:17:58
     8  22:17:40
     7  22:17:42
     7  22:17:23
     5  22:17:49
     5  22:17:56
     4  22:17:55
     4  22:17:44
     4  22:17:48
     3  22:18:01
     3  22:17:24
     2  22:17:41
     2  22:17:50

The sandboxed commands running in that window. The START line is wrapped in the log, so the following lines are the rest of the command line:

[2026-09-06 22:16:41.054 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:16:41.139 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:16:41.190197900+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:41.190 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:41.217034500+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:41.222474500+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:16:41.222552+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:16:41.432 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:16:41.519 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:16:41.569193900+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:41.569 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:41.593138900+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:41.598364200+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:16:41.598450400+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:16:41.816 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:16:41.899 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:16:41.949397100+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:41.949 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:41.972639900+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:41.978258600+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:16:41.978376900+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:16:42.183 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:16:42.265 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:16:42.324022100+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:42.324 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:42.354315+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:42.360003+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:16:42.360130+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:16:42.577 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:16:42.654 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:16:42.703613700+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:42.703 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:42.727476500+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:42.733828100+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:16:42.733918100+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:16:42.929 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:16:43.007 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:16:43.055231700+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:43.055 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:43.083570800+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:43.089546900+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:16:43.089718200+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:16:57.587 codex.exe] START: C:\Users\lurenjia\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
Get-Co
[2026-09-06 22:16:57.669 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c, payload_len=3944)
[2026-09-06T14:16:57.722768400+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:16:57.722 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:16:57.751297200+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:16:57.756349800+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06 22:17:09.703 codex.exe] START: C:\Users\lurenjia\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
& 'C:/
[2026-09-06 22:17:09.778 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c, payload_len=3944)
[2026-09-06T14:17:09.835916+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:09.835 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:09.864003900+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:09.868913900+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06 22:17:21.288 codex.exe] START: C:\Users\lurenjia\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
& 'C:/
[2026-09-06 22:17:21.357 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c, payload_len=3944)
[2026-09-06T14:17:21.409355200+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:21.409 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:21.438364100+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:21.443695+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06 22:17:23.639 codex.exe] START: C:\Users\lurenjia\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
& 'C:/
[2026-09-06 22:17:23.710 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c, payload_len=3944)
[2026-09-06T14:17:23.767581200+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:23.767 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:23.795139500+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:23.800045400+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06 22:17:37.987 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:17:38.073 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:17:38.123599300+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:38.123 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:38.147598100+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:38.153707400+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:17:38.153802+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:17:38.367 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:17:38.458 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:17:38.509998900+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:38.510 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:38.533108900+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:38.538340700+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:17:38.538444100+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:17:38.757 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:17:38.828 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:17:38.875577900+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:38.875 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:38.899071100+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:38.903876700+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:17:38.903969200+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:17:39.094 codex.exe] START: C:\Users\lurenjia\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-09-06 22:17:39.169 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Dev\Project\Python\cup_det, payload_len=3944)
[2026-09-06T14:17:39.217462800+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:39.217 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:39.242316+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:39.246992200+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users
[2026-09-06T14:17:39.247091+00:00] grant read ACE failed on C:\Users\lurenjia\PCManger for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-06 22:17:39.409 codex.exe] START: C:\Users\lurenjia\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
$env:P
[2026-09-06 22:17:39.473 codex.exe] setup refresh: spawning C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c\codex-windows-sandbox-setup.exe (cwd=C:\Users\lurenjia\AppData\Local\OpenAI\Codex\bin\8e5b6932251c2c1c, payload_len=3944)
[2026-09-06T14:17:39.526951+00:00] setup refresh: processed 3 write roots (read roots delegated); errors=[]
[2026-09-06 22:17:39.526 codex-windows-sandbox-setup.exe] setup binary completed
[2026-09-06T14:17:39.555529300+00:00] read-acl-only mode: applying read ACLs
[2026-09-06T14:17:39.561138600+00:00] granting read ACE to C:\Users\lurenjia\PCManger for sandbox users

Additional reproduction + a narrower recovery method that did not require recursively taking ownership of the whole repository.

Environment

Windows 10/11, native Codex Desktop
Codex Desktop build: 26.928.31416
Bundled backend / fs-helper: codex-cli 0.159.2
PowerShell 7.6.6
Local NTFS repository inside a Google Drive-synced folder
Normal workspace-write sandbox; no "retry without sandbox"

Symptom

Built-in apply_patch worked on a file in the repository root, but failed on an ordinary file under an existing tests\ directory:

Failed to read file to update ...\tests\<file>:
path contains a reparse point

Windows reported that neither the directory nor the file was a reparse point:

fsutil reparsepoint query ...\tests
Error: The file or directory is not a reparse point.

The exact same file was readable and writable from Codex's sandbox shell:

Get-Content .\tests\.codex-native-probe.txt   # PASS
Set-Content .\tests\.codex-native-probe.txt -Value "AFTER-SHELL"  # PASS
Get-Content .\tests\.codex-native-probe.txt   # PASS

So the failure was specific to the built-in patch/fs-helper path, not a general inability of the sandbox to read/write the file.

Filesystem difference found

The old physical tests\ directory was owned by:

<machine>\CodexSandboxOffline

A freshly-created sibling directory was owned by the normal interactive user and inherited the current Codex capability ACL entries from the repository root.

Fresh nested directory test:

create codex-clean-probe\probe.txt
built-in apply_patch -> PASS

Old tests\:

built-in apply_patch -> FAIL with false reparse-point error

Non-destructive recovery that worked

I created a fresh sibling directory and copied only file data/attributes/timestamps, deliberately excluding Windows security metadata:

robocopy tests tests2 /E /COPY:DAT /DCOPY:DAT /R:0 /W:0

Before swapping directories I compared every file by:

relative path
length
SHA-256

Result: all files were identical.

Then:

Confirmed built-in apply_patch works inside tests2\.
Moved the old physical tests\ outside the repository as a rollback backup.
Renamed tests2\ -> tests\.
Repeated the SHA-256 comparison against the backup: identical.
Confirmed git status showed no tracked-content changes.
Tested built-in apply_patch under the new tests\: PASS.
Fully restarted Codex Desktop and repeated the patch test: PASS again.

The new tests\ owner is the normal user, and it has the current inherited Codex capability ACL entries.

Conclusion / limitation

This strongly suggests that persistent historical Windows sandbox security state on the physical directory object can poison apply_patch, and recreating that directory without copying its security descriptor can recover it.

This test does not isolate which individual element was decisive: the CodexSandboxOffline owner, stale/missing capability ACEs, or their combination. Recreating the directory changed those together.

The reported path contains a reparse point diagnostic was definitely false in this reproduction.

Related: #46213 and #46290.

Windows workspace-write sandbox can change project ownership to CodexSandboxOffline and cause persistent write failures #17179

Description

What version of the IDE extension are you using?

What subscription do you have?

Which IDE are you using?

What platform is your computer?

What issue are you seeing?

Title

Summary

Environment

Config

What happened

Initial symptoms

Important behavior difference

IDE switching did not fix it

Restarting did not fix it

Sandbox log evidence

ACL / ownership inspection

Scope of corruption

Repair attempt

Strong suspicion

Expected behavior

Actual behavior

Suggested areas to investigate

Minimal repro shape

End result

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 9, 2026

mickitty0511 commented on Apr 22, 2026

floxrot commented on Aug 24, 2026

alexanderfedyunin-bit commented on Aug 25, 2026

D1sconnected commented on Aug 27, 2026

alexanderfedyunin-bit commented on Aug 27, 2026

qubiq1337 commented on Aug 27, 2026

xbzhang1994 commented on Aug 28, 2026

lucaschang2021 commented on Aug 29, 2026

Environment

Symptom

Underlying sandbox error

A/B test

lucaschang2021 commented on Aug 29, 2026

Confirmed workaround: switch Windows sandbox from elevated to unelevated

jdr377 commented on Aug 31, 2026

deretame commented on Sep 6, 2026

Additional reproduction variant: stale owner SID after Windows reinstall

lurenjia2003lrj commented on Sep 16, 2026

Ownership of a large part of the workspace was transferred to CodexSandboxOffline, and 65 directories were additionally left inaccessible to the interactive user

Environment

Summary

The workspace root and .git are NOT affected

State 1: 4,885 directories owned by the sandbox account

State 2: 65 of them deny non-elevated access

The DACL on the access-denied directories

Timeline: the directories were created in the same second as a sandboxed command

Additional observation (may deserve its own issue): persistent read ACL run had errors

Impact outside Codex

Repair

What I could not determine

Question for maintainers

Related

lurenjia2003lrj commented on Sep 16, 2026

Follow-up: when the sandbox-owned directories were created

dariokraljevic-design commented on Oct 1, 2026

Environment

Symptom

Filesystem difference found

Non-destructive recovery that worked

Conclusion / limitation

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Confirmed workaround: switch Windows sandbox from `elevated` to `unelevated`

Ownership of a large part of the workspace was transferred to `CodexSandboxOffline`, and 65 directories were additionally left inaccessible to the interactive user

The workspace root and `.git` are NOT affected

Additional observation (may deserve its own issue): persistent `read ACL run had errors`