apply_patch fails with Access is denied on mapped/UNC Windows worktrees

Summary

apply_patch fails with Access is denied in a mapped/UNC-backed Windows worktree, while direct file writes in the same directory succeed.

Environment

• OS: Windows
• Codex runtime: codex.exe --codex-run-as-apply-patch
• Workspace path: U:\BAK Cleaner\bak-cleaner
• Trusted project entry resolves to UNC path: \\?\UNC\captive-fs1\Users\rjurgens\BAK Cleaner\bak-cleaner

Minimal Repro

1. Open Codex in a mapped network worktree on Windows (example: U:\BAK Cleaner\bak-cleaner, backed by UNC).
2. Run an apply_patch edit against an existing file, e.g. src/config.rs:

*** Begin Patch
*** Update File: src/config.rs
@@
-            target_path: "W:/",
+            target_path: "W:/".to_string(),
*** End Patch

1. Observe failure from apply_patch:

Failed to read file to update src/config.rs: Access is denied. (os error 5)

1. In the same session and same file, run a direct shell write (PowerShell), which succeeds:

(Get-Content src/config.rs) -replace 'target_path:\s*: "W:/"', 'target_path: "W:/".to_string(),' | Set-Content src/config.rs

Expected

apply_patch should be able to update files that are writable in the current workspace.

Actual

apply_patch returns access denied while normal shell write operations to the same file/path succeed.

Notes

• icacls shows the target file/path is writable for the current user.
• ~/.codex/.sandbox/sandbox.log shows --codex-run-as-apply-patch failures (exit code 1), but no detailed error context.

Could this be a path normalization/permission boundary issue for mapped-drive vs UNC paths in the apply-patch worker?