Codex tool runtime intermittently loses `apply_patch` path and fails with `No such file or directory`

What version of the IDE extension are you using?

Version 26.406.31014

What subscription do you have?

Plus

Which IDE are you using?

VSCode

What platform is your computer?

Linux 6.18.21-1-cachyos-lts x86_64 unknown

What issue are you seeing?

Summary

During a single Codex session, the apply_patch tool intermittently becomes unavailable. Calls that previously worked start failing with No such file or directory, and the resolved path to apply_patch appears to change between invocations.

Similar failures also occasionally affect other shell-based tool calls, even when the referenced files definitely exist.

Environment

• Long-lived Codex session
• Multiple repositories used in the same session
• Repository paths were moved/changed earlier during the workflow
• Files and directories referenced by the commands did exist and were readable

What happened

I was working across repositories in the same session and using apply_patch normally. At some point:

• built-in patch application started failing
• error reported No such file or directory
• files targeted by the patch definitely existed
• later, running which apply_patch returned a different path than before
• manually invoking the newly discovered apply_patch path worked again

There were also moments where ordinary shell commands failed with No such file or directory even though the files and directories were present and accessible.

Exact error messages

Primary apply_patch/runtime error:

execution error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Shell/tool process creation error:

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

Example full shell-tool failures:

exec_command failed for `/usr/bin/bash -lc "sed -n '1,220p' ansible/host_vars/pts-onedev-r1/main.yml"`: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

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

Repeated low-level failure:

execution error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Evidence of unstable apply_patch path

At different moments in the same session, which apply_patch returned different paths, for example:

~/.codex/tmp/arg0/codex-arg0c1jJCG/apply_patch

and later:

~/.codex/tmp/arg0/codex-arg09jUUn5/apply_patch

This suggests that the previously resolved temporary tool path became invalid and a new one appeared during the same session.

Workaround

Temporary workaround:

1. Run which apply_patch
2. Use the newly returned path manually for patch application
3. Continue until the path becomes stale again

This workaround restores functionality temporarily, but does not solve the underlying issue.

Why this looks like a Codex/runtime bug

• The repositories and files were valid.
• The issue was not tied to a specific target file.
• The executable path to apply_patch appeared unstable within the same session.
• The problem could be worked around by rediscovering the current apply_patch path.
• Similar instability appeared in shell-based command execution as well.

This suggests session-local tool path rotation, stale tool path caching, or invalidation of the unified execution environment during long sessions.

Suggested areas to investigate

• Session-local temporary tool path lifecycle
• Stale tool path caching between tool invocations
• Context or repository switching effects on developer tool execution
• Unified exec process environment invalidation during long sessions
• Whether temporary tool directories are being rotated without downstream consumers refreshing their resolved paths

What steps can reproduce the bug?

Steps to reproduce

These are the closest reproducible conditions observed during the session:

1. Start a long-lived Codex session on Linux.
2. Work across multiple repositories in the same session.
3. Use apply_patch successfully several times.
4. Change context between repositories and continue editing files.
5. Attempt another patch or shell-based file read/edit operation.
6. Observe that a previously working tool invocation may now fail with No such file or directory.
7. Run which apply_patch.
8. Notice that the resolved path may differ from the one used earlier in the same session.
9. Manually invoke the newly resolved apply_patch path and observe that it works again temporarily.

Observed behavior details

• Built-in patch application starts failing unexpectedly.
• The failure is not tied to one specific file.
• The targeted files exist.
• The path to apply_patch appears unstable within a single session.
• The issue can sometimes be worked around by rediscovering the current apply_patch path.

What is the expected behavior?

Expected behavior

• apply_patch should remain callable for the full session
• tool resolution should be stable within a session
• patch execution should not fail with No such file or directory when the target file exists and the tool was previously available
• shell-based tool invocations should not fail on valid existing paths because of runtime instability

Actual behavior

• apply_patch works initially
• later fails with No such file or directory
• re-checking the executable location gives a different temporary path
• manually using the updated path restores functionality temporarily
• some shell/tool executions also fail with process creation errors even when the repository files exist

Additional information

_No response_