I’m using the Codex desktop on Windows 10, version 26.818.61809.
I’m using Codex to program an Unreal Engine 5.8.1 application and using GitHub.
As of today, Codex is failing to edit local files due to the following restriction: “Use apply_patch for local file edits. Do not create or edit files with cat or other shell write tricks.”
Codex informed me that this is a developer instruction, and not something I can change. This higher-priority instruction is why Codex “did not substitute PowerShell Set-Content, redirection, or similar direct-write workarounds.”
The patch tool returns the following error: “Failed to write file B:\XXX\YYY\Docs\Milestones\R44\”
Codex made the following findings:
Docs, Docs/Milestones, and Docs/Milestones/R44 are ordinary directories—not reparse points or symlinks.Their ACLs grant Modify access to the Codex sandbox user; the target files are not read-only.
The worktree is valid and located at B:\XXX\YYY.
No Git command, GitHub operation, staging operation, or remote access occurs before the failure.
Existing Docs files can be patched, proving it is specifically new-file creation beneath Docs/ .
Temporary diagnostic changes were fully removed; no tracked repository changes remain from testing.
The strongest lead is a sandbox-ownership inconsistency: Docs and Docs/Milestones are owned by PC\CodexSandboxOffline , while the repository root and Source are owned by PC\<user>. Although their ACLs look writable, the patch layer appears to apply an additional owner/path policy when creating files. That is an inference, but it exactly matches the observed boundary.
Codex tested an all-patch create-then-move approach, but the patch layer falsely rejected the move as involving a reparse point.
Version/process evidence:
Desktop app package: OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0
Sandbox command runner: codex-command-runner-0.149.0-alpha.4.3
Codex/ChatGPT desktop processes were active during testing.
EricGT
August 25, 2026, 2:47pm
2
Welcome to the forum!
You are welcome to discuss Codex issues here. However, the official place to report and track them is the OpenAI Codex GitHub issue tracker .
I asked ChatGPT to look for the closest related issue, and it identified:
opened 01:53AM - 09 Apr 26 UTC
bug
windows-os
sandbox
### 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:
```toml
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:
```text
windows sandbox: setup refresh failed with status exit code: 1
```
When Codex tried a direct PowerShell rewrite of the same file, it failed with:
```text
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:
```text
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`):
```text
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:
```text
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:
```powershell
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:
```powershell
takeown /F "<PROJECT_ROOT>" /R /D Y
icacls "<PROJECT_ROOT>" /setowner "<MACHINE>\<USER>" /T /C
icacls "<PROJECT_ROOT>" /inheritance:e /T /C
If that issue matches your problem, consider adding a
If it does not describe the same problem, search the existing Codex issues for a closer match. If you cannot find one, open a new issue and include as much relevant detail as possible.
This resolved my issue. Thank you!
reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.