Codex Desktop tool exec can fail to spawn shell in WSL-backed thread

[atlantho]

Summary

In a Codex Desktop thread using a WSL-backed workspace, tool execution can enter a state where exec_command cannot start the configured shell. Once this happens, the agent cannot read local files or attachments, even though the underlying Windows/WSL environments are otherwise usable from the user's terminal.

This appears to be a Codex Desktop / sandbox / tool-runtime execution-context issue rather than a normal filesystem permission issue.

Environment

• Codex CLI: 0.143.0
• Codex Desktop on Windows 11
• WSL-backed thread/workspace
• WSL distros involved: Ubuntu 22.04 and Ubuntu 24.04
• Desktop configured to run Codex in WSL

Symptoms

Attempts to read an attached file from the Codex agent fail before the command body runs. For example, trying to read a text attachment with sed failed with:

exec_command failed for `/bin/bash -lc "sed -n '1,260p' <attachment-file>"`: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

Trying an explicit shell path also failed:

exec_command failed for `/usr/bin/bash -lc "sed -n '1,260p' <attachment-file>"`: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

A minimal command can fail the same way:

exec_command failed for `/bin/bash -lc pwd`: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

Why this looks like a Codex tool-runtime issue

• The failure happens before sed, cat, pwd, or similar commands can run.
• The error is about creating the unified exec process, not about the target file.
• The same Windows and WSL environments are usable from the user's terminal.
• The issue has occurred across more than one day, including after a machine reboot, so it does not look like a single stale process.
• Some direct absolute-path tool invocations were intermittently possible earlier in the thread, while normal shell-based tool execution remained broken, suggesting the execution context for Codex tools became inconsistent.

Expected behavior

Codex Desktop should be able to start the configured shell for tool execution in a WSL-backed thread, or report a targeted diagnostic explaining which shell path/context is invalid.

At minimum, reading files in the workspace or attached pasted-text files should not fail because the unified exec runtime cannot locate /bin/bash.

Actual behavior

The tool layer rejects process creation with No such file or directory (os error 2) for shell startup, leaving the agent unable to read local files or attachments.

Related but distinct

This is separate from #31433. That issue concerns rollout files not being indexed in the state DB. This issue concerns exec_command process creation failing in a WSL-backed Desktop thread.

[atlantho]

Additional context that may matter for reproducing this:

This occurred in a normal Codex Desktop chat, not in a user-selected project/repository workspace. There was no explicit project directory opened by the user for this thread.

The apparent working directory shown to the agent was a Codex-generated thread/workspace path under the user's Documents/Codex area, rather than a normal checked-out repository or project root.

That distinction may be important: the failure seems to happen in the Desktop chat/thread execution context, where the tool runner tries to create a shell process for a generated workspace. It may not reproduce the same way in a normal project-backed Codex thread.

[atlantho]

Clarification: although this was a normal Codex Desktop chat without a user-selected project directory, it was still running in the Codex Windows desktop app with WSL enabled as the execution/runtime environment.

So the relevant combination is:

• Codex Windows desktop app
• WSL-backed runtime enabled
• normal chat/thread, not an explicitly opened project/repository
• Codex-generated thread/workspace directory
• tool execution later unable to spawn /bin/bash for exec_command

[github-actions]

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

• Codex Desktop Chrome bridge unavailable: node_repl missing and process launch fails #30889
• Codex Desktop: unified exec process fails after plugin manifest crash #30754
• Codex Desktop macOS does not expose node_repl or bundled Chrome tools despite enabled config #31533

Powered by Codex Action

[atlantho]

Thanks for the duplicate suggestions. I reviewed the linked issues.

This appears related to #30754 and #30889 at the root-cause level: local tool execution fails before shell/runtime startup with No such file or directory (os error 2) / Failed to create unified exec process.

However, I do not think this issue is an exact duplicate, because this report covers a different affected configuration:

• Windows Codex Desktop app
• WSL-backed runtime enabled
• normal chat/thread, not a user-selected project/repository workspace
• Codex-generated thread/workspace directory
• exec_command cannot spawn /bin/bash

#30754 and #30889 appear to cover macOS-centered cases, with emphasis on plugin manifest / Chrome / node_repl failure paths. This issue may be useful as the Windows + WSL-backed normal-chat variant of the same broader unified exec process failure class.

#31533 is related but seems focused more on node_repl/Chrome tool exposure. The issue here is lower-level: shell process creation itself fails, which then prevents even reading local files or attachments.

[mogya]

I encountered the same error in a project-backed Codex thread on Windows:

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

Environment:

• ChatGPT/Codex app version: 26.825.51511
• Release date shown by the app: 2026-08-30
• Agent environment: Windows Subsystem for Linux
• Integrated terminal shell: WSL

WSL and the shells themselves were healthy:

wsl.exe -e /bin/bash -lc 'echo shell-ok; pwd; ls -l /bin/bash /usr/bin/sh'

shell-ok
/mnt/c/Users/mogya
-rwxr-xr-x 1 root root 1540520 Feb 13  2026 /bin/bash
lrwxrwxrwx 1 root root       4 Feb  3  2026 /usr/bin/sh -> dash

The issue was resolved with the following steps:

1. Temporarily changed both the agent environment and integrated terminal shell to values other than WSL.
2. Completely exited the ChatGPT app, including the system tray process.
3. Restarted the app.
4. Changed both settings back to WSL.
5. Retried tool execution.

After that, shell execution, Git commands, and source-file reads all worked again. Both of these paths were accessible:

/mnt/c/users/mogya/develop/my_project
/home/codex/develop/my_project

I did not need to modify config.toml, disable unified_exec, or clear the CODEX_HOME/tmp/arg0 directory.

This suggests that the configured values were correct, but the desktop app may have retained a stale or inconsistent execution-environment state. Toggling the settings and fully terminating the tray process appears to have forced that state to be rebuilt.