Windows: Codex-created .agents ownership breaks sandbox setup and in-app browser control

What version of the Codex App are you using?

Codex Desktop on Windows, observed September 8, 2026. Bundled runtime verified with codex.exe --version: codex-cli 0.153.4. The separate desktop About-dialog version was not captured.

What subscription do you have?

Pro; this report concerns a local Windows filesystem/sandbox failure.

What platform is your computer?

Windows 10 Pro 22H2, build 19045.7663, x64. Local project on M:. Configuration: sandbox_mode = "workspace-write" and [windows] sandbox = "elevated".

What issue are you seeing?

After Codex created a project's .agents directory while adding a project-local skill, subsequent local commands and in-app browser control failed during sandbox initialization. The user had not manually created the directory or changed its ownership.

The directory was owned by <MACHINE>\CodexSandboxOffline, while the parent project directory was owned by the interactive Windows user. Both directories were ordinary directories, not reparse points. The child inherited its access rules and the normal user's broad group access was Modify, rather than permission to change the ACL.

Sanitized sandbox log:

deny ACE failed on M:\Codex\<PROJECT>\.agents:
SetNamedSecurityInfoW failed for M:\Codex\<PROJECT>\.agents: 5
setup refresh completed with errors
setup error: setup refresh had errors

Local command error:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

Browser tool error from cua.getState():

trusted Node process exited unexpectedly; kernel reset, rerun your request

The user could manually use the in-app browser tabs, but the agent could not even enumerate them. Repeated tool calls and a browser-kernel reset reproduced the failure.

What steps can reproduce the bug?

This is the observed incident sequence, not a separate clean-room reproduction:

A user-owned Windows project was working with the elevated sandbox.
Codex used its file-editing workflow to add project-local skill files beneath a new .agents directory.
The directory's creation time was 2026-09-08 00:49:43 PDT. Sandbox setup was still succeeding immediately before creation.
At 00:49:51 PDT, the next local command failed while applying a deny ACE to that directory.
Later attempts from a task in the same project failed for both local commands and browser initialization.
Inspection found the ownership mismatch described above.

What is the expected behavior?

Creating a supported project-local skill through Codex should leave the project usable. The creation/setup workflow should handle ownership and protected-directory ACLs consistently.

If setup cannot apply an ACL, the agent-facing error should identify the affected path and Windows error. Browser control should expose the underlying setup failure rather than only a generic Node-process crash.

Users should not have to anticipate which folders Codex will create, pre-create them manually, or diagnose NTFS ownership.

Additional information

A narrowly scoped repair was verified:

Backed up the affected directory's security descriptor.
With Windows administrator approval, changed only the .agents directory's owner to the interactive user using icacls <directory> /setowner <interactive-user>, without recursion.
Did not reset the directory's ACL, grant Everyone access, disable the sandbox, change firewall rules, or delete/recreate the directory.
On the next attempt, Codex successfully applied its deny ACEs and sandbox setup reported errors=[].
In the original affected task, a local README read completed with exit code 0 and cua.getState() successfully enumerated both existing in-app browser tabs on the first attempt. No app restart or kernel reset was needed after the ownership repair.

This strongly points to an ownership/ACL setup interaction triggered by Codex's own directory creation. The exact internal code defect has not been isolated.

Related reports: #31414 concerns a different folder-owner case; #39933 describes the generic setup-refresh failure. This report adds the agent-created .agents trigger, correlated browser-control failure, and verified single-directory ownership repair.

The assistant initially recommended restarting, then suggested that the user manually pre-create the folders. That guidance misplaced the prevention burden: Codex created the directory. Please address both the setup behavior and the diagnostic guidance.

Project names, personal account/machine names, browser destinations, and full transcripts are omitted.

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

[CRITICAL][Windows] Recurring helper setup failures block both browser control and local execution #43721
Windows Codex Desktop 26.901.31953: local command runner fails with helper_unknown_error #42905
windows sandbox failed: helper_unknown_error: setup refresh had errors #43416

Powered by Codex Action

Reviewed #43721, #42905, and #43416, including their current follow-up comments. They report similar symptoms, but none establishes that this is the same underlying defect. Keeping #43776 open pending maintainer confirmation of a shared root cause. If these belong under one tracking issue, please indicate which one so the existing evidence can be consolidated.

I reproduced the same ownership / ACL bootstrap failure independently on Codex Desktop for Windows, but with two additional directory types: .git and .codex.

Environment

Codex Desktop: 26.901.6511.0
Bundled runtime: codex-cli 0.153.4
ChatGPT Plus
Windows x64

Case 1 — .git

Codex ran git init inside a normal user-owned project directory. The newly created .git directory was owned by CodexSandboxOffline.

On the next sandbox refresh, the helper attempted to add the protective deny ACE to .git and failed with:

SetNamedSecurityInfoW failed: 5

After that, even Get-Location failed before process creation with:

helper_unknown_error: setup refresh had errors

I changed only the owner of the .git root directory from CodexSandboxOffline back to the interactive Windows user. I did not reset the DACL, change inheritance, or modify permissions recursively.

Immediately afterwards:

sandbox refresh reported errors=[]
Codex successfully installed its expected explicit deny ACEs on .git
Get-Location succeeded with exit code 0

Case 2 — .codex

In a different, initially healthy repository, Codex attempted to create a project-level .codex directory. The new directory was again owned by CodexSandboxOffline.

The next sandbox refresh failed while attempting to provision that directory:

write ACE grant failed on D:\repo.codex: SetNamedSecurityInfoW failed: 5

Subsequent attempts also failed while applying deny ACEs, and command execution became unavailable.

Inspecting the directory confirmed:

Owner = \CodexSandboxOffline

Pre-creating .codex / .codex\agents as the normal interactive user avoids this ownership condition.

This suggests the problem is broader than .agents: directories created by the Codex sandbox that later become sandbox provisioning/protected roots can be left owned by CodexSandboxOffline, causing the next ACL refresh to deadlock itself.

I also found the same .git failure pattern in local sandbox logs from an earlier runtime (0.150.0-alpha.8), so this does not appear to be unique to 0.153.4.

Independent confirmation of the same .agents ownership / ACL bootstrap failure, on a newer runtime.

Environment:

Windows 10 Home 22H2, build 19045.6466, AMD64
Codex CLI: 0.155.0-alpha.2.6
Computer Use bundle: 26.911.61220
Node: v24.19.0
PowerShell: 7.6.5
Local NTFS workspace on D:

In the affected workspace, .agents was owned by:

<MACHINE>\CodexSandboxOffline

while the normal interactive Windows user was the expected owner.

Sandbox initialization repeatedly failed with:

deny ACE failed on <WORKSPACE>\.agents:
SetNamedSecurityInfoW failed for <WORKSPACE>\.agents: 5

setup refresh completed with errors
setup error: setup refresh had errors

This blocked all of the following before normal execution could begin:

default sandbox shell
Node REPL
Computer Use / @oai/sky
cua.getState()
Chrome extension control

A clean workspace created by the normal Windows user did not reproduce the problem.

I repaired only the owner of the .agents directory itself:

CodexSandboxOffline -> <interactive Windows user>

The operation was non-recursive. I did not reset the ACL, inheritance, ACEs, Defender, firewall, registry, sandbox mode, or credentials.

I captured the security descriptor immediately before and after the ownership change. DACL bytes, SACL/audit state, group, and non-owner control flags were unchanged.

On the next sandbox setup:

applied deny ACE to protect <WORKSPACE>\.agents
setup refresh: processed 3 write roots (read roots delegated); errors=[]

Afterwards, all previously affected surfaces passed in the original workspace:

sandbox shell
Node REPL
@oai/sky
cua.getState()
Chrome control
Chrome extension screenshot capture
click/navigation readback

So this independently confirms that restoring ownership of the affected metadata directory alone can recover the sandbox without broad ACL resets or weakening sandbox/security settings.

I still cannot determine what originally changed .agents ownership to CodexSandboxOffline, so I would treat that causal step as unresolved.

I may be seeing a related variant where the repository root, rather than only .agents, was owned by CodexSandboxOffline.

Environment

Codex Desktop: 26.915.31945
Windows 11 25H2
Git: 2.51.0.windows.1
Local NTFS repository
Interactive user: <MACHINE>\amosl

Symptoms

All Codex tasks created under this project fail before any command starts. Tasks associated with other projects continue to work.

Commands fail with:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

This applies even to a command that does not use Git:

Write-Output SHELL_OK

The Codex terminal is never created. Restarting the affected task did not resolve the failure.

Ownership evidence

Before I corrected the ownership, Git reported:

fatal: detected dubious ownership in repository at '<PROJECT>'
'<PROJECT>' is owned by:
    <MACHINE>/CodexSandboxOffline
but the current user is:
    <MACHINE>/amosl

The repository was therefore owned by the Codex sandbox account while Git was running as my interactive Windows account.

I added the repository to my user-level Git safe.directory configuration:

file:C:/Users/<USER>/.gitconfig  <PROJECT>

This removed the immediate Git ownership warning for my interactive account, but it did not restore command execution in Codex.

I subsequently corrected the repository root owner to my interactive account. The current ACL reports:

Owner: <MACHINE>\amosl

The ACL also contains entries granting access to CodexSandboxUsers, the interactive user, Administrators, SYSTEM, Users, and Authenticated Users.

Correcting the repository root ownership did not restore the shell in the existing affected task. Codex still reports:

helper_unknown_error: setup refresh had errors

Previous occurrence

I have encountered similar project-wide failure before. At that time, deleting the entire local directory and cloning the repository again restored Codex operation. This suggests that filesystem ownership or ACL state persisted somewhere inside the project and continued to break sandbox setup.

Difference from this report

The original report identifies a Codex-owned .agents directory inside an otherwise user-owned project. In my case, Git initially identified the repository root itself as owned by CodexSandboxOffline.

The root owner has now been corrected, but the setup failure remains. A child path may still have mismatched ownership or an ACL that the sandbox setup cannot modify.

Expected behaviour

Codex should not leave project files or directories owned by CodexSandboxOffline in a state that prevents future sandbox initialisation.

If sandbox setup cannot modify an ACL, the error should report:

the affected path;
the attempted ACL operation;
the Windows error code;
the current owner;
the required remediation.

The current setup refresh had errors message does not identify which path caused the failure, so it is difficult to distinguish a repository ownership problem from a protected child directory or another sandbox initialisation error.

I can provide sanitised recursive ownership results or perform targeted checks if that would help isolate the affected path.

Independent confirmation of the existing .git ownership / ACL bootstrap failure on a newer Windows Codex build.

Environment: Windows 11 Pro, build 26200; Codex Desktop 26.915.4065.0; bundled codex-cli 0.155.0-alpha.9.2; elevated Windows sandbox with workspace-write.

All local shell/file operations in an existing user-owned repository failed before command execution with helper_unknown_error: setup refresh had errors. codex doctor --json reported sandbox.helpers: fail and helper_unknown_error. A fresh sandbox log showed the more specific repeated error:

deny ACE failed on <WORKSPACE>\.git: open deny ACL target for update
setup refresh completed with errors
setup error: setup refresh had errors

The repository root was owned by the interactive Windows user. Only the .git directory root was owned by <MACHINE>\CodexSandboxOffline. It was an ordinary directory with inherited ACLs; the interactive user had inherited Modify access but was not the owner. Running codex sandbox setup --elevated --current-user from an elevated terminal completed, but the next task refresh still failed on .git.

The user then changed only the owner of the .git directory root to their interactive account. No recursive ownership change, ACL reset, sandbox disablement, or repository reclone was needed. In the same affected task, Get-Location, git status, and git rev-parse HEAD origin/main then succeeded; the repository was clean.

I cannot establish when or why .git acquired CodexSandboxOffline ownership. This confirms the reported failure and narrow recovery path on codex-cli 0.155.0-alpha.9.2. The agent-facing error still concealed the target path; only the rotated sandbox log identified it.

Follow-up: I reproduced the same setup-refresh failure in a different Windows workspace, with a project-local .codex directory as the failing path.

Environment: Codex Desktop on Windows, bundled runtime/codex-cli 0.155.0-alpha.9.2, workspace-write, local workspace on the E: drive (exact path omitted).

The parent task attempted to read a local SKILL.md, but the command never reached PowerShell:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

Sanitized sandbox log:

deny ACE failed on .codex: open deny ACL target for update
setup refresh completed with errors: ["deny ACE failed on .codex: open deny ACL target for update"]
setup error: setup refresh had errors

Read-only inspection showed that the workspace root and .codex had different owners: the child was owned by CodexSandboxOffline, while CodexSandboxUsers had Modify access. No ACL or ownership changes were made.

This confirms that the failure is in Windows sandbox ACL setup, not in the command text or the Hugging Face skill. Full logs and local identifiers are omitted; sanitized evidence is available privately if needed.

Controlled clean-room reproduction on a newer runtime confirms the causal creation step for both .git and .codex.

Environment

Windows x64, native elevated sandbox
sandbox_mode = "workspace-write"
codex-cli 0.156.1

Minimal reproduction

Start with an empty directory owned by the interactive Windows user. The first sandbox invocation succeeds because the protected paths do not exist yet, then creates them as the sandbox identity:

codex sandbox `
  -c 'windows.sandbox="elevated"' `
  -c 'sandbox_mode="workspace-write"' `
  -c 'project_root_markers=[]' `
  -- powershell -NoProfile -Command `
  "New-Item -ItemType Directory -Path .git,.codex -Force | Out-Null; whoami"

Observed identity:

<MACHINE>\codexsandboxoffline

Ownership immediately afterward:

<REPRO-ROOT>          OWNER=<MACHINE>\<interactive-user>
<REPRO-ROOT>\.git    OWNER=<MACHINE>\CodexSandboxOffline
<REPRO-ROOT>\.codex  OWNER=<MACHINE>\CodexSandboxOffline

Run a second elevated workspace-write sandbox invocation from the same directory:

codex sandbox `
  -c 'windows.sandbox="elevated"' `
  -c 'sandbox_mode="workspace-write"' `
  -c 'project_root_markers=[]' `
  -- powershell -NoProfile -Command "Get-Location"

The second invocation fails before PowerShell starts:

windows sandbox failed: helper_unknown_error: setup refresh had errors

The sandbox log records the same failure for both newly created protected paths:

deny ACE failed on <REPRO-ROOT>\.codex: open deny ACL target for update
deny ACE failed on <REPRO-ROOT>\.git: open deny ACL target for update
setup refresh completed with errors
setup error: setup refresh had errors

Controls

An empty user-owned root succeeds.
User-owned .git and .codex directories succeed and receive the expected protective deny ACEs.
Copies with the same .git / .codex contents but interactive-user ownership succeed.
The failure appears only after the protected directories are created by the elevated sandbox and therefore owned by CodexSandboxOffline.
Changing only the owner of the affected directory roots back to the interactive user is the narrow recovery; recursive ACL reset is not required.

This closes the previously unresolved causal step: the sandbox can create a path that the next sandbox refresh classifies as protected, but refresh cannot reopen that sandbox-owned path to apply the deny ACE. The setup operation is therefore not idempotent across this valid state transition.

The documented protected-path set includes .git, .codex, and .agents: https://learn.chatgpt.com/docs/agent-approvals-security#protected-paths-in-writable-roots

Adding another observed creation path and verified recovery from one Windows machine.

Recovery environment, September 30: Codex Desktop 26.928.21956 (build 12404), CLI 0.159.2, Windows sandbox configured as elevated. The September 29 creation-time log identifies command runner 0.158.0-alpha.2.1.

VERIFIED-SOURCE: creation sequence. On September 29, an agent explicitly ran Codex’s bundled create_basic_plugin.py with --with-marketplace and a project-local destination:

--marketplace-path "<project>\.agents\plugins\marketplace.json"

The recorded command completed successfully. .agents, its plugins subfolder, and marketplace.json all have creation time 2026-09-29T21:41:36.0672667Z, matching the command’s completion at 21:41:36.101Z.

Before repair, the .agents directory owner was <MACHINE>\CodexSandboxOffline. Subsequent affected-project commands repeatedly failed before execution with:

helper_unknown_error: setup refresh had errors

The sandbox log identified:

deny ACE failed on <project>\.agents: open deny ACL target for update

VERIFIED-SOURCE: comparison. A separate, brand-new empty project ran whoami successfully as codexsandboxoffline and remained empty. No .agents appeared during that test. The affected folder’s recorded origin was the explicit plugin-scaffolding operation.

VERIFIED-SOURCE: recovery.

Backed up the folder’s DACL with icacls /save, without recursion, and separately recorded its original owner.
From administrator PowerShell, changed only that directory’s owner:
```
icacls "<project>\.agents" /setowner "<MACHINE>\<USER>"
```
No /T or DACL edits. A non-administrator attempt had failed with Access is denied. Immediately after the owner change, the DACL matched the backup.
Restored the sandbox configuration from the temporary unelevated workaround to elevated and fully restarted the desktop app.

Setup refresh subsequently reported errors=[] and successfully applied protection to .agents. Commands worked in a fresh chat. whoami in that same chat returned <machine>\codexsandboxoffline, exit code 0. The directory remained owned by the interactive user after restart and testing.

INFERENCE: This supports an ownership/ACL interaction following plugin scaffolding. It is an observed incident and recovery, not an isolated reproduction: sandbox configuration and application lifecycle also changed.

Suggestion: Please review ownership handling when Codex tooling creates protected project directories through the sandbox. Reporting the affected path and ACL failure directly would also make this much easier to diagnose.

I can confirm a similar Windows failure, with a different affected directory. On Codex Desktop 26.928.40906, both normal shell startup and browser/computer-use initialization failed. The sanitized setup log reported deny ACE failed on <repo>\.git: open deny ACL target for update, followed by helper_unknown_error: setup refresh had errors. Inspection showed the root .git directory was owned by CodexSandboxOffline.

After backing up its ACL and, with Windows elevation, changing the owner of that directory alone to the interactive user (no recursion, ACL reset, or sandbox change), both a normal sandboxed Git command and cua.getState() succeeded.

This suggests the ownership/setup failure can affect a repository’s .git directory as well as .agents.

I reproduced the .git variant mentioned in this issue from a completely empty workspace and was able to isolate directory ownership as the variable that determines whether the sandbox refresh succeeds or fails.

Minimal reproduction

Environment:

Codex Desktop for Windows
Windows 11
workspace-write sandbox
command runner observed in the sandbox log: 0.160.0
NTFS workspace

I created a completely empty test workspace and ensured that its owner was my normal interactive Windows user.

I refer to this directory below as:

<test-workspace>

1. Baseline: sandbox works

From Codex Desktop:

Get-Location

Result: the command executed successfully and returned the test workspace.

The sandbox setup completed successfully.

2. Run `git init` from Codex

From Codex Desktop:

git init

Result:

Initialized empty Git repository in <test-workspace>/.git/

Immediately afterward, from normal PowerShell, I inspected the owner of .git:

(Get-Acl -LiteralPath '<test-workspace>\.git').Owner

The owner was the Codex sandbox account:

CodexSandboxOffline

(The actual Windows account value is machine-qualified; the machine name has been omitted here.)

The .git directory inherited the expected DACL. Its relevant ACL entries were:

CodexSandboxUsers:(I)(OI)(CI)(M)
<capability SID>:(I)(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M)

3. Next Codex command fails before execution

I then asked Codex Desktop to run only:

Get-Location

It failed with:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

The sandbox log shows that the failure occurred specifically while updating the newly created .git directory:

deny ACE failed on <test-workspace>\.git: open deny ACL target for update

setup refresh: processed 3 write roots (read roots delegated);
errors=["deny ACE failed on <test-workspace>\\.git: open deny ACL target for update"]

setup refresh completed with errors:
["deny ACE failed on <test-workspace>\\.git: open deny ACL target for update"]

setup error: setup refresh had errors

So git init itself succeeds, but the next sandbox refresh fails before the requested command can execute.

Owner-only A/B test

I then changed only the owner of the root .git directory.

Before:

Owner = CodexSandboxOffline

I recorded the complete SDDL before making the change.

I then changed the owner of:

<test-workspace>\.git

from the CodexSandboxOffline account to my normal interactive Windows user.

I recorded the complete SDDL again afterward.

The comparison showed that:

Owner: CodexSandboxOffline → interactive Windows user
Group: unchanged
DACL:  unchanged

No ACL reset or permission grant was performed.

Without making any other filesystem or Git changes, I asked Codex Desktop to run:

Get-Location

Result: SUCCESS.

The sandbox was operational again.

The controlled sequence was therefore:

empty workspace, owner = interactive user
    ↓
Get-Location                         PASS
    ↓
Codex runs git init                  PASS
    ↓
.git owner = CodexSandboxOffline
    ↓
next sandbox refresh                FAIL
    ↓
change ONLY .git owner
CodexSandboxOffline → interactive user
    ↓
next sandbox refresh                PASS

This appears to establish that the ownership change caused by sandboxed git init is sufficient to trigger this failure on my system.

It also explains why changing only the root .git owner has restored affected repositories for me without resetting the ACL, deleting .git, reinitializing Git, or using safe.directory.

Possibly broader than Git

I also reproduced a related failure without Git.

A fresh workspace directory owned by BUILTIN\Administrators, with the normal inherited DACL, failed during initial Codex sandbox provisioning with:

write ACE grant failed on <test-workspace>: open ACL target for update

An equivalent fresh directory with the same inherited permissions but owned by my interactive Windows user successfully received the Codex sandbox ACEs and executed Get-Location.

So .git may be one manifestation of a more general Windows sandbox ownership/ACL-update issue.

git init is particularly problematic because Codex itself creates .git as CodexSandboxOffline, after which the next sandbox refresh attempts an ACL update on that directory and fails.

This also appears related to #37965.

I have not traced the exact Windows access right requested by the setup helper, so I don't want to claim the specific WRITE_DAC/access-check mechanism without further evidence. However, the owner-only FAIL → PASS test above is reproducible.

Independent confirmation on Windows with Codex runtime 0.160.1, plus a separate Windows command-resolution issue uncovered during diagnosis.

1. Sandbox setup failure on a local NTFS Git workspace

Every local command initially failed before PowerShell/CMD could start:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

The useful detail was in %USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.log:

deny ACE failed on <repo>\.git: open deny ACL target for update
setup refresh completed with errors
setup error: setup refresh had errors

icacls <repo>\.git /verify succeeded and the DACL looked ordinary, but the root .git directory was owned by BUILTIN\Administrators.

From an elevated PowerShell I changed only the owner of the .git directory itself to the interactive Windows user (non-recursive):

takeown /F "<repo>\.git"

I did not reset the DACL, change inheritance, recursively change ownership, reinstall Codex, or reclone the repository.

Afterward (Get-Acl "<repo>\.git").Owner returned the interactive Windows user.

On the next Codex sandbox refresh the log changed to:

applied deny ACE to protect <repo>\.git
setup refresh: processed 2 write roots (read roots delegated); errors=[]
setup binary completed

and sandboxed PowerShell execution recovered (Get-Location ran successfully).

This independently supports the narrow recovery already discussed here: when the log identifies a protected path whose owner prevents the sandbox helper from updating its security descriptor, restoring ownership of that directory root to the interactive user can recover setup without a recursive ACL reset.

2. Separate issue discovered afterward: zero-byte command shadows in System32

After sandbox initialization recovered, Git still behaved incorrectly. This turned out not to be the same Codex ACL failure.

where.exe git returned:

C:\Windows\System32\git
C:\Program Files\Git\cmd\git.exe

The first path was a zero-byte, extensionless file. The real Git executable worked when invoked explicitly:

C:\Program Files\Git\cmd\git.exe --version
git version 2.55.0.windows.4

Further inspection found many zero-byte files in C:\Windows\System32 created within the same ~1-second interval, with names that looked like PowerShell script tokens/commands, including git, Select-Object, Sort-Object, Format-Table, Where-Object, ForEach-Object, Copy-Item, New-Item, Write-Host, $workspace, $gradleWrapper, and $generatedApk.

These files shadowed real executables/cmdlets. We quarantined only the zero-byte cohort from that exact creation window to a backup directory (no deletion). After opening a fresh PowerShell:

Get-Command Select-Object  -> Cmdlet / Microsoft.PowerShell.Utility
Get-Command Sort-Object    -> Cmdlet / Microsoft.PowerShell.Utility
Get-Command Format-Table   -> Cmdlet / Microsoft.PowerShell.Utility
git --version              -> git version 2.55.0.windows.4

I have not established what originally created those zero-byte System32 files, so I am NOT attributing that second issue to Codex. I am including it because it can produce misleading follow-on symptoms after the sandbox ownership problem is fixed.

Practical diagnostic sequence

For helper_unknown_error: setup refresh had errors, inspect the current sandbox log under %USERPROFILE%\.codex\.sandbox\.
If it reports deny ACE failed on <path>, inspect that exact path's owner and ACL rather than reinstalling Codex or resetting an entire drive/repository.
Prefer the narrowest repair possible; in this case changing only the .git root owner was sufficient.
If shell execution returns but commands still behave strangely, verify command resolution (where.exe git, Get-Command ...) independently instead of assuming the remaining symptom is still the sandbox.

Hope this saves the next person an "aha" moment without the full Windows archaeology session. 🙂

Same failure mode with a different trigger, plus a verified fix — in case it helps others.

Environment: Codex Desktop on Windows (app 26.1002.7124.0, bundled codex-cli 0.162.0-alpha.2,
command runner 0.162.0-alpha.2), Windows 10 Home China 26H2 build 26340.9616 x64,
sandbox_mode = "workspace-write", [windows] sandbox = "elevated".

Symptom: every sandboxed command was rejected before execution —
Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors").
Escalated commands worked, which pointed at sandbox initialization rather than the command.

Root cause: identical mechanism to the .agents case, but on .git:

deny ACE failed on D:\Qingjian\.git: open deny ACL target for update
setup refresh: processed 4 write roots (read roots delegated);
  errors=["deny ACE failed on D:\\Qingjian\\.git: open deny ACL target for update"]
setup error: setup refresh had errors

The repository had been cloned inside the sandbox, so the whole working tree — including .git —
was owned by <MACHINE>\CodexSandboxOnline; it was then moved and reopened as a workspace root.
The parent directory was owned by the interactive user, the contents by the sandbox account.
The interactive user had only Modify through a group ACE, which does not include permission to
change the ACL, so the setup helper could not open .git for the ACL update.

Worth noting this is not specific to .agents: any object created by the sandbox accounts can hit it.

Fix that worked (requires an elevated shell):

takeown /F D:\Qingjian /R /D Y
icacls D:\Qingjian /setowner "%COMPUTERNAME%\%USERNAME%" /T /C /Q

The next setup refresh recovered immediately:

setup refresh: processed 4 write roots (read roots delegated); errors=[]
setup binary completed

Non-elevated, icacls /setowner fails with "Access is denied" on every single file, which is the
trap here — it makes the situation look locally unfixable.

Suggestions: (1) surface the failing path and reason to the user instead of only
setup refresh had errors; (2) detect ownership mismatch during setup and print the exact
takeown/icacls remediation; (3) treat deny-ACE failures on protected subdirectories
(.git, .agents) as non-fatal so one bad directory does not disable the entire sandbox.

Independent confirmation of the root .git ownership / elevated sandbox ACL refresh failure on Windows, observed 2026-10-11 02:50 UTC. This is an affected user's diagnostic evidence; no ACL changes, reinstall, or recovery steps have been performed.

Environment / context

Codex Desktop on Windows (app/CLI exact version not captured yet).
%USERPROFILE%\.codex\config.toml contains:
```
[windows]
sandbox = "elevated"
```
Project directory and separate target game directory both exist on the host. A new local Codex conversation could not start even read-only shell commands; earlier setup involved a delegated Codex task and a local project initialization workflow. The specific process that created .git was not observed, so I cannot attribute that action with certainty.

Sanitized observed evidence

User-facing result: even a basic Get-Location / read-only project listing failed before the shell started with helper_unknown_error: setup refresh had errors.

Sandbox log:

[2026-10-11T02:50:38Z] setup refresh: processed 3 write roots (read roots delegated);
  errors=["deny ACE failed on <REPO>\\.git: open deny ACL target for update"]
[2026-10-11T02:50:38Z] setup refresh completed with errors
[2026-10-11T02:50:38Z] setup error: setup refresh had errors
[2026-10-11 02:50:38 UTC] codex-windows-sandbox-setup.exe setup error: setup refresh had errors
[2026-10-11 02:50:38 UTC] codex.exe setup refresh exited with status 1

Read-only host PowerShell checks:

Get-Item <REPO>\.git: Hidden, Directory (not a link)
(Get-Acl <REPO>\.git).Owner: <MACHINE>\CodexSandboxOffline
icacls <REPO>\.git:
  <capability SID>: (I)(OI)(CI)(M)
  <MACHINE>\CodexSandboxUsers: (I)(OI)(CI)(M)
  <another SID>: (I)(OI)(CI)(M)
  BUILTIN\Administrators: (I)(OI)(CI)(F)
  NT AUTHORITY\SYSTEM: (I)(OI)(CI)(F)
  BUILTIN\Users: (I)(OI)(CI)(RX)
  NT AUTHORITY\Authenticated Users: (I)(M)
  NT AUTHORITY\Authenticated Users: (I)(OI)(CI)(IO)(M)

Assessment: This matches the protected-directory creation / later deny-ACE setup deadlock reproduced earlier in this issue, including its .git variant. No proof that a specific delegated task caused the initial ownership state; the confirmed failure is the attempt to update the deny ACE while .git is sandbox-owned. Nothing has been changed on the affected user's machine during investigation.

Request: Please ensure Codex-created protected project directories stay manageable across elevated-sandbox refreshes, recover safely from this ACL/owner state (without administrator intervention), and surface the exact failing path/ACL operation to the user instead of only helper_unknown_error. A supported forensic / diagnostic / cleanup workflow would help users who prefer not to modify permissions manually. Machine name, username, absolute directory, and security identifier values deliberately redacted.

Navigation Menu

Repository navigation

Windows: Codex-created .agents ownership breaks sandbox setup and in-app browser control #43776

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Symptoms

Ownership evidence

Previous occurrence

Difference from this report

Expected behaviour

Environment

Minimal reproduction

Controls

Minimal reproduction

1. Baseline: sandbox works

2. Run `git init` from Codex

3. Next Codex command fails before execution

Owner-only A/B test

Possibly broader than Git

1. Sandbox setup failure on a local NTFS Git workspace

2. Separate issue discovered afterward: zero-byte command shadows in System32

Practical diagnostic sequence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows: Codex-created .agents ownership breaks sandbox setup and in-app browser control #43776

Description

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 8, 2026

veerthetiguy commented on Sep 8, 2026

RinkoKobayakawa commented on Sep 9, 2026

kevin198156 commented on Sep 18, 2026

holsoma commented on Sep 21, 2026

Environment

Symptoms

Ownership evidence

Previous occurrence

Difference from this report

Expected behaviour

riotallo300697 commented on Sep 21, 2026

SDSDFFG-rgb commented on Sep 21, 2026

satotaichi commented on Sep 24, 2026

Environment

Minimal reproduction

Controls

djwinten-ship-it commented on Sep 30, 2026

sanaro99 commented on Oct 2, 2026

Lovinxyu commented on Oct 4, 2026

Minimal reproduction

1. Baseline: sandbox works

2. Run git init from Codex

3. Next Codex command fails before execution

Owner-only A/B test

Possibly broader than Git

ImanCognitiveArch commented on Oct 7, 2026

1. Sandbox setup failure on a local NTFS Git workspace

2. Separate issue discovered afterward: zero-byte command shadows in System32

Practical diagnostic sequence

artforzxq commented on Oct 10, 2026

Hoppy-days commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

2. Run `git init` from Codex