Repository navigation
exec_command tool consistently fails with "Failed to create unified exec process: No such file or directory (os error 2)" #20770
Description
Codex bug: exec_command fails with "Failed to create unified exec process"
Suggested title for the issue:
exec_commandtool consistently fails with "Failed to create unified exec process: No such file or directory (os error 2)"
Suggested repo: openai/codex
Description
The exec_command tool fails on every invocation with:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }
This makes it impossible for the Codex agent to run any shell command inside the session — pwd, ls, sqlite3, anything.
Environment
- codex-cli: 0.128.0 (also reproduced on 0.125.0)
- macOS: 14.x (Apple Silicon iMac)
- Shell: zsh 5.9 (default macOS)
- Installed via
npm install -g @openai/codex
Reproduction
- Launch Codex with
codexfrom a fresh Terminal session - Inside Codex, prompt:
Run "pwd" and tell me the result - Codex's LLM invokes the
exec_commandtool - Tool fails with the error above; no shell command executes
Things tried that did NOT fix it
- Updating from 0.125.0 to 0.128.0 (
npm install -g @openai/codex@latest) — the bug persists rm -rf ~/.codex/.tmp ~/.codex/shell_snapshots/*— issue returned in subsequent sessions- Restarting Terminal / opening fresh shells
Diagnostic from ~/.codex/logs_2.sqlite
level=ERROR target=codex_core::session::handlers
error=exec_command failed for `/bin/zsh -lc "<command>"`:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }
The error suggests Codex is trying to spawn a helper binary (unified-exec of some sort) that's missing or unreachable from where it's looking. which zsh returns /bin/zsh cleanly; not a shell-binary issue.
Expected behavior
exec_command spawns the shell, runs the requested command, returns its stdout/stderr.
Workaround
None — the tool is fully blocked. User has to copy-paste commands into a separate Terminal window, defeating the agentic-coding workflow.
Activity
markod0925 commentedon May 3, 2026
Same issue here after the last update
CancanSinger commentedon Jun 2, 2026
在提示词里面，显式说明“提升命令权限”
JoanJuan10 commentedon Jun 2, 2026
Same issue here for me
judeng commentedon Aug 28, 2026
I have the same issue in latest version
kdy1 commentedon Sep 4, 2026
Additional reproduction from a hosted Linux runner (not Codex Desktop or WSL):
Observed on 2026-09-04 from 10:28:57Z through 10:34:30Z.
Environment: a
node:24-bookworm-slim-based Linux container with Codex CLI0.153.2, invoked throughcodex app-serverfor a plan-mode coding task. The image explicitly installs/bin/bash.Within the same running app-server, every observed
exec_commandrequest using/bin/bash -lc ...failed before its requested shell script started. This affected harmless repository-read commands and GitHub CLI read/help commands alike, so it was not specific to one target file, command body, or GitHub authorization state.The repeated error was exactly:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }The app-server remained running long enough to emit subsequent
codex_core::tools::routererrors for more than five minutes. The failure prevented the task from completing its GitHub issue-recording workflow.This was not a Windows/WSL session and the diagnostic did not expose a missing
arg0, helper, command, or working-directory path. I therefore cannot attribute it to the stale-wrapper or Windows setup-refresh variants discussed elsewhere.A useful regression target would be a long-lived Linux
codex app-serverunder the same container base and sandbox settings, repeatedly issuing a benign/bin/bash -lc 'true'tool call and a read-only GitHub CLI call. The current production observation is a reproducible-in-environment report rather than a minimal standalone reproducer.kdy1 commentedon Sep 7, 2026
Hey, openai folks, as I really need this to be fixed, I did some work on this.
https://github.com/openai/codex/compare/main...kdy1:kdy1/linux-unified-exec-enoent?expand=1
Can someone check it?
benjamin-yanh commentedon Oct 12, 2026
Additional diagnostics for a Windows desktop + WSL2 instance of this error (2026-10-12). This may be a different cause from the original macOS report.
Environment
Observed behavior
CreateProcess { message: "Rejected("Failed to create unified exec process: No such file or directory (os error 2)")" }
Key filesystem evidence
The running WSL codex app-server process has an open file descriptor for:
<CODEX_HOME>/tmp/arg0/codex-arg0/.lock
Both that path and its parent directory are missing. The expected codex-linux-sandbox alias in that directory is also missing.
/proc//fdinfo/ still reports an active POSIX ADVISORY WRITE lock from byte 0 to EOF.
The runtime executable under <CODEX_HOME>/bin/wsl//codex exists and runs successfully.
Possible explanation, not a confirmed deletion trace
In codex-rs/arg0/src/lib.rs, all operating systems currently create helpers and run janitor_cleanup in the same CODEX_HOME/tmp/arg0 root. Windows uses native file locking; WSL uses Linux file locking. When CODEX_HOME is shared, another OS's janitor may not recognize a live foreign lock and may remove its helper directory. The missing directory above is consistent with that failure mode, but we did not capture the deleting process. A direct Windows/WSL lock-interoperability experiment could not run because this executor returned Exec format error for powershell.exe.
Suggested change
Namespace helper directories and janitor scopes by OS:
<CODEX_HOME>/tmp/arg0/linux/codex-arg0
<CODEX_HOME>/tmp/arg0/windows/codex-arg0
Preserve existing per-session locks for same-OS cleanup. Do not clean legacy sessions from another namespace. Legacy non-recursive janitors should skip the new namespace directories because those directories have no top-level .lock.
I prepared a small candidate patch based on a9b0815, with regression tests for foreign-namespace preservation and compatibility with the legacy janitor. This is a proposed fix for the shared-CODEX_HOME variant, not a claim to resolve every ENOENT report in this issue.
One separate observation: bwrap is not installed, but unshare -Ur true succeeds. We have not established that this causes the missing helper path.
Candidate validation
The candidate is committed locally as 25a7bb4 (fix(arg0): isolate helper cleanup by operating system). I understand the repository does not currently accept external PRs and am providing this analysis and proposed change through the issue for maintainers to review.
Published candidate patch, standalone regression tests, and validation details:
https://gist.github.com/benjamin-yanh/75b43705494b7525a4c0ede391734b05
This is an independently tested candidate for the shared-CODEX_HOME variant, not a merged fix or an upstream PR. The upstream repository currently restricts PR creation to collaborators.