codex - 💡(How to fix) Fix Windows workspace-write sandbox can change project ownership to CodexSandboxOffline and cause persistent write failures [1 comments, 2 participants]

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:

1. Codex sandbox touched project ACLs / ownership during a degraded or interrupted state
2. ownership on some paths was left as CodexSandboxOffline
3. later sandbox setup attempts could no longer repair those paths
4. 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:

1. Use Codex on Windows with workspace-write
2. Successfully edit files in a project for a while
3. Experience an interruption such as network drop and/or IDE update / restart during the same general period
4. Later attempt an edit in the same project
5. Observe sandbox refresh failure and Access denied
6. 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