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

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 openai/codex#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.