Codex Desktop macOS loses local execution: unified exec fails with ENOENT despite unrestricted filesystem access

Open 💬 2 comments Opened Aug 11, 2026 by sosicivona
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 pwd
  • ls against existing local folders
  • launching the bundled Python runtime returned by load_workspace_dependencies
  • apply_patch against 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 16 days ago

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

  • #37594

Powered by Codex Action

KrzysztofSakowski · 11 days ago

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:

CreateProcess: Failed to create unified exec process: No such file or directory (os error 2)

The ChatGPT Desktop app was 26.810.52044 (build 6662). Its bundled codex-code-mode-host existed, 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:

/opt/homebrew/bin/codex

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_command worked again and pwd returned 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:

find "$HOME/.codex/tmp/arg0" -maxdepth 3 -type l -exec ls -l {} \;
test -x /opt/homebrew/bin/codex && echo "Homebrew Codex target exists"