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)"

Hello everyone. Faced with a similar problem. I asked codex itself to figure out what's going on and send a prompt to solve the problem if it happens again. To which he replied:

Normal reading or apply_patch is not working again. Check the log
C:\Users\ZhendoS\.codex\.sandbox\sandbox.2026-07-31.log,
The ACL of the root of the current workspace and the status of the Windows sandbox Codex.
Do not delete or change anything without diagnostics. If the reason is setup refresh
or SetNamedSecurityInfoW failed: 5, restore sandbox access in a secure
way, then check the read and temporary apply_patch with immediate rollback.

I hope I helped someone.

I am reproducing this exact issue on the current ChatGPT/Codex Windows desktop app.

• App version: 26.803.81509
• Release date shown in About: August 11, 2026
• Microsoft Store confirms it is fully updated
• Workspace: D:\ARK_Dino_Ledger_Tool
• Sandbox: workspace-write
• Feedback ID with attached session logs: 019febc0-b1c6-7733-8067-c88f48065263

The built-in apply_patch fails deterministically before file access with:

windows sandbox: helper_unknown_error: setup refresh had errors

I fully restarted the app, waited more than 30 minutes, and retried the normal patch helper once. It failed identically.

One narrowly authorized elevated apply_patch attempt later reached the local executable but returned Access is denied before writing. I declined the proposed direct PowerShell-writing workaround.

SHA-256 verification confirms that all intended target files remain byte-identical to their preserved baselines. No files were changed and no tests executed.

This appears related to #33964 and #32855. Please correlate this report with the submitted feedback/session logs using the feedback ID above.

<img width="384" height="360" alt="Image" src="https://github.com/user-attachments/assets/948e1868-7e38-4cf7-b565-48e60031daf3" />

<img width="1920" height="1049" alt="Image" src="https://github.com/user-attachments/assets/8d411bcf-9756-47c9-8999-9e5c422b6a23" />

I was able to solve this issue for msyelf by making my logged in user the owner of the folders that I am working in.

I launch codex in my documentation folder, and my repo's are in 2 different folders, since my local admin was owner of the folders it blocking the sandbox. I opened up a powershell session as administrator used below commands:

icacls "folder name" /setowner "logged in user"

Independent reproduction on Codex Desktop for Windows (2026-08-15).

This appears to be the same ownership/ACL failure described in #29867, and it is still reproducible in a newer desktop build.

Environment

• Codex Desktop app: 26.810.4967.0
• Codex command runner: 0.148.0-alpha.9
• Windows build: 10.0.26200.9168
• Filesystem mode: workspace-write
• Windows sandbox: elevated
• Workspace type: normal local repository (not UNC, not a reparse point)

Observed behavior

• In the ACL snapshot captured during the failure window, the repository root was owned by the local CodexSandboxOffline account.
• The interactive user had effective Modify access but did not have WRITE_DAC on that root.
• On every refresh, the sandbox setup helper attempts to grant a write ACE on the repository root.
• SetNamedSecurityInfoW returns Win32 error 5 (Access is denied).
• Setup ends with helper_unknown_error: setup refresh had errors.
• The built-in apply_patch operation then fails before it can read the target file.

The same checks found no read-only source attribute, Git lock, reparse point, or project filesystem watcher. The failure is in sandbox ACL setup, not patch content or project code.

Expected behavior

The Windows sandbox should not leave a user workspace owned by a transient sandbox account. If this ownership state already exists, setup refresh should recover safely or provide a specific remediation message instead of making apply_patch unusable.

<details>
<summary>Extended sanitized diagnostic log</summary>

# Source: native Windows elevated-sandbox log, corresponding apply_patch tool
# results, and a read-only ACL snapshot captured during failure.
#
# Redaction map
#   <CODEX_APP>           installed Codex application path
#   <CODEX_HOME>          per-user Codex data path
#   <REPO_ROOT>           affected repository path
#   <FILE_A>, <FILE_B>    target files
#   <MACHINE>             Windows machine name
#   <INTERACTIVE_USER>    interactive Windows user name
#   <LOCAL_SID>           machine-local security identifier
#
# Original timestamps were replaced while preserving event order. The native log
# mixes local-time and UTC records; LOCAL_TIMESTAMP and UTC_TIMESTAMP retain that
# distinction without publishing usage times.

--- refresh #1 ---
[LOCAL_TIMESTAMP A1 codex.exe] START: <CODEX_HOME>\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[LOCAL_TIMESTAMP A2 codex.exe] setup refresh: spawning <CODEX_APP>\resources\codex-windows-sandbox-setup.exe (cwd=<REPO_ROOT>, payload_len=4252)
[UTC_TIMESTAMP A3] granting write ACE to <REPO_ROOT> for sandbox group and capability SID
[UTC_TIMESTAMP A4] write ACE grant failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5
[UTC_TIMESTAMP A5] read-acl-only mode: applying read ACLs
[UTC_TIMESTAMP A6] setup refresh: processed 3 write roots (read roots delegated); errors=["write ACE failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5"]
[UTC_TIMESTAMP A7] setup refresh completed with errors: ["write ACE failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5"]
[UTC_TIMESTAMP A8] setup error: setup refresh had errors
[LOCAL_TIMESTAMP A9 codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
[LOCAL_TIMESTAMP A10 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))
[UTC_TIMESTAMP A11] read ACL run completed

--- refresh #2 / apply_patch attempt A ---
[LOCAL_TIMESTAMP B1 codex.exe] START: <CODEX_HOME>\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[LOCAL_TIMESTAMP B2 codex.exe] setup refresh: spawning <CODEX_APP>\resources\codex-windows-sandbox-setup.exe (cwd=<REPO_ROOT>, payload_len=4252)
[UTC_TIMESTAMP B3] granting write ACE to <REPO_ROOT> for sandbox group and capability SID
[UTC_TIMESTAMP B4] write ACE grant failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5
[UTC_TIMESTAMP B5] setup refresh: processed 3 write roots (read roots delegated); errors=["write ACE failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5"]
[UTC_TIMESTAMP B6] setup refresh completed with errors: ["write ACE failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5"]
[UTC_TIMESTAMP B7] setup error: setup refresh had errors
[LOCAL_TIMESTAMP B8 codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
[LOCAL_TIMESTAMP B9 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))
[TOOL RESULT B10] apply_patch verification failed: Failed to read file to update <REPO_ROOT>\<FILE_A>: fs sandbox helper failed with status exit code: 1: windows sandbox failed: helper_unknown_error: setup refresh had errors

--- refresh #3 / apply_patch attempt B ---
[LOCAL_TIMESTAMP C1 codex.exe] START: <CODEX_HOME>\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[LOCAL_TIMESTAMP C2 codex.exe] setup refresh: spawning <CODEX_APP>\resources\codex-windows-sandbox-setup.exe (cwd=<REPO_ROOT>, payload_len=4252)
[UTC_TIMESTAMP C3] granting write ACE to <REPO_ROOT> for sandbox group and capability SID
[UTC_TIMESTAMP C4] write ACE grant failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5
[UTC_TIMESTAMP C5] setup refresh: processed 3 write roots (read roots delegated); errors=["write ACE failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5"]
[UTC_TIMESTAMP C6] setup refresh completed with errors: ["write ACE failed on <REPO_ROOT>: SetNamedSecurityInfoW failed: 5"]
[UTC_TIMESTAMP C7] setup error: setup refresh had errors
[LOCAL_TIMESTAMP C8 codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
[LOCAL_TIMESTAMP C9 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))
[TOOL RESULT C10] apply_patch verification failed: Failed to read file to update <REPO_ROOT>\<FILE_B>: fs sandbox helper failed with status exit code: 1: windows sandbox failed: helper_unknown_error: setup refresh had errors

--- repetition summary ---
Affected-repository setup launches found in this log: 8
Launches ending in SetNamedSecurityInfoW error 5: 8
Successful affected-repository refreshes in the same log: 0

--- ACL correlation captured during the failure window ---
Path: <REPO_ROOT>
Owner: <MACHINE>\CodexSandboxOffline
DACL canonical: true
DACL inheritance protected: false
Interactive identity: <MACHINE>\<INTERACTIVE_USER>
Interactive-user effective rights: Modify, Synchronize
Right missing for ACL rewrite: WRITE_DAC / FullControl
Sandbox capability identity: <LOCAL_SID>
Healthy comparison roots owner: <MACHINE>\<INTERACTIVE_USER>

--- negative checks ---
Target source files marked read-only: no
Repository root is a reparse point or symlink: no
Git index.lock or equivalent lock residue found: no
Project-defined filesystem watcher/write/rename implementation found: no
Files changed by either failed apply_patch attempt: no

</details>

Privacy note: machine name, interactive user name, user-profile path, repository and file paths, Git remote, timestamps, local SIDs, email addresses, and task/session IDs were removed or replaced with placeholders.

I am reproducing this exact issue on the current ChatGPT/Codex Windows desktop app. App version: 26.803.81509 Release date shown in About: August 11, 2026 Microsoft Store confirms it is fully updated Workspace: D:\ARK_Dino_Ledger_Tool Sandbox: workspace-write Feedback ID with attached session logs: 019febc0-b1c6-7733-8067-c88f48065263 The built-in apply_patch fails deterministically before file access with: windows sandbox: helper_unknown_error: setup refresh had errors I fully restarted the app, waited more than 30 minutes, and retried the normal patch helper once. It failed identically. One narrowly authorized elevated apply_patch attempt later reached the local executable but returned Access is denied before writing. I declined the proposed direct PowerShell-writing workaround. SHA-256 verification confirms that all intended target files remain byte-identical to their preserved baselines. No files were changed and no tests executed. This appears related to #33964 and #32855. Please correlate this report with the submitted feedback/session logs using the feedback ID above. <img alt="Image" width="384" height="360" src="https://private-user-images.githubusercontent.com/72517276/634131675-948e1868-7e38-4cf7-b565-48e60031daf3.jpg?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODY3ODI0ODYsIm5iZiI6MTc4Njc4MjE4NiwicGF0aCI6Ii83MjUxNzI3Ni82MzQxMzE2NzUtOTQ4ZTE4NjgtN2UzOC00Y2Y3LWI1NjUtNDhlNjAwMzFkYWYzLmpwZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODE1VDA4MjMwNlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE2ZWJjNzEwNDdkMjI5YWZjZmIyMGEwNzY5MThlNjIwM2E0MWFmYzM5YTcwOGI4MjljYmI4ZDczYWM4ZjY4ZDYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRmpwZWcifQ.BrRKNYSAvTsjvYBVGV-FX2bSMKGrBs6TFzvk62upiGs"> <img alt="Image" width="1920" height="1049" src="https://private-user-images.githubusercontent.com/72517276/634132013-8d411bcf-9756-47c9-8999-9e5c422b6a23.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODY3ODI0ODYsIm5iZiI6MTc4Njc4MjE4NiwicGF0aCI6Ii83MjUxNzI3Ni82MzQxMzIwMTMtOGQ0MTFiY2YtOTc1Ni00N2M5LTg5OTktOWU1YzQyMmI2YTIzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODE1VDA4MjMwNlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTZmNTc4NzJlZTI0NTYzNDJmODUxOGYzOWExNzJjZDM3MTMwYWQ2OGFkZmMzNGE3MjEyOTI3ZDhhZDJmZDUzYWImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.h3E1sMdSY7oM2pW57SKUmUYaRN33t-LTx2Jp_CJIY4k">

Follow-up from my reproduction: the affected repository ownership was restored to my normal Windows user, after which the built-in apply_patch recovered. I retained workspace-write with the elevated Windows sandbox and verified normal file create, update, and delete behavior. This resolves the immediate local failure, but the underlying issue remains: Codex should not leave a user workspace owned by a transient sandbox account.

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."

THIS SOLVE MY PROBLEM TO

same issue

same issue

I reproduced the same error on Windows:

helper_unknown_error: setup refresh had errors

In my case, the bundled PowerShell runtime itself was healthy:

$pwsh = Join-Path $env:USERPROFILE ".cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe"
& $pwsh -NoProfile -Command "Write-Output DIRECT_PWSH_OK"

Result:

DIRECT_PWSH_OK
Exit code: 0

Clearing/rebuilding codex-runtimes, repairing the app, and testing a minimal config.toml did not resolve the problem.

The actual cause was visible in:

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

Relevant log entry:

deny ACE failed on D:\work\pss_radar_kunlun\.codex:
SetNamedSecurityInfoW failed for D:\work\.codex: 5

setup refresh completed with errors

ACL inspection showed that the workspace .codex directory had unexpectedly become owned by the sandbox account:

Owner: <MACHINE>\CodexSandboxOffline

The workspace root itself was still correctly owned by my normal Windows user; only the nested .codex directory had the wrong owner.

I fixed only that directory from an elevated PowerShell window:

$target = "D:\work\pss_radar_kunlun\.codex"
takeown.exe /F $target

Important: I did not use /A or /R. /A would assign ownership to the Administrators group, and /R would unnecessarily modify descendants.

Afterward:

(Get-Acl -LiteralPath $target).Owner

returned my normal account:

The same Codex task recovered immediately without a restart. PowerShell commands, project file reads, and Git commands all worked again.

This is likely one specific cause of setup refresh had errors, not a universal fix. I recommend checking the latest sandbox log for SetNamedSecurityInfoW failed: 5 and verifying the owner of the exact path named in the error before changing any permissions.