functions.apply_patch can add files but cannot update existing files in Windows Codex App

Open 💬 1 comment Opened Jun 2, 2026 by YuefengLi

What version of the Codex App are you using (From “About Codex” dialog)?

26.527.60818

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

In Codex Windows Desktop App, functions.apply_patch can create a new file successfully, but fails when updating the same existing file immediately afterward.

The failure is stable and reproducible. The target file exists and is readable from shell commands (ls, sed). The same apply_patch workflow works correctly in Codex CLI inside WSL.

This looks related to the internal functions.apply_patch tool path or filesystem/path mapping in the Windows Desktop App, rather than the patch parser or WSL filesystem itself.

Environment

  • Product: Codex Windows Desktop App
  • Platform: Windows host
  • WSL enabled
  • runCodexInWindowsSubsystemForLinux = true
  • Reproduces in:
  • WSL workspace
  • Windows local workspace
  • Does not reproduce in:
  • Codex CLI running inside WSL
  • The model/tool appears to access Windows local workspace paths through WSL-style paths such as /mnt/c/....

What steps can reproduce the bug?

Run this functions.apply_patch tool call:

*** Begin Patch
*** Add File: /tmp/codex-apply-patch-test.txt
+initial
*** End Patch

Observed: succeeds.

Then immediately run:

*** Begin Patch
*** Update File: /tmp/codex-apply-patch-test.txt
@@
-initial
+updated
*** End Patch

Observed: fails with:

apply_patch verification failed: Failed to read file to update /tmp/codex-apply-patch-test.txt: No such file or directory (os error 2)

Shell verification after the failure:

ls -la /tmp/codex-apply-patch-test.txt
sed -n '1,5p' /tmp/codex-apply-patch-test.txt

Both commands succeed. The file exists and contains:

initial

What is the expected behavior?

functions.apply_patch should be able to update an existing file that it just created, especially when the file is visible and readable from shell commands in the same session.

Additional information

Things Already Tried

The issue persisted after:

  • Reinstalling Codex Windows Desktop App while keeping user data.
  • Removing and regenerating:
  • .sandbox
  • .sandbox-bin
  • .tmp
  • Removing app state/cache files/directories:
  • .codex-global-state.json
  • .codex-global-state.json.bak
  • state_5.sqlite
  • cache/
  • shell_snapshots/
  • Restarting Codex App.
  • Testing both WSL workspace and Windows local workspace.

Related Issues

This may be related to, but appears distinct from:

#17240: intermittent tool path/runtime loss in long sessions.
#17778: functions.apply_patch fails while shell invocation works.
#21117: sandbox retry duplicate approval/hanging app-server turns.
This issue differs because Add File works reliably, but Update File fails reliably on an existing file, while shell access to that file remains healthy.

Hypothesis

The Windows Desktop App's internal functions.apply_patch update path may be resolving existing files through a different filesystem view than the shell tool uses.

In particular, even Windows local workspaces appear to be accessed by the model/tooling via WSL-style paths such as /mnt/c/.... This may point to a Windows App + WSL path mapping issue in the internal apply_patch tool bridge.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗