Environment
codex-cli version: 0.153.0-alpha.5
OS: Windows 11
Sandbox mode: default (workspace-write)
Install path: %LOCALAPPDATA%\OpenAI\Codex\bin<hash>\codex.exe
Summary
On this Windows machine, every invocation of exec_command — and even plain file reads — fails at the sandbox initialization layer before reaching the tool logic. This makes codex-cli fully unusable in any workflow that needs command execution or file access, even read-only.
Steps to reproduce
Run codex.exe exec "" < /dev/null
Observe the error below on the very first tool call, regardless of what the tool call actually does.
Actual error
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")" }
...
ERROR codex_core::tools::router: error=unable to locate image at <file>: fs sandbox helper
failed with status exit code: 1: windows sandbox failed: helper_unknown_error: setup refresh had errors
Expected behavior
Sandbox helper initializes successfully (or fails with an actionable error naming the missing Windows dependency/feature), and exec_command/file reads work normally under workspace-write sandbox mode.
Notes / what we've ruled out
Not a CLI flag/config issue — this is a lower-level Windows sandbox helper initialization failure, distinct from the (already-fixed) "no active project" confirmation error we hit previously with a different Codex-based agent on the same machine.
We have not tried --dangerously-bypass-approvals-and-sandbox (or equivalent) to isolate whether the sandbox layer itself is the sole blocker, since this instance is driven by an unattended automation pipeline and running without sandbox isn't a safe test to run unattended.
Suspected cause (unconfirmed): a Windows optional feature or permission the sandbox helper depends on (e.g. Windows Sandbox feature, Hyper-V, or app container capability) may not be enabled on this machine. Haven't yet confirmed which one.
Related issues
GitHub's duplicate detector flagged #28278, #28457 and #34928 — all in the same Windows sandbox helper subsystem, but none appear to be the same failure:
#28278 / #28457: the launcher fails to locate the helper executable (error=program not found, or ShellExecuteExW failed... 1223), traced to a PATH/junction mismatch between the visible codex.exe entry point and the real standalone release directory.
#34928: helper crashes with 0xc0000142 (DLL init failure) specifically during the Desktop app's UAC-elevated first-run setup flow.
This issue: the helper is found and launched, but the setup refresh step itself returns helper_unknown_error: setup refresh had errors — a different failure signature, and downstream of where the other three fail. Our install also resolves directly to a versioned bin<hash>\codex.exe path rather than the junction layout described in #28278/#28457, so that specific root cause likely doesn't apply here.
Flagging the overlap in case a maintainer sees a connection we don't, but filing separately since the error text and failure point differ.
Impact
Full loss of function for any automated/headless codex-cli workflow on this machine — it can echo/respond but cannot execute or read files, since 100% of tool calls fail at this layer.
Environment
codex-cli version: 0.153.0-alpha.5
OS: Windows 11
Sandbox mode: default (workspace-write)
Install path: %LOCALAPPDATA%\OpenAI\Codex\bin<hash>\codex.exe
Summary
On this Windows machine, every invocation of exec_command — and even plain file reads — fails at the sandbox initialization layer before reaching the tool logic. This makes codex-cli fully unusable in any workflow that needs command execution or file access, even read-only.
Steps to reproduce
Run codex.exe exec "" < /dev/null
Observe the error below on the very first tool call, regardless of what the tool call actually does.
Actual error
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")" }
...
ERROR codex_core::tools::router: error=unable to locate image at
<file>: fs sandbox helperfailed with status exit code: 1: windows sandbox failed: helper_unknown_error: setup refresh had errors
Expected behavior
Sandbox helper initializes successfully (or fails with an actionable error naming the missing Windows dependency/feature), and exec_command/file reads work normally under workspace-write sandbox mode.
Notes / what we've ruled out
Not a CLI flag/config issue — this is a lower-level Windows sandbox helper initialization failure, distinct from the (already-fixed) "no active project" confirmation error we hit previously with a different Codex-based agent on the same machine.
We have not tried --dangerously-bypass-approvals-and-sandbox (or equivalent) to isolate whether the sandbox layer itself is the sole blocker, since this instance is driven by an unattended automation pipeline and running without sandbox isn't a safe test to run unattended.
Suspected cause (unconfirmed): a Windows optional feature or permission the sandbox helper depends on (e.g. Windows Sandbox feature, Hyper-V, or app container capability) may not be enabled on this machine. Haven't yet confirmed which one.
Related issues
GitHub's duplicate detector flagged #28278, #28457 and #34928 — all in the same Windows sandbox helper subsystem, but none appear to be the same failure:
#28278 / #28457: the launcher fails to locate the helper executable (error=program not found, or ShellExecuteExW failed... 1223), traced to a PATH/junction mismatch between the visible codex.exe entry point and the real standalone release directory.
#34928: helper crashes with 0xc0000142 (DLL init failure) specifically during the Desktop app's UAC-elevated first-run setup flow.
This issue: the helper is found and launched, but the setup refresh step itself returns helper_unknown_error: setup refresh had errors — a different failure signature, and downstream of where the other three fail. Our install also resolves directly to a versioned bin<hash>\codex.exe path rather than the junction layout described in #28278/#28457, so that specific root cause likely doesn't apply here.
Flagging the overlap in case a maintainer sees a connection we don't, but filing separately since the error text and failure point differ.
Impact
Full loss of function for any automated/headless codex-cli workflow on this machine — it can echo/respond but cannot execute or read files, since 100% of tool calls fail at this layer.