Skip to content

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

Open
Open
Codex Windows: helper_unknown_error setup refresh had errors when running git log or reading project files#29797
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

Description

@jrtigers
jrtigers
opened on Jun 24, 2026

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.

Activity

  1. jrtigers
    added
    appIssues related to the Codex desktop app
    on Jun 24, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    tool-callsIssues related to tool calling
    on Jun 24, 2026

  3. github-actions commented on Jun 24, 2026

    @github-actions
    github-actionsBot
    on Jun 24, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. jrtigers commented on Jun 24, 2026

    @jrtigers
    jrtigers
    on Jun 24, 2026
    Author

    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.

  5. braindamp commented on Jun 26, 2026

    @braindamp
    braindamp
    on Jun 26, 2026

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

  6. c1594908064-gif commented on Jul 11, 2026

    @c1594908064-gif
    c1594908064-gif
    on Jul 11, 2026

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

  7. c1594908064-gif commented on Jul 11, 2026

    @c1594908064-gif
    c1594908064-gif
    on Jul 11, 2026

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

  8. enouchi-dev commented on Jul 11, 2026

    @enouchi-dev
    enouchi-dev
    on Jul 11, 2026

    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.

  9. petejmarino commented on Jul 13, 2026

    @petejmarino
    petejmarino
    on Jul 13, 2026 – with ChatGPT Codex Connector

    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.

  10. MajesticMug commented on Jul 17, 2026

    @MajesticMug
    MajesticMug
    on Jul 17, 2026

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

  11. Zh-end-oS commented on Jul 31, 2026

    @Zh-end-oS
    Zh-end-oS
    on Jul 31, 2026

    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.

  12. vrpill-personal commented on Aug 11, 2026

    @vrpill-personal
    vrpill-personal
    on Aug 11, 2026

    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.

    Image Image

  13. petejmarino commented on Aug 11, 2026

    @petejmarino
    petejmarino
    on Aug 11, 2026

    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"

  14. yuweiyang9611 commented on Aug 15, 2026

    @yuweiyang9611
    yuweiyang9611
    on Aug 15, 2026 – with ChatGPT Codex Connector

    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.

    Extended sanitized diagnostic log 
    # 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

    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.

  15. vrpill-personal commented on Aug 15, 2026

    @vrpill-personal
    vrpill-personal
    on Aug 15, 2026

    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.

    Image Image

    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.

  16. jagonbar commented on Aug 19, 2026

    @jagonbar
    jagonbar
    on Aug 19, 2026

    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

  17. wangyufe commented on Aug 24, 2026

    @wangyufe
    wangyufe
    on Aug 24, 2026

    same issue

  18. Rin-aki commented on Aug 24, 2026

    @Rin-aki
    Rin-aki
    on Aug 24, 2026

    same issue

  19. wangyufe commented on Aug 24, 2026

    @wangyufe
    wangyufe
    on Aug 24, 2026

    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.

  20. Bagestan commented on Sep 1, 2026

    @Bagestan
    Bagestan
    on Sep 1, 2026

    same issue

  21. dougfumitoshinakamura-dev commented on Sep 6, 2026

    @dougfumitoshinakamura-dev
    dougfumitoshinakamura-dev
    on Sep 6, 2026

    Additional Windows case: deny-ACE setup failure on .git, with a limited comparison test

    I encountered the same pre-execution failure in the native Windows Codex desktop environment:

    helper_unknown_error: setup refresh had errors

    The retained daily sandbox log identifies the failing operation as:

    deny ACE failed on D:\<workspace>\.git:
SetNamedSecurityInfoW failed for D:\<workspace>\.git: 5

    The workspace path above is redacted.

    Observations from the retained logs

    • The command runner recorded around the failures was version 0.152.1. The runtime executable inspected during the investigation reports 0.153.4.
    • On 2026-09-04 at 20:31 JST, adding a deny ACE to the same .git directory failed. At 21:31 JST, the log recorded successful deny-ACE application and an empty setup error list. That successful run still used the 0.152.1 runner. Therefore, the recovery cannot be attributed solely to upgrading to 0.153.4.
    • During the later investigation, .git itself was owned by the normal Windows user, and acquiring WRITE_DAC for that directory from the normal user process succeeded. Some descendants were owned by the sandbox user.
    • We do not have the failing operation's effective token, target capability SID, or a contemporaneous owner/DACL snapshot. The later state must not be treated as the state at the time of failure.

    Isolated comparison test

    We did not change the real .git directory's ownership or ACLs. Instead, we created temporary test trees and used a small Python ctypes probe following the Windows API sequence in the published rust-v0.153.4 acl.rs:

    GetNamedSecurityInfoW -> SetEntriesInAclW -> SetNamedSecurityInfoW.

    This was an API-level comparison, not a reproduction using the Codex binary itself.

    • Control: the parent and its two descendants were owned by the normal host user.
    • Comparison: the parent was owned by the same host user, but its two descendants were created by the sandbox user.
    • Corresponding initial DACLs, inheritance settings, and file contents matched. WRITE_DAC acquisition succeeded for both parents and all control objects, but failed with access denied for the comparison descendants.
    • The deny-ACE update was issued once to each parent from the non-elevated host user process.
    • In the control tree, the deny ACE appeared on the parent and descendants.
    • In the comparison tree, it appeared on the parent but not on the existing descendants.
    • Crucially, SetNamedSecurityInfoW returned success in both cases. The original setup failure with error 5 was not reproduced. The earlier WRITE_DAC access-check failures are separate results, not failures returned by the ACL-setting call.
    • Both parents subsequently satisfied the published code's "deny ACE already present" condition, evaluated read-only; we did not run a second update.

    The test therefore shows a descendant-propagation limitation under those specific conditions, but does not establish why the original setup call returned access denied. It does not justify applying a recursive ownership or ACL repair to the real repository.

    Related code review

    PR #39279 propagates ACL API failures instead of treating them as success. That change is already present in the 0.152.1 source history; it does not itself repair the condition causing Windows to deny the ACL update.

    The acl.rs blobs fetched for rust-v0.152.1, rust-v0.153.4, and public main were identical at the time of this investigation. This is only a comparison of that file, not a claim that all surrounding setup behavior is identical.

    Questions for maintainers

    Is there a known fix or recommended diagnostic procedure for this particular .git deny-ACE failure path? What additional information should be captured at the time of failure to distinguish:

    • lack of permission on .git itself,
    • descendant ACL/ownership effects,
    • capability-SID or concurrent-refresh changes,
    • or another setup condition?

    We would prefer to identify the failing condition before changing ownership, granting broad permissions, or weakening sandbox isolation. No deterministic reproduction of the original error has been established.

  22. seodevse commented on Sep 8, 2026

    @seodevse
    seodevse
    on Sep 8, 2026

    Same problem.

    This resolved it:
    Reset ownership of your repository root back to your active Windows user account:
    powershell

    takeown /f "C:\path\to\your\repo" /r /d y
    icacls "C:\path\to\your\repo" /reset /t

  23. DukeHouse commented on Oct 8, 2026

    @DukeHouse
    DukeHouse
    on Oct 8, 2026

    helper_unknown_error: setup refresh had errors 我在使用中也碰到这个问题

    Image

  24. Meetem commented on Oct 8, 2026

    @Meetem
    Meetem
    on Oct 8, 2026

    still a problem, appeared out of nowhere

  25. WFProgramming commented on Oct 8, 2026

    @WFProgramming
    WFProgramming
    on Oct 8, 2026

    getting this error suddenly

  26. itlogsandwich commented on Oct 12, 2026

    @itlogsandwich
    itlogsandwich
    on Oct 12, 2026

    Likewise.
    Suddenly happened as soon as I decided to bump the version to 0.162.1. Downgrading back to 0.162.0 did nothing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions