Codex Desktop macOS loses local execution: unified exec fails with ENOENT despite unrestricted filesystem access
Environment
- Codex Desktop on macOS
- Local desktop task
- Filesystem permission profile: unrestricted
- Workspace was initially accessible and used successfully
- Additional workspace roots were later granted without resolving the failure
- Affected thread ID:
019febe2-4b22-7e13-a02b-a4e357df6c39 - Date observed: 2026-08-11
Problem
The task can use online Gmail and Google Drive connectors, but it cannot perform any local filesystem operation. Every exec_command invocation fails before the requested command starts.
Exact error:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }
Minimal reproductions attempted
pwd/bin/zsh -c pwd/bin/bash -c pwdlsagainst existing local folders- launching the bundled Python runtime returned by
load_workspace_dependencies apply_patchagainst a project file that had been read successfully earlier
All local process attempts failed. The failure is independent of the target folder and command.
Additional symptoms
codex_app.read_thread_terminal returns:
No app terminal session is attached to this thread yet.
The session skill list includes bundled Browser, Chrome, and Computer Use capabilities, but no corresponding callable local-control tools are exposed in the affected task. Therefore, the task cannot bypass the broken exec layer by inspecting Finder or Photos through Computer Use.
Expected behavior
With unrestricted filesystem access, the task should be able to start a local shell and read authorized local workspace roots, Downloads, iCloud Drive, and other user-authorized locations.
Actual behavior
No local command starts. Online connector calls continue to work.
Why this appears to be a Codex runtime bug
- The failure occurs before command execution.
- It reproduces with multiple valid shell/runtime paths.
- Expanding workspace permissions does not change the result.
- The workspace had been accessible earlier in the same task.
- The error closely matches #20770, #16970, #17240, #29070, and #31533.
Impact
The agent cannot perform a user-authorized task to locate sensitive mortgage documents across Downloads, a computer-migration archive, iCloud Drive, and Apple Photos. It also cannot inspect its own local diagnostics, forcing the user to act as a technical relay.
Areas to investigate
- stale or deleted unified-exec helper paths;
- task-to-local-runtime attachment;
- regeneration of temporary
arg0/ tool-wrapper paths; - terminal-to-thread attachment;
- why installed bundled Computer Use capabilities are listed but not exposed;
- an automatic recovery path when unified exec returns
ENOENT.
Personal names, email addresses, and the macOS account name have been omitted from this public report.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I found a related, but potentially distinct, failure mode on macOS Apple Silicon.
The initial symptom was identical to this issue: every local command failed before the shell started with:
The ChatGPT Desktop app was
26.810.52044(build6662). Its bundledcodex-code-mode-hostexisted, was an executable arm64 Mach-O binary, and the app passed strict code-signature verification. Changing filesystem permissions and reinstalling the Desktop app did not resolve the failure.The decisive diagnostic was the active temporary runtime directory under
~/.codex/tmp/arg0. Its wrappers were symlinks to:That target had been removed when the Homebrew Codex CLI was uninstalled, leaving broken runtime symlinks. Reinstalling the Homebrew Codex cask (
codex-cli 0.147.0) restored the target; after restarting ChatGPT,exec_commandworked again andpwdreturned the workspace path.This may not be the root cause for every affected Mac, especially where the Homebrew target still exists. However, checking the active
~/.codex/tmp/arg0/*wrapper directory and verifying that its symlink targets exist may help distinguish a stale/missing runtime binding from other unified-exec failures.Relevant checks: