Activity

1. Flarenapple

   added

   bugSomething isn't workingSomething isn't working

   on Sep 27, 2026
2. github-actions

   added

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   tool-callsIssues related to tool callingIssues related to tool calling

   on Sep 27, 2026
3. github-actions commented on Sep 27, 2026

   

   github-actionsbot

   on Sep 27, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows] CLI 0.157.1 elevated sandbox provisioning fails with helper_unknown_error and creates no sandbox.log #48517
   • Different tool-error recovery behavior between GPT-6 Lune and GPT-5.6 Lune after Windows sandbox setup refresh failures #48479

   Powered by Codex Action
4. sanaro99 commented on Oct 2, 2026

   

   sanaro99

   on Oct 2, 2026

   More actions

   I encountered this same setup-refresh failure on Windows with Codex Desktop 26.928.40906. It prevented both normal shell startup and browser/computer-use initialization. The sanitized setup log identified a failed deny-ACE update on the repository’s root .git directory; its owner was CodexSandboxOffline.

   With Windows elevation, changing only that directory’s owner to the interactive user restored both the sandboxed shell and cua.getState() without changing the sandbox configuration or resetting its ACL. I added the fuller report to #43776, since it covers a related ownership/setup failure.

   👍React with 👍1Reacted by UJustBe Tech
5. ujustbetech commented on Oct 7, 2026

   

   ujustbetech

   on Oct 7, 2026

   More actions

   Fix: Codex on Windows fails with helper_unknown_error: setup refresh had errors

   Problem

   After restarting my laptop while a Codex task was running, every command in Codex failed with:

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

   The exit code was -1 for both cmd and PowerShell commands. Sometimes I also saw:

   windows sandbox failed: helper_unknown_error: setup refresh had errors
   node_repl kernel exited unexpectedly
   

   The commands themselves never ran. The failure was in Codex's own Windows sandbox/exec environment, not in my project code.

   Diagnosis

   1. Confirmed the error source. ~\.codex\.sandbox\setup_error.json contained:

      {
        "code": "helper_unknown_error",
        "message": "setup refresh had errors"
      }

   2. Read the sandbox log (~\.codex\.sandbox\sandbox.<date>.log). The key error was:

      runtime read/execute validation failed
      node_repl.exe: The process cannot access the file because it is being used by another process. (os error 32)
   

   3. Verified the lock was real by trying to open node_repl.exe from PowerShell. The file was locked.
   4. Traced the process holding it. The lock was associated with Codex's own runtime processes:

      codex.exe
      ├── node.exe
      └── node_repl.exe
   

   It was not caused by my Next.js development servers.

   5. Checked ACLs on the runtime folder and executable. The permissions looked correct, so I did not use destructive permission-reset commands such as takeown or icacls /reset.

   What did not fix it by itself

   • Killing the Codex processes with Stop-Process -Force. Codex recreated the runtime and the error returned.
   • Reinstalling Codex.
   • Restarting explorer.exe. Resource Monitor showed Explorer holding handles inside the Codex runtime folder.
   • Renaming the runtime folder (...\runtimes\cua_node\<hash> → <hash>.bak) so Codex could rebuild it.

   What fixed it

   With Codex fully closed, I changed the Windows sandbox setting in ~\.codex\config.toml.

   From:

   [windows]
   sandbox = "elevated"

   To:

   [windows]
   sandbox = "unelevated"

   After fully restarting Codex and starting a new thread, commands executed normally again. For example, dir worked successfully.

   Important: Edit the existing [windows] table. Do not add a second [windows] block, as that will make the TOML invalid.

   I backed up the configuration before editing:

   Copy-Item ~\.codex\config.toml ~\.codex\config.toml.bak

   I also moved the previous sandbox error state aside so I could distinguish fresh errors from old ones:

   Move-Item ~\.codex\.sandbox\setup_error.json ~\.codex\.sandbox\setup_error.old.json
   Move-Item ~\.codex\.sandbox\sandbox.<date>.log ~\.codex\.sandbox\sandbox.old.log

   Why unelevated works

   The issue appears to occur during the Windows elevated sandbox setup/refresh process. Switching to sandbox = "unelevated" avoids that failing setup path, allowing Codex's command environment to start normally.

   This means the change does not fix or unlock node_repl.exe itself. Instead, it avoids the sandbox setup path that was failing.

   Temporary workaround

   This is a temporary workaround, not a permanent fix.

   unelevated provides weaker sandbox isolation than elevated. The preferred long-term configuration is still:

   [windows]
   sandbox = "elevated"

   once the underlying Windows elevated-sandbox issue is fixed. A proper permanent fix should let the elevated sandbox initialize successfully without producing helper_unknown_error: setup refresh had errors.

   What to do until the issue is fixed

   Keep sandbox = "unelevated" and continue using Codex normally. There is no need to repeatedly delete or rebuild the Codex runtime.

   Current status:

   Item	Value
   Workaround	sandbox = "unelevated"
   Reason	Elevated sandbox fails with helper_unknown_error: setup refresh had errors
   Status	Working with unelevated sandbox
   Long-term	Return to elevated once the underlying issue is fixed

   The normal Codex workflow keeps working, including:

   • Running PowerShell/cmd commands
   • npm/pnpm commands
   • Git operations
   • Running the Next.js application
   • Editing and testing project files
     Because unelevated provides weaker isolation, it is preferable to keep command approvals/review enabled rather than allowing unrestricted automatic execution.

   Re-test after a Codex update

   After a future Codex update, test whether the elevated sandbox has been fixed:

   1. Change the config back:

      [windows]
      sandbox = "elevated"

   2. Restart Codex and start a new thread.
   3. Run a test command such as dir.
      If it works, the stronger elevated sandbox can be restored.

   If the same helper_unknown_error: setup refresh had errors error returns, switch back to:

   [windows]
   sandbox = "unelevated"

   and keep it there until the underlying issue is resolved.
6. tk-Ravi commented on Oct 8, 2026

   

   tk-Ravi

   on Oct 8, 2026

   More actions

   I’m seeing this in a Codex desktop session on Windows too.

   Workspace command execution fails before the command starts:
   exec_command failed: CreateProcess { message: "Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")" }

   The computer-use environment also failed to initialize with:
   windows sandbox failed: helper_unknown_error: setup refresh had errors

   This happened repeatedly during attempts to access my local workspace. Codex could not inspect or edit any project files.

   Codex version: 26.1002.52244
   Windows version: Windows 10 Pro, 22H2, 19045.7725.
7. hedarfu commented on Oct 8, 2026

   

   hedarfu

   on Oct 8, 2026

   More actions

   Another data point with a clean on/off repro. In our case the lock comes from the desktop app's computer-use runtime, and it breaks the CLI too.

   Environment: Windows 11 Pro 26H2 (build 26300.9550), x64. codex-cli 0.162.0-alpha.2, which is the CLI binary the desktop app installs under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe. Desktop app: MSIX package OpenAI.Codex (26.930.7945.0, auto-updated on 2026-10-08). The CLI runs non-interactively as codex exec -s workspace-write -c windows.sandbox="elevated".

   Repro

   1. Open the Codex desktop app. codex-computer-use-swift.exe starts from runtimes\cua_node\<hash>\....
   2. Run codex exec with any prompt that executes a shell command. It fails:

      Failed to create unified exec process: helper_unknown_error: setup refresh had errors
      ERROR codex_core::tools::router: error=exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }
      

   3. Close the desktop app, so no Codex app processes remain, and run the same command again. It works, and the setup refresh reports errors=[].

   %USERPROFILE%\.codex\.sandbox\sandbox.<date>.log:

   runtime read/execute validation failed: validate runtime read/execute access on C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll: open ACL target for root-only update: The process cannot access the file because it is being used by another process. (os error 32)
   setup refresh completed with errors: [...same...]
   setup error: setup refresh had errors
   [codex-windows-sandbox-setup.exe] setup error: setup refresh had errors
   [codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))
   

   The process holding VCRUNTIME140_1.dll was codex-computer-use-swift.exe, launched by the desktop app from that same cua_node runtime. That day the machine ran 83 setup refreshes. 80 had errors=[], and the only 3 that failed all ran while the app was open.

   So the elevated setup refresh tries to open runtime files for an ACL update, and those files are in use by the computer-use helper. It looks like the refresh should either skip runtime files that are already in use (their ACLs were already validated), or not treat a sharing violation on them as fatal. In the meantime, the error could name the process holding the lock.

   Workaround: we don't launch CLI agents on that machine while codex-computer-use-swift.exe is running.
8. Frostvalk commented on Oct 9, 2026

   

   Frostvalk

   on Oct 9, 2026

   More actions

   Title: Windows 11: Codex integrated terminal does not open; local command execution fails

   Environment

   • Windows 11
   • ChatGPT desktop app, Codex, local project chat
   • App version: Newest 09.Oct.26
   • Settings show the integrated terminal shell is PowerShell
   • The separate Codex CLI does not appear to be installed or available in PATH

   What happens

   • Clicking View > Terminal does nothing. No terminal panel opens.
   • The Ctrl + ^ keyboard shortcut also does nothing.
   • Local commands in this Codex session fail before they start with:
     Failed to create unified exec process: helper_unknown_error: setup refresh had errors
   • Error identifier shown by the app: 01a10c34-4115-7752-b9df-9001ff9173ca

   What I tried

   • Restarted Windows; the problem remained.
   • Force-closed and reopened the desktop app using Task Manager; the problem remained.
   • Started the app as administrator; the problem remained.
   • Checked for app updates; none were available.
   • Tried codex doctor in a standalone PowerShell window. PowerShell reported that codex is not recognized, so the separate CLI diagnostic could not run.

   Expected result
   The integrated terminal should open in the local project chat and allow commands to run.

   Please investigate the Windows desktop app’s terminal and local command environment. I have not changed sandbox settings or Windows permissions.
9. mmoad454-art commented on Oct 9, 2026

   

   mmoad454-art

   on Oct 9, 2026 – with ChatGPT Codex Connector

   More actions

   Adding another reproduction from a Windows desktop computer-use workflow that is blocking development of a local project (NetMedic).

   Feedback ID: 01a11996-6fc3-749d-b877-4664db4050c2
   Observed: 2026-10-09, approximately 17:23 (Saudi Arabia, UTC+03:00).

   The computer appears connected and authorized in the desktop UI, and the task can be submitted, but even a minimal read-only PowerShell command fails before the process is created:

   exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors
   

   Local project discovery also fails with DesktopProjectsUnavailableError. The tool returns no PowerShell exit code or execution session. The device connection menu shows the computer selected, but does not offer a reconnect option (only revoke access, which was not used).

   This is blocking autonomous work on the NetMedic application. There is no evidence the failure originates in the project source or Windows permissions; the failure appears to occur during execution-channel initialization.

   A feedback report has been submitted with the ID above. Please investigate the desktop execution/setup-refresh failure, and whether project discovery is affected by the same underlying issue.
10. venturi01 commented on Oct 12, 2026

    

    venturi01

    on Oct 12, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows desktop reproduction and successful targeted workaround, observed October 11–12, 2026. Posted with the affected user's authorization; personal paths are redacted.

    Environment observed

    • Running desktop executable path contained Windows package version OpenAI.Codex_26.1002.7124.0_x64 (package version, not a separately collected About-dialog version).
    • Backend: %LOCALAPPDATA%\OpenAI\Codex\bin\9691020b546a15b2\codex.exe.
    • Runtime: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin.
    • Ordinary workspace-write shell execution failed before PowerShell started. User-approved execution outside the sandbox succeeded.
    • User had tried restarting, but process inspection showed the particular ChatGPT.exe parent and codex.exe backend still had October 8 creation times.

    Error and process identification

    Top-level failure:

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

    Sandbox log's fatal error:

    runtime read/execute validation failed: validate runtime read/execute access on
    <RUNTIME>\bin\node_repl.exe:
    open ACL target for root-only update:
    The process cannot access the file because it is being used by another process. (os error 32)
    

    A read-only Windows Restart Manager query (RmRegisterResources/RmGetList) against that exact executable reported two node_repl.exe processes. Process ancestry traced both to this Codex backend, one directly and one through its Node helper.

    Controlled recovery sequence

    1. Rechecked executable paths and stopped only those two node_repl.exe processes with the user's approval.
    2. Retried ordinary sandboxed Get-Location. Setup still failed, but the fatal target changed from node_repl.exe to node.exe in the same runtime.
    3. Inspected the remaining processes executing that exact node.exe. Two were running ./server.mjs; their cmd.exe parent command lines identified:
       • scripts\launch_code_review_mcp.cmd
       • ./scripts/launch_codex_app_tools_mcp.cmd ./server.mjs
         Both traced to the same Codex backend.
    4. Revalidated executable paths and parent identities, then stopped those two service processes with approval.
    5. Immediately retried a normal sandboxed command (Write-Output 'Sandbox execution succeeded'; Get-Location). It succeeded with exit code 0, without an outside-sandbox override. Subsequent ordinary local reads also worked.

    No sandbox configuration changes, permission resets, runtime deletion, or reinstall were performed during this recovery. Stopping these helpers may interrupt their integrations.

    What this establishes / limits

    The observed sequence supports live bundled runtime processes blocking sandbox ACL setup: removing only node_repl processes exposed a second blocker in the code-review/app-tools Node services, and releasing both groups allowed setup to complete.

    This is a session-level workaround, not proof of a permanent repair. We have not tested recurrence after all integrations respawn, nor established the precise CreateFile access/share flags responsible.

    Please investigate runtime startup versus sandbox permission-refresh ordering and access requested during ACL validation. Reporting the actual target file and responsible process in the user-facing error would also greatly improve diagnosis.