Codex Windows: helper_unknown_error setup refresh had errors when running git log or reading project files

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

• #28296
• #28431
• #28566
• #28248

Powered by Codex Action

Additional info:

Codex app version:
26.616.81150

Release date shown in About Codex:
2026-06-24

Subscription:
ChatGPT Plus

Feedback ID:
019ef7e9-f772-7da1-8e0a-f793ee2ddebF

The issue still happens on this version.

this worked for me (note: increased risk: this paradoxically provides LESS strict isolation)

TL;DR: this post contains a config.toml change + a restart instruction + some considerations

it worked for me by changing config.toml

sandbox = "elevated"

to:
sandbox = "unelevated"

Before restarting,
close codex completely, if another (administrator?) user is on windows, check in task manager if it has codex processes running and end them.
run this from PowerShell as codexlab:
Get-Process Codex -ErrorAction SilentlyContinue |
Stop-Process -Force

Then confirm:
Get-Process Codex -ErrorAction SilentlyContinue

It should return nothing.

then restart codex and let codex perform (in Low/Light) :
Run cmd.exe /d /s /c "echo CODEX_EXEC_OK" and report the exact stdout, stderr, exit code, and working directory. Do not create or modify any files. Do nothing else.

it should now return CODEX_EXEC_OK

From ChatGPT:
unelevated does not mean Codex receives unrestricted access. It means the Windows sandbox does not use the currently failing elevated setup path.
e.g. your codex user is a different user with less grants, so it is unable to perform elevated powershell commands and it should stop using that by default.

No. unelevated will generally not limit what Codex can build or run inside your project. It mainly weakens how strictly Codex can isolate those commands from the rest of the Windows account.

The confusing part is the name:

elevated does not give Codex more operational power.
unelevated does not mean Codex loses normal command-line capabilities.
The distinction is primarily about the sandbox implementation, not about whether Codex may compile code, run PowerShell, use Git, or create project files.
What will probably continue to work normally

Under:

sandbox_mode = "workspace-write"

[windows]
sandbox = "unelevated"

According to ChatGPT:
"
What is actually weaker

OpenAI describes the unelevated implementation as a fallback with weaker network isolation and incomplete enforcement of some split read/write permissions. The elevated implementation can use dedicated low-privilege sandbox users and more precise Windows access controls.

It means the effective outer boundary becomes the Windows permissions of the Windows codex user.

The main precaution is to avoid storing personal or sensitive material inside the codex user profile. OpenAI still recommends elevated when it works, while explicitly documenting unelevated as the fallback when elevated setup fails."

I can consistently reproduce the same Windows sandbox failure.

Environment:

• Windows 11, build 10.0.26200
• Codex/ChatGPT Windows app: 26.707.3748.0
• Codex runtime: 0.144.0-alpha.4
• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"

Minimal behavior:

1. Standard apply_patch can create a new file successfully.
2. Standard apply_patch cannot update that existing file.
3. Standard apply_patch cannot delete that existing file.
4. Reading the file and normal PowerShell filesystem operations work.

Exact error:
apply_patch verification failed: Failed to read file to update <path>:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed:
helper_unknown_error: setup refresh had errors

The same failure occurs in:

• An existing Unity Git repository
• A clean Codex-managed Git worktree
• A minimal test folder

Troubleshooting already attempted:

• Restarted Windows and the ChatGPT/Codex app
• Repaired and reinstalled the Windows app
• Switched the app to workspace-write
• Tested both elevated and unelevated Windows sandbox modes
• Ran the app normally and as administrator
• Closed Unity completely
• Tested a clean Git worktree
• Removed and allowed Codex to regenerate project sandbox ACLs

Unelevated mode gives a different error:
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

Elevated mode consistently returns:
helper_unknown_error: setup refresh had errors

PowerShell Set-Content works after explicit approval, but the standard apply_patch tool remains unusable for updating existing files.

I was able to identify and fix the exact cause of this error on my machine.

Environment:

• Windows 11 10.0.26200
• ChatGPT / Codex Windows App 26.707.3748.0
• Codex runtime 0.144.0-alpha.4
• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"

Behavior:

• apply_patch could create a new file.
• Reading the file succeeded.
• Updating or deleting an existing file failed with:

helper_unknown_error: setup refresh had errors

The relevant log was not named sandbox.log; it was in:

%USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.log

The exact failure was:

granting write ACE to C:\tmp for sandbox group and capability SID
write ACE grant failed on C:\tmp: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors:
["write ACE failed on C:\\tmp: SetNamedSecurityInfoW failed: 5"]

On this machine, C:\tmp was owned by BUILTIN\Administrators. The current Windows user only had Modify through Authenticated Users, so the sandbox setup helper could not call SetNamedSecurityInfoW successfully.

Granting Modify to CodexSandboxUsers and the sandbox capability SID was not sufficient, because the setup helper re-applies the ACEs during every refresh and the current app user still could not modify the directory ACL.

The fix was to run this in an elevated PowerShell, after backing up the existing ACL:

icacls "C:\tmp" /grant "<MACHINE>\<USER>:(OI)(CI)F"

I then fully restarted the ChatGPT / Codex app normally, without running it as administrator.

After the restart:

• apply_patch Add File succeeded.
• apply_patch Update File succeeded.
• apply_patch Delete File succeeded.
• The sandbox log repeatedly showed:

setup refresh: processed 3 write roots (read roots delegated); errors=[]

So in my case the root cause was not the project, Git, Unity, or a dirty worktree. It was the sandbox setup helper lacking permission to update the ACL on the automatically-added C:\tmp writable root.

Security note: granting FullControl on C:\tmp increases what the current Windows user can do there. Users should back up the existing ACL and consider whether C:\tmp is shared by other software before applying this workaround.

### What version of the Codex App are you using (From “About Codex” dialog)? Unknown ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Windows 10 / Windows 11, Codex Windows desktop app ### What issue are you seeing? Codex Windows desktop app repeatedly fails with: helper_unknown_error: setup refresh had errors Previous Codex feedback ID: 019ef48e-e421-7f93-bc11-aa7f3d42cac3 Current behavior: git status --short --untracked-files=all succeeds and shows no output. git diff --cached --stat succeeds and shows no output. git log -1 --oneline fails with helper_unknown_error. Reading AGENTS.md fails with helper_unknown_error. Reading scenes/main/main.gd fails with helper_unknown_error. Local PowerShell on the same machine can run git status, git diff, git log, and read AGENTS.md successfully, so the project files and Git repository appear to be fine. What I already tried: Rebooted Windows. Removed and re-added the project in Codex. Created new Codex threads. Submitted feedback from the Codex app. Checked %USERPROFILE%.codex\config.toml. Removed duplicate [windows] config entries. Kept only: [windows] sandbox = "elevated" Ran Codex as administrator. The environment check succeeded once after fixing the duplicate config, but the next real task failed again with the same helper_unknown_error. Current project state: Worktree is clean. Staging area is empty. No files were modified. No tests or Godot commands were run. No git add or git commit was performed. This issue is blocking my work. I mainly use ChatGPT Plus for Codex, but Codex is currently unusable for this project. Please investigate the Windows sandbox/setup refresh failure. ### What steps can reproduce the bug? Feedback ID: 019ef7e9-f772-7da1-8e0a-f793ee2ddebf ### What is the expected behavior? Codex should be able to complete setup refresh, read project files, and run basic git commands consistently. Expected: git log -1 --oneline should work. AGENTS.md should be readable. scenes/main/main.gd should be readable. Codex should not fail during setup refresh before the task starts. If the local Git worktree is clean and local PowerShell can read the files, Codex should be able to read them too. ### Additional information Local PowerShell on the same machine can run git status, git diff, git log, and read AGENTS.md successfully. The project files and Git repository appear to be fine. What I already tried: Rebooted Windows. Removed and re-added the project in Codex. Created new Codex threads. Submitted feedback from the Codex app. Checked %USERPROFILE%.codex\config.toml. Removed duplicate [windows] config entries. Kept only: [windows] sandbox = "elevated" Ran Codex as administrator. Environment check succeeded once, but the next real task failed again with helper_unknown_error. Current project state: Worktree is clean. Staging area is empty. No files were modified. No tests or Godot commands were run. No git add or git commit was performed. This is blocking my work. I mainly use ChatGPT Plus for Codex, but Codex is currently unusable for this project.

I am seeing a very similar issue on Windows with Codex.

Environment:

• Windows desktop Codex app
• Local repo path originally: C:\Dev\guided-investor-app
• Clean local clone also tested: C:\Dev\guided-investor-app-codex

Observed behavior:
Codex intermittently fails with:

windows sandbox: helper_unknown_error: setup refresh had errors

Pattern:

• Sometimes Codex can read the repo.
• Sometimes Codex can create/modify/delete harmless files.
• Sometimes source patching works temporarily.
• Then sandbox setup refresh fails before commands can run.
• Local Administrator PowerShell can run Git commands and access the repo successfully.

Git/ACL details:
The original repo also had stale NTFS ACL deny entries under .git that blocked git add, including:

• .git/index.lock creation permission denied
• later .git/objects permission errors

After attempting ACL repair and then creating a clean local clone, Codex still failed against the clean clone before basic repo checks could run, with the same setup refresh error.

Impact:
This blocks reliable Codex source-edit/test/stage/commit workflows on Windows. It is especially risky for sensitive files like auth/access-control code because Codex cannot be trusted to complete the full workflow consistently.

Current workaround:
I am pausing sensitive Codex-based coding and using planning/QA/manual-controlled workflows only.

This appears related to the same Windows sandbox/setup-refresh issue described here.

Additional reproduction from Codex Desktop on native Windows (2026-07-12, America/New_York):

• Sandbox mode: workspace-write with multiple explicitly writable local workspace roots.
• A simple read-only check initially succeeded: Get-Item CLAUDE.md.
• The very next normal apply_patch call failed before touching the file with:

windows sandbox: helper_unknown_error: setup refresh had errors

• Retrying after fully restarting Codex reproduced the same apply_patch failure.
• After the patch failure, even some read-only shell commands intermittently failed with the same setup-refresh error, while other read-only calls sometimes succeeded.
• The target file was a normal local file (not read-only, not a symlink), the workspace was configured writable, and the drive had ample free space.
• Another coding tool was able to edit the same workspace concurrently, which indicates the repository and ordinary Windows permissions were healthy.
• The failure appears specific to Codex's Windows sandbox/setup refresh layer and blocks normal file editing.

Expected: sandbox refresh should initialize consistently and apply_patch should edit files under configured writable roots.

Actual: refresh intermittently fails before command execution, persists across a new Codex app session, and can affect both patch and shell calls.

I think this happens when some agents decide to write files in places like C:\tmp,

Codex thinks this is a new writable root, so the startup logic tries to acquire permissions to all writable roots. The Codex sandbox user in Windows doesn't have access to that path, so it fails.

I was able to work around it by granting ACLs to the Codex users with these commands from an admin PowerShell:

icacls C:\tmp /grant "CodexSandboxOffline:(OI)(CI)(RX)"
icacls C:\tmp /grant "CodexSandboxOnline:(OI)(CI)(RX)"