Windows Desktop: apply_patch intermittently fails or hangs when updating existing files with split writable roots

Component

Codex Desktop on Windows, local project task.
Version: 26.810.7004.0

Describe the bug

apply_patch is unreliable when updating or deleting existing files.

Observed behavior:

• Creating a new file often succeeds.
• Updating an existing tracked file may fail before the patch is applied.
• Some operations remain active for minutes even after the UI reports that the file was edited.
• Updating a temporary copy may succeed while updating the original file fails.
• Delete-and-recreate can succeed after a normal update fails.
• The agent may repeatedly misdiagnose the failure as a file lock, although the exact failure is not consistently identified.

The task environment contains more than one writable root:

• The local project workspace.
• A .codex\visualizations\... writable root.

This resembles the split writable root failures reported in #34970 and #35864.

Steps to reproduce

1. Open a local Git repository in Codex Desktop on Windows.
2. Start a local project task with the visualization writable root present.
3. Ask Codex to update one or two lines in an existing tracked source or Markdown file using apply_patch.
4. Repeat the operation on another existing file.
5. Compare the result with creating a new file or updating a temporary copy.

Expected behavior

apply_patch should update and delete existing files reliably, or return the exact filesystem/helper error immediately.

The agent should not classify an unknown write failure as a file lock without checking the actual error.

Additional information

Normal Git operations and file reads work.
The configured project has Full Access/elevated local execution.
The issue is intermittent, so the exact helper error is not always surfaced.

Related issues:

• #34970 — apply_patch fails on Windows with multiple writable roots
• #35864 — split writable roots break apply_patch update/delete
• #34290 — intermittent multi-minute apply_patch hangs
• #38992 — Codex misdiagnoses permission failures as file locks