Workspace terminal fails to start with "setup refresh had errors"

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.31338

What subscription do you have?

Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

The workspace terminal cannot start any command.

Whenever I run a terminal command such as pwd, Get-Location, or rg --files, the command fails before execution with the following error:

CreateProcess:
Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")

The issue occurs with PowerShell, Command Prompt, and the system PowerShell executable. No detailed stack trace, log path, or additional information about the "setup refresh" failure is shown.

Codex App version: 26.818.31338
Workspace runtime dependency version: 26.819.11345

What steps can reproduce the bug?

Open Codex Desktop on Windows 11.
Open a local workspace or repository.
Start a new task or thread.
Run any terminal command, for example:
- pwd
- Get-Location
- rg --files
Observe that the command fails before it is executed.

Expected behavior:
The terminal process should start and execute the command successfully.

Actual behavior:
The terminal process is rejected during setup with:

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

The issue occurs consistently across PowerShell, Command Prompt, and the system Windows PowerShell executable.

What is the expected behavior?

No response

Additional information

No response

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

Powered by Codex Action

Additional reproduction from a Windows Codex Desktop task on 2026-08-23:

Workspace: C:___Projects\anthropic-api\repo
The failure is reproducible before command execution with PowerShell, cmd.exe, and Git.
Failed read-only commands included Get-Location, Get-ChildItem, rg --files, and git status.
Exact result: CreateProcess rejected with helper_unknown_error: setup refresh had errors.
The failure prevented repository inspection, including Azure IaC/resource-name inventory and deployability validation.
No repository files were modified and no command reached the target process.

This confirms the issue blocks read-only software-engineering workflows, not only application commands.

I can reproduce the same problem in Codex Desktop on Windows.

Every local command fails before execution, including:

Get-Location
Get-Content -Raw <file>

The exact error is:

CreateProcess {
  message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")"
}

I also tried switching from the bundled PowerShell runtime to the system Windows PowerShell; the failure is unchanged. Restarting/reinstalling the Codex desktop app did not resolve it.

Additional reproduction after restarting Codex Desktop on 2026-08-24:

Workspace: C:\___Projects\openai-api
Restarting Codex Desktop did not resolve the failure.
I explicitly requested Git Bash instead of PowerShell.
Attempts used:
- C:\Program Files\Git\bin\bash.exe
- bash
- the bundled runtime path ending in dependencies\native\git\bin\bash.exe
Even with the explicit Git Bash shell selection, the execution result showed a cmd.exe /c wrapper and failed before Bash started.
A minimal command such as pwd; git --version never executed.
The exact failure remained:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }

This means a full app restart and selecting an alternative shell do not provide a workaround. The failure occurs before the requested shell process starts. No repository files were modified.

I am experiencing the same issue on Windows.

The problem persists after repairing and resetting the ChatGPT app,
restarting Windows, running the app as administrator, and creating a new task.

Workspace:
C:\wamp\www\yorkfrance-php8x27

Workspace owner:
BEELINK-PC\yves

Feedback ID:
01a030e1-174d-78e2-aa70-15f10e5597bb

I can independently reproduce this on Windows in the Codex desktop app today (2026-08-24).

Symptoms match this issue exactly:

Any shell command fails before execution, including the minimal read-only Get-Location test.
Error: Failed to create unified exec process: helper_unknown_error: setup refresh had errors
Reproduces in a fresh Codex conversation/workspace session.
Restarting the Codex app did not recover the shell.
Switching between GPT-5.3-Codex-Spark and GPT-5.6 Sol did not change the result.
The affected local project is on a secondary Windows drive (D:).
The project/web application itself remains accessible; the failure occurs at shell process creation, before project commands can run.

This is currently blocking further local development/testing because even a basic read-only shell command cannot start.

Happy to provide additional non-sensitive diagnostics if there is a recommended collection procedure.

I can reproduce the same failure on a newer Windows app version.

App version: 26.818.5229.0
Subscription: ChatGPT Pro (5×)
Platform: Microsoft Windows NT 10.0.26200.0 x64

The error is intermittent: one PowerShell command may succeed, while the next independent command fails before process creation with:

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

The issue also affected in-app browser control in a previous task. It persisted after repairing the app, restarting Windows, and starting a new task.

Feedback ID with session and browser logs:
01a03224-b13f-73a1-90d2-43c1bb438f87

I can reproduce this error on app version 26.819.11345 on windows 11 x64
Reproducible with; Get-Date -Format o (or any powershell command)
helper_unknown_error: setup refresh had errors
Persists after reinstall and restart

Additional reproduction from Codex Desktop on Windows on 2026-08-25:

Workspace root: C:\___Projects
Every local process launch failed before command execution with helper_unknown_error: setup refresh had errors.
Explicit shell selection using both C:\Program Files\Git\bin\bash.exe and C:\Program Files\Git\usr\bin\bash.exe did not start Git Bash; the execution result instead showed a cmd.exe /c wrapper and failed during setup.
Directly invoking C:\Program Files\Git\bin\bash.exe from the bundled PowerShell runtime also failed before Bash started.
Minimal commands such as pwd never executed.
The task had no attached app terminal session, so that path could not be used as a fallback.
No workspace or repository files were created or modified.

This confirms the failure persists across another local workspace and blocks explicit alternative-shell selection as well as direct shell invocation.

Still reproducible after updating the Windows app.

Previous version: 26.818.5229.0
Current version: 26.818.8289.0
Platform: Microsoft Windows NT 10.0.26200.0 x64

Immediately after the update, a read-only Get-Location command again failed before PowerShell started with:

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

No repository files were modified and no external operation was attempted.

Related feedback ID:
01a03224-b13f-73a1-90d2-43c1bb438f87

Additional reproduction on 2026-08-25:

Platform: Microsoft Windows NT 10.0.26200.0 x64
Codex App version: Version 26.818.61809

A minimal Get-Location command fails before PowerShell starts with:

CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }

The same sandbox setup failure also affects:

apply_patch, while trying to read/verify a workspace file
in-app browser-control runtime startup

An explicitly approved out-of-sandbox execution succeeds with:

workspace file creation, reading, and deletion
Git
Python
project scripts

This suggests the underlying repository and filesystem access are functional and the failure is specifically in Windows sandbox setup/refresh.

Critical recurrence — 2026-08-26

This remains reproducible in Codex Desktop on Windows and is currently a complete blocker for local repository work.

Every command is rejected before process launch with:

CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }

Reproduced with both the bundled PowerShell (pwsh.exe -Command Get-Location) and Command Prompt (cmd.exe /c cd).

Opening the task terminal panel returned status: queued, but the task continued to report:

No app terminal session is attached to this thread yet.

Retrying from the same task after refreshed environment context did not recover the process host.

Impact: critical. No shell command can start, so Git status/fetch/worktree checks, repository inspection, builds, tests, and safe file modifications are all blocked. The repository was intentionally left unchanged because mandatory safety checks could not run.

Still reproducible after another Windows app update.

Previous affected version: 26.818.8289.0
Current affected version: 26.820.7780.0
Platform: Microsoft Windows NT 10.0.26200.0 x64

Immediately after updating, a read-only Get-Location command failed before PowerShell started with:

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

No repository files were modified and no external operation was attempted.

Related feedback ID:
01a03224-b13f-73a1-90d2-43c1bb438f87

Confirmed fix for my instance of this issue on Windows.

The displayed error was:

Rejected("Failed to create unified exec process:
helper_unknown_error: setup refresh had errors")

The specific cause was recorded in:

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

My log contained:

deny ACE failed on C:\path\to\repo\.git:
SetNamedSecurityInfoW failed: 5

Checking the directory showed that .git was incorrectly owned by CodexSandboxOffline:

(Get-Acl "C:\path\to\repo\.git").Owner

I opened PowerShell as Administrator and restored ownership of only that directory:

takeown /F "C:\path\to\repo\.git"

After restarting Codex:

.git was owned by my Windows account;
sandbox setup reported errors=[];
normal terminal commands executed successfully again.

This fix is path-specific. Other instances of setup refresh had errors may involve Temp, WindowsApps, WSL/UNC paths, or another workspace directory. Check the current sandbox log for the exact failing path before changing ownership or permissions. Recursive ACL changes should not be necessary unless the log explicitly identifies child paths.

I can reproduce this on Codex Desktop 26.820.7780.0 on Windows x64 in a local workspace. On 2026-08-26 (Europe/Warsaw), Browser startup via node_repl fails before browser selection. The Node kernel exits with code 1 and reports: windows sandbox failed: helper_unknown_error: setup refresh had errors. The initial normal sandboxed PowerShell command also fails before process creation with the same setup-refresh error, while the equivalent read-only check succeeds with elevated sandbox approval. This blocks browser control and normal sandboxed commands. The issue began about a week ago. I fully terminated Codex, used Windows App Repair, and then completely uninstalled and reinstalled it; the failure persists. C:\tmp does not exist on this system. The installed package reports Status: Ok.

@vlastimilvajnorak

Update — resolved for my instance. Thanks @vlastimilvajnorak for sharing the targeted diagnostic steps in #39841 (comment). My sandbox log identified the repository .git directory as the failing path: the sandbox could not apply its deny ACE because that directory was owned by CodexSandboxOffline. Restoring ownership of that directory only to the Windows user fixed the issue immediately: normal sandboxed commands and the in-app browser now start successfully. No recursive ACL changes were needed.

@ablazhko

Thank you, @ablazhko — your diagnosis and targeted fix resolved the issue for me.

My sandbox log showed the same failure on the workspace repository’s .git directory:

deny ACE failed ... .git: SetNamedSecurityInfoW failed ... : 5

The directory owner was CodexSandboxOffline. Restoring ownership of that directory only to my normal Windows user account fixed the problem immediately. No recursive ownership or ACL changes were needed.

After that, normal sandboxed terminal commands started working again. Thanks again for identifying such a precise and safe solution.

Confirmed workaround on Windows

I was hitting the same error:

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

Codex could not start PowerShell, CMD, Git, or any local process.

I checked:

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

and found:

deny ACE failed on C:\dev\sample-project\.git:
SetNamedSecurityInfoW failed for C:\dev\sample-project\.git: 5

5 = Access Denied.

Then I checked the .git owner:

(Get-Acl "C:\dev\sample-project\.git").Owner

It was unexpectedly owned by:

DESKTOP-EXAMPLE\CodexSandboxOffline

instead of my normal Windows account.

Fix

I closed Codex completely, opened PowerShell as Administrator, and ran:

$me = "$env:USERDOMAIN\$env:USERNAME"
icacls "C:\dev\sample-project\.git" /setowner "$me"

After reopening Codex, local execution worked again immediately:

git status
git --version
cmd.exe /c echo CODEX_CMD_OK

No reinstall, reclone, .git deletion, or recursive permission reset was needed.

So if you are seeing setup refresh had errors, check whether your .git directory is owned by CodexSandboxOffline. Restoring ownership to the normal Windows user may fix the issue.

@MadMick96

@MadMick96 Thank you . Based on your answer, it is currently resolved!
On Windows, Codex Desktop may fail with:

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

This usually means that the Codex Windows sandbox failed while applying or refreshing filesystem ACLs.

1. Check the current sandbox log

Sandbox logs are located under:

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

You can locate the newest log with PowerShell:

Get-ChildItem "$env:USERPROFILE\.codex\.sandbox\sandbox*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1 FullName,LastWriteTime

Then inspect the end of that log:

Get-Content "C:\Users\<username>\.codex\.sandbox\sandbox.<date>.log" -Tail 100

Look for an error similar to:

deny ACE failed on C:\path\to\repo\.git:
SetNamedSecurityInfoW failed for C:\path\to\repo\.git: 5

or:

deny ACE failed on C:\path\to\repo\.codex:
SetNamedSecurityInfoW failed for C:\path\to\repo\.codex: 5

Windows error code 5 means:

Access Denied

The path reported in the log is the path that should be investigated.

2. Check the owner of the failing path

For example, if the log reports:

C:\path\to\repo\.git

check its owner:

(Get-Acl "C:\path\to\repo\.git").Owner

Or, if the failing path is:

C:\path\to\repo\.codex

run:

(Get-Acl "C:\path\to\repo\.codex").Owner

Normally, the owner should be the Windows account that owns the repository, for example:

MY-PC\myuser

A problematic case can look like:

MY-PC\CodexSandboxOffline

In that situation, the sandbox account appears to have incorrectly retained ownership of the directory. A later sandbox refresh may then fail when Codex tries to modify the ACL again.

3. Restore ownership only for the failing path

First, fully exit Codex Desktop.

Then open PowerShell as Administrator.

If the failing path is .git:

takeown /F "C:\path\to\repo\.git"

If the failing path is .codex:

takeown /F "C:\path\to\repo\.codex"

Then verify the owner:

(Get-Acl "C:\path\to\repo\.git").Owner

or:

(Get-Acl "C:\path\to\repo\.codex").Owner

The owner should now be your normal Windows account.

4. Do not recursively reset ACLs unless the log requires it

In most cases, commands such as these should not be necessary:

takeown /F "C:\path\to\repo" /R /D Y

or:

icacls "C:\path\to\repo" /reset /T /C

Codex uses specific Allow/Deny ACEs as part of its sandbox implementation. Recursively resetting the entire repository may remove ACL entries that Codex intentionally created.

The safer rule is:

log reports exact path
→ inspect that exact path
→ restore ownership only for that path

5. Restart Codex and verify the sandbox log

After restoring ownership, restart Codex Desktop.

A successful sandbox setup should contain output similar to:

applied deny ACE to protect C:\path\to\repo\.codex
setup refresh: processed 4 write roots (read roots delegated); errors=[]
setup binary completed

The important indicator is:

errors=[]

The following should no longer appear:

setup refresh had errors

or:

helper_unknown_error

6. Test normal sandbox filesystem operations

After restarting, test a few basic operations through Codex:

git status
create a temporary file
read the temporary file
delete the temporary file

I am seeing the same failure in the VS Code Codex extension.

Environment:

- OS: Microsoft Windows 11 Home, Version	10.0.26200 Build 26200
- VS Code: Version: 1.136.1 (user setup)
- Extension: `openai.chatgpt` version `26.901.22334`
- Shell: Windows PowerShell 5.1
- PowerShell version: `5.1.26100.9278`
- WSL: not installed
- Sandbox configuration: `[windows] sandbox = "elevated"`

The extension launches its bundled binaries from:

```text
%USERPROFILE%\.vscode\extensions\openai.chatgpt-26.901.22334-win32-x64\bin\windows-x86_64\

Normal VS Code PowerShell and Claude Code work in the same workspace.

Codex logs repeatedly show:

codex_core::shell_snapshot: Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

followed by:

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

Every subsequent exec_command fails before the requested process starts. Restarting VS Code, restarting the terminal, and restarting Windows did not resolve it.

This occurs in the VS Code extension rather than the standalone Codex CLI. Please advise whether this is the same Windows sandbox provisioning issue and whether extension-specific logs or diagnostics are needed.

codex-windows-sandbox-repair.zip

I uploaded a portable Agent Skill, codex-windows-sandbox-repair, based on a Windows case where Codex failed before executing any command with:

helper_unknown_error: setup refresh had errors
SetNamedSecurityInfoW failed for <repo-root>\.codex: 5
The underlying issue was incorrect ownership of the repository’s .codex directory. The repair was:
1. Run PowerShell as Administrator.
2. Confirm the owner:
$repoRoot = (Get-Location).Path
$target = Join-Path $repoRoot '.codex'
(Get-Acl -LiteralPath $target).Owner
3. If the owner is a sandbox/service account rather than the interactive user, repair only that directory:
$repoRoot = (Get-Location).Path
$target = Join-Path $repoRoot '.codex'
$me = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
icacls.exe $target /setowner "$me"
(Get-Acl -LiteralPath $target).Owner
Do not use /T, modify .git, change global permissions, or alter OneDrive settings.
Afterward, fully restart Codex and verify with a fresh Codex-runner command such as:
Get-Location
This is an evidence-based repair for the specific SetNamedSecurityInfoW ... .codex: 5 signature, not a guaranteed fix for every setup refresh failure. Please redact usernames, domains, SIDs, full paths, feedback IDs, and other machine-specific information before sharing diagnostics publicly.

Le 28 septembre 2026, Codex Desktop sous Windows échoue avant le lancement de toute commande avec helper_unknown_error: setup refresh had errors. Plusieurs redémarrages n’ont pas résolu le problème. L’accès aux fichiers du projet est bloqué.

Additional Windows reproduction (2026-09-29, Asia/Shanghai).

Observed error in Codex Desktop when attempting even the minimal command Get-Location:

Failed to create unified exec process:
Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")

Control tests performed outside Codex on the same Windows machine:

Windows PowerShell at C:\:

Get-Location

Succeeded and returned C:\.

Created an empty test directory:

mkdir C:\CodexExecTest
cd C:\CodexExecTest
Get-Location

Succeeded and returned C:\CodexExecTest.

In Codex Desktop, asked Codex to execute the same minimal command Get-Location. Codex reported that the command did not start and returned:

helper_unknown_error: setup refresh had errors

This provides a clean isolation result: Windows PowerShell itself and the empty directory are functional, while Codex fails before launching the requested process. The reproduction is therefore consistent with a Codex Desktop local execution/sandbox/workspace setup-refresh failure rather than a PowerShell command failure or corruption of the original project files.

Not yet verified in this reproduction: the specific underlying cause inside Codex (e.g. sandbox helper, ACL application, local configuration, security software interaction, or another setup-refresh component). No claim is made about root cause beyond the confirmed failure boundary above.

Navigation Menu

Repository navigation

Workspace terminal fails to start with "setup refresh had errors" #39841

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Critical recurrence — 2026-08-26

Fix

1. Check the current sandbox log

2. Check the owner of the failing path

3. Restore ownership only for the failing path

4. Do not recursively reset ACLs unless the log requires it

5. Restart Codex and verify the sandbox log

6. Test normal sandbox filesystem operations

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Workspace terminal fails to start with "setup refresh had errors" #39841

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 21, 2026

vlastimilvajnorak commented on Aug 23, 2026

AlexeyAbubyakirov commented on Aug 24, 2026

vlastimilvajnorak commented on Aug 24, 2026

yvescesso commented on Aug 24, 2026

orlay626 commented on Aug 24, 2026

icrevinversiones-stack commented on Aug 24, 2026

kleinjoshua298-byte commented on Aug 25, 2026

vlastimilvajnorak commented on Aug 25, 2026

icrevinversiones-stack commented on Aug 25, 2026

pocketlinkDev commented on Aug 25, 2026

vlastimilvajnorak commented on Aug 25, 2026

Critical recurrence — 2026-08-26

icrevinversiones-stack commented on Aug 25, 2026

MadMick96 commented on Aug 26, 2026

ablazhko commented on Aug 26, 2026

ablazhko commented on Aug 26, 2026

yvescesso commented on Aug 26, 2026

normandiazr64 commented on Aug 26, 2026

Fix

mzzyb commented on Aug 27, 2026

1. Check the current sandbox log

2. Check the owner of the failing path

3. Restore ownership only for the failing path

4. Do not recursively reset ACLs unless the log requires it

5. Restart Codex and verify the sandbox log

6. Test normal sandbox filesystem operations

tdquerec commented on Sep 5, 2026

tdquerec commented on Sep 5, 2026

doddynicolas commented on Sep 28, 2026

lingsanyue6-beep commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions