Windows 10: apply_patch reports false reparse-point errors; read-only no-follow reproduction

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

Desktop app version: 26.908.70816 Bundled backend/session cli_version: 0.154.0-alpha.6.2

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64 Windows 10 Pro, version 22H2, build 19045.6456 Native Windows / PowerShell, not WSL.

What issue are you seeing?

The built-in apply_patch tool repeatedly fails when updating existing ordinary files inside authorized local workspaces.

Representative error, with the project path anonymized:

Failed to read file to update X:\Codex<project><file>: path contains a reparse point

The error occurs across three separate projects. Operations do not fail consistently, which makes the problem appear intermittent and causes repeated retries or changes of editing mechanism.

Verified filesystem observations:

• X: is a fixed local NTFS volume, not a mapped network drive.
• Windows reported no reparse-point attributes on the sampled affected files or their parent directories.
• fsutil reparsepoint query reported that the sampled files were not reparse points.
• The workspace roots grant Modify access to CodexSandboxUsers. This alone does not establish the effective permissions of every restricted token or descendant file.
• Both ordinary and \?-prefixed saved project roots occur among the affected projects. One affected project has an unprefixed saved root.

The investigation also reproduced the relevant low-level Windows error using read-only file opens, as described below. This points to a no-follow path-resolution problem, but does not establish that every historical patch failure had the same upstream trigger.

What steps can reproduce the bug?

Application observations:

1. Open an existing local project in Codex Desktop.
2. Use workspace-write with the native Windows elevated sandbox.
3. Ask Codex to update an existing ordinary text file using apply_patch.
4. Some attempts fail while reading the file, with “path contains a reparse point”.

These application steps are not claimed to fail on every attempt.

Read-only diagnostic reproduction:

A diagnostic reproduced the NtCreateFile parameters used by the matching release's Windows no-follow implementation:

• Path: ??\X:<existing ordinary file>
• DesiredAccess: FILE_GENERIC_READ | SYNCHRONIZE
• RootDirectory: NULL
• ObjectAttributes: OBJ_CASE_INSENSITIVE | OBJ_DONT_REPARSE
• CreateDisposition: FILE_OPEN
• CreateOptions: FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT
• ShareAccess: FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE

Results:

A. Drive-letter native path, OBJ_DONT_REPARSE enabled:
0xC000050B — STATUS_REPARSE_POINT_ENCOUNTERED

B. Same path, OBJ_DONT_REPARSE disabled:
0x00000000 — success

C. Same file addressed through the device path obtained from QueryDosDevice,
with OBJ_DONT_REPARSE still enabled:
0x00000000 — success

These results were reproduced for sampled files in all three affected projects on X:, and for an ordinary file on C:.

The diagnostic opened existing files for reading only. It did not change their contents, ACLs, or attributes.

What is the expected behavior?

apply_patch should be able to update authorized ordinary files on local Windows volumes.

The no-follow implementation should handle normal Windows drive/device namespace resolution while retaining protection against actual filesystem symlinks and junctions.

If access is denied or sandbox preparation fails, the diagnostic should identify that failure accurately rather than suggesting that an ordinary project directory contains a filesystem reparse point.

Additional information

Related reports already describe the same or similar symptom:

• #46213 — workspace descendant access failures after a sandbox SID change.
• #33741 — capability-SID race; a comment also reports false reparse-point errors.
• #41776 — stale workspace binding after moving a project.

I am not claiming this symptom is previously unreported. This report adds a controlled read-only reproduction of a potentially shared downstream failure. Please consolidate it if that mechanism is already tracked.

Source examined: rust-v0.154.0-alpha.6.2, matching the backend version recorded in the affected sessions.

1. Windows no-follow implementation:
   https://github.com/openai/codex/blob/rust-v0.154.0-alpha.6.2/codex-rs/exec-server/src/no_follow/windows.rs#L78

nt_path() converts both ordinary drive-letter paths and verbatim drive-letter paths to the ??\ namespace. open_handle() uses OBJ_DONT_REPARSE and translates STATUS_REPARSE_POINT_ENCOUNTERED into “path contains a reparse point”.

The diagnostic results isolate the failing behavior to the drive-letter/native-namespace form: the same file opens successfully through its device path while retaining the no-reparse flag.

2. Patch runtime:
   https://github.com/openai/codex/blob/rust-v0.154.0-alpha.6.2/codex-rs/core/src/tools/runtimes/apply_patch.rs#L181

The runtime selects follow_symlinks based on the sandbox attempt. This offers a possible explanation for execution-route-dependent behavior, but the routing of every historical failure has not been reconstructed.

Limitations:

• This was a source comparison plus a reproduction of the Windows API call, not an instrumented build of Codex.
• It does not rule out separate ACL or sandbox-setup problems that could cause Codex to select the failing route.
• No patched Codex build or proposed fix has been tested.
• Removing reparse-point protection is not being proposed as the fix.

Start by reading codex-rs/exec-server/src/no_follow/windows.rs around nt_path() and open_handle(), then compare the follow_symlinks selection in codex-rs/core/src/tools/runtimes/apply_patch.rs. Reproduce the read-only native-path and device-path opens described in the issue. Done means authorized ordinary files can be handled on Windows while actual symlink and junction protection remains intact and failures are reported accurately.