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:

Open an existing local project in Codex Desktop.
Use workspace-write with the native Windows elevated sandbox.
Ask Codex to update an existing ordinary text file using apply_patch.
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:

[Windows] Sandbox: Access denied on existing workspace descendants after sandbox SID change #46213 — workspace descendant access failures after a sandbox SID change.
Windows sandbox: race condition with the cap_sid file update. Multiple Codex CLI instances race to write that file - last one wins and workspaces become unwriteable #33741 — capability-SID race; a comment also reports false reparse-point errors.
[Windows][Codex Desktop] Existing task retains deleted workspace path after project folder is moved #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.

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.

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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Windows] Sandbox: Access denied on existing workspace descendants after sandbox SID change #46213

Powered by Codex Action

Additional reproduction on codex-cli 0.155.0-alpha.9.2, Windows 10 22H2 build 19045.7725 (native Windows).

The built-in apply_patch tool still rejects an existing ordinary file before reading/writing it with "path contains a reparse point", even after the exact workspace was explicitly included in writable roots. The source stayed unchanged. Sampled ancestors had no filesystem reparse attributes, and the resolved final path matched the expected file.

A read-only reproduction of the matching release's NtCreateFile call (FILE_OPEN, read access, OBJ_DONT_REPARSE retained) returned 0xC000050B for ordinary files on both C: and a second local drive. No protection flag was removed and no alternate-path write was attempted.

Important distinction: earlier sandbox setup logs contained SetNamedSecurityInfoW error 5; later setup refresh receipts reported errors=[]. The visible patch tool trace does not expose attempt.sandbox_requested, initial bypass, or fallback routing, so the trigger selecting no-follow is still unproven. This is not a claim that every ACL error has the same cause.

Installed source reference: https://github.com/openai/codex/blob/4607249e430dac1c961df4dc615beae88e33cec8/codex-rs/exec-server/src/no_follow/windows.rs

Could a maintainer provide a supported diagnostic for the patch sandbox route, or point to a verified fix that preserves actual symlink/junction protections? This blocks authorized local source edits. Full-access, recursive ACL changes and alternate writers are not proposed as fixes. No private project paths, source files, credentials or session logs are included here.

Additional affected case on Codex CLI 0.156.0, Windows 10 Home build 19045, native elevated sandbox, in an existing project on a local fixed NTFS D: drive.

The project root is 85 characters and the existing TXT target's full path is 104 characters. Every path component from D:\ to the file has empty LinkType/Target and lacks the ReparsePoint attribute. fsutil reparsepoint query on both the project root and target file says The file or directory is not a reparse point. Nevertheless, the normal sandboxed apply_patch Update File failed with path contains a reparse point. Direct invocation of the same Codex patch executable outside the failing sandbox processed a minimal no-op Update File against that same path. No Delete+Add replacement was needed.

This machine also has a separate, confirmed command-start blocker: elevated-sandbox refresh sometimes fails while validating a 291-character path in Codex's own CUA Node runtime cache, before shell creation (helper_unknown_error: setup refresh had errors). I added the details to #46388. I cannot establish from available logs whether that refresh failure causes the false reparse-point error or whether the patch path validator has an independent issue. After refresh is fixed, an in-sandbox Update File should be retested to distinguish the two.

Regression-test status update (2026-09-23): after downgrading the installed CLI to 0.154.0 (confirmed by both codex.exe --version and npm metadata), the same Windows native elevated sandbox completed 12/12 independent read-only commands and 13/13 sandbox refreshes with errors=[]. No new setup refresh had errors or reparse-point messages appeared during this test window; the 291-character CUA Node runtime path and LongPathsEnabled = 0 remain unchanged. Full command-start findings are posted to #46388.

This does not demonstrate that the false reparse-point patch error is fixed on 0.154.0. The test did not execute apply_patch or any Update File against an existing file. That write-path regression remains to be tested separately with an authorized, recoverable workspace file.

Follow-up to my earlier 0.154.0 read-only regression comment: the apply_patch write-path test has now been completed. This supersedes only my earlier statement that no Update File test had yet been run.

On the same local NTFS workspace with Codex CLI 0.154.0, I used Add File to create a dedicated ordinary probe file (codex_apply_patch_ntfs_probe.txt), then used only Update File on that existing path to change phase=created to phase=updated. Both patch operations succeeded. No Delete File, delete/recreate, or move/replace operation was used.

Before and after the update, the volume was NTFS, the file had ordinary Archive attributes, LinkType and Target were empty, and fsutil reparsepoint query said it was not a reparse point. The final content was solely phase=updated; phase=created was absent. SHA-256 changed from CB0B366B3A454DC76091013AE4E701EC8E0A0B58B70C2F32A5977BD62F46DEE7 to 4E5910BAB855BDD551342E8469C60CF3AE23D27C87265DE80327481810F1496A. The sandbox-log window for this write test contained zero setup-refresh errors, CreateFileW failed messages, or reparse-point errors.

Conclusion limited to this probe: 0.154.0 successfully updated this ordinary NTFS file without a false reparse-point report. This does not prove that the intermittent patch failure is permanently fixed for all existing files or that the separate 291-character CUA Node runtime-path problem is resolved.

Still reproducible on 2026-09-27 with Codex Desktop 26.924.22138 (build 11645, prod channel) and bundled codex-cli 0.158.0-alpha.2.1, native Windows / PowerShell.

An integrated apply_patch no-op update of an existing ordinary Markdown file in an authorized local workspace fails with Failed to read file to update ...: path contains a reparse point. Relative, absolute drive-letter, and verbatim Windows paths all failed. A patch with mismatched context instead reached the expected-line verification error. Direct invocation of the installed codex.exe --codex-run-as-apply-patch successfully applied the same no-op patch; before/after SHA-256 was identical.

Get-Item checks for the file and every filesystem ancestor showed no ReparsePoint attribute; fsutil checks likewise reported no filesystem reparse points.

A separate read-only NtOpenFile probe reproduced the namespace distinction:

DesiredAccess: FILE_READ_ATTRIBUTES (0x80)
ShareAccess: READ | WRITE | DELETE (7)
OpenOptions: FILE_OPEN_REPARSE_POINT (0x00200000)
ObjectAttributes: OBJ_CASE_INSENSITIVE (0x40), with/without OBJ_DONT_REPARSE (0x1000)
RootDirectory: NULL

For the same existing file:

Native path	Without OBJ_DONT_REPARSE	With OBJ_DONT_REPARSE
`\??\C:\<workspace>\<file>`	0x00000000	0xC000050B
Device path resolved with QueryDosDevice(C:)	0x00000000	0x00000000

This corroborates a DOS-drive/native-namespace no-follow problem, but is not an instrumented trace of the integrated tool. Exact flag propagation and sandbox-route selection in this bundled version have not been verified. No ACLs, settings, filesystem mappings, or protections were changed. Please retain protection against real filesystem symlinks/junctions in any fix.

Project paths and contents have been omitted intentionally.

Additional redacted affected case observed on 2026-09-27 in a separate authorized native-Windows local workspace.

The integrated apply_patch path rejected an existing ordinary source file before modification with:

Failed to read file to update …: path contains a reparse point

Observed facts:

both the normal workspace-relative form and the approved absolute drive-letter form were rejected with the same message;
read-only Windows metadata reported the target as an ordinary file with ReparsePoint=false;
every inspected filesystem ancestor also reported no ReparsePoint and no link target;
the repository remained clean and the tracked source bytes were unchanged after the failed attempts;
no alternate writer, delete/recreate, path relocation/new checkout, ACL/configuration change, Full Access, downgrade, or direct --codex-run-as-apply-patch workaround was used.

This is a symptom match to this issue, not a claim that the same root cause has been instrumentally proven. The exact app/backend build that executed this particular failed integrated patch call was not captured, so I am intentionally not inferring its version from another executable or session.

Could a maintainer provide either:

a supported diagnostic that identifies which integrated patch/no-follow/sandbox route is being selected on Windows, or
a verified supported remedy that allows normal Add/Update of ordinary files while preserving protection against real symlinks/junctions?

A suitable recovery check on our side would be to verify the same integrated tool on an explicitly authorized disposable fixture first, before re-entering the blocked source-edit workflow.

No private project paths, source content, credentials, archives, or session transcripts are included here.

Public-source follow-up to my affected-case report #46290 (comment) — no additional local probes or private project data.

I found merged PR #47672, commit 5f371ba30ae4a4bf4527eb0729ab6b36e3a0c123 (2026-09-23). Its two changed files are the Windows sandbox directory-opening helper and its tests. It resolves the drive-letter alias with QueryDosDeviceW while retaining rejection of filesystem reparse points:
#47672

The separate file-operation implementation relevant to the error discussed here is codex-rs/exec-server/src/no_follow/windows.rs. In the public rust-v0.157.1 source, nt_path() still constructs a drive-letter \\??\\ path, open_handle() applies OBJ_DONT_REPARSE, and the STATUS_REPARSE_POINT_ENCOUNTERED branch emits the reported error:
https://github.com/openai/codex/blob/rust-v0.157.1/codex-rs/exec-server/src/no_follow/windows.rs
Blob observed: 14a3db30a9feb76cb0fe22ea7e07951d999957c9.

I also checked that tag's windows-sandbox-rs/src/no_reparse_dir.rs: the inspected function still has the older drive-letter conversion, rather than the implementation shown in #47672. Thus neither PR merge date nor a numerically different installed CLI proves that the relevant fix is present in the integrated tool's actual backend. These are source observations, not an instrumented diagnosis of the affected application and not a recommendation to downgrade to 0.157.1.

Could a maintainer clarify whether #47672 covers the integrated apply_patch file-opening route, or whether the equivalent fix for exec-server/no_follow/windows.rs is tracked separately, and identify an officially shipped App/backend build suitable for verifying this? The desired recovery retains real symlink/junction protection. No alternative-path writes, direct writer bypasses, ACL/security changes, custom binary build or additional patch retries were performed.

Follow-up: the existing-file patch failure recurred on Codex CLI 0.157.1 (2026-09-27), in a second Windows project directory on D:. This is a write-path attempt, unlike my preceding 0.154.0 read-only regression test.

Target operation: append a new session at the confirmed EOF of an existing Development_Log.md using a single Update File patch. The patch tool failed after about 8.3 seconds with exit code 1, before content matching or writeback:

Failed to read file to update D:\work\<project>\Development_Log.md: path contains a reparse point

Read-only checks afterward:

Resolve-Path returned the same expected project path.
Get-Item -Force reported Attributes: Archive, empty LinkType, empty Target, size 94,368 bytes, and the prior last-write time (2026-09-27 06:04:22 local).
Checking the target and each parent directory with PowerShell found no ReparsePoint attribute.
An exact search found zero occurrences of the new session header; the file still ended with the preceding session. No partial append, truncation, or overwrite was observed.

The project's editing rule required stopping after this first failed Update File, so there were no additional write attempts or alternative write mechanisms. The intended text was given to the user for manual EOF append.

This confirms that the patch tool's reparse-point verdict conflicts with the checked PowerShell metadata on 0.157.1. The present check did not include an fsutil reparsepoint query for this second project and does not reveal the patch tool's internal path-resolution result; I cannot yet identify whether workspace mapping, sandbox state, or no-follow handling produces this verdict. A separate 0.157.1 command-start setup refresh had errors recurrence is documented on #46388, without evidence that the two failures share one root cause.

I reproduced this false path contains a reparse point error on the current bundled backend 0.159.2, and found an additional Windows security-state angle that may explain at least some remaining cases after the no-reparse fix.

Key A/B result in one repository:

root-level file: built-in apply_patch -> PASS
fresh nested directory: built-in apply_patch -> PASS
old existing tests\ directory: built-in apply_patch -> FAIL with path contains a reparse point
fsutil reparsepoint query on both tests\ and the target file -> not a reparse point
sandboxed PowerShell Get-Content and Set-Content on the exact same target file -> PASS

The old failing physical tests\ directory was owned by CodexSandboxOffline and had different historical sandbox ACL/capability state. A freshly-created sibling directory was owned by the normal user and inherited the current Codex ACLs.

Recovery:

Create tests2\ as the normal host user.
robocopy tests tests2 /E /COPY:DAT /DCOPY:DAT (do not copy security metadata).
Verify every copied file by relative path + length + SHA-256.
Confirm apply_patch works in tests2\.
Move old tests\ outside the repo as rollback backup.
Rename tests2\ to tests\.
Re-verify SHA-256 and git status.
Re-test apply_patch before and after a full Codex Desktop restart.

Result: apply_patch continued to work after restart, with identical repository file contents.

Detailed ownership/ACL reproduction was added to #17179. This does not prove whether ownership alone, a stale capability ACE, or the combination is the decisive trigger, but it shows the false reparse diagnostic can persist on 0.159.2 and can be tied to stale per-directory sandbox security state rather than an actual reparse point.

I am experiencing what appears to be the same reparse-point protection issue described here.

Important note: I am not a programmer or Windows security expert. This comment was written by ChatGPT based on my observations, screenshots, and PowerShell results. ChatGPT guided me through the diagnostic steps. I cannot independently verify the technical cause of the problem.

My environment

Windows 10 Pro, version 22H2, build 19045.6466
ChatGPT Windows desktop app, version 26.1002.52244 (released October 7, 2026)
Codex and ChatGPT Work used through the desktop app
Native Windows environment, not WSL
%USERPROFILE%\.codex\config.toml contains [windows] sandbox = "elevated"
Projects located on drive G:\, identified by Windows as a local NTFS volume (DriveType = 3, no network provider)

What happens

Both Codex and ChatGPT Work have encountered problems using their normal patch functionality when modifying files in my projects.

For example, during a ChatGPT Work documentation update, three Markdown files were rejected:

Abgelehnt 00 Aktueller Projektstand.md
Abgelehnt 02 Landkarte, Bewegung und LK-UK.md
Abgelehnt 12 Gebäude, Bauen und Gebäude-UK.md

Work then reported:

Die vorgesehene Patch-Funktion kann diese Windows-Arbeitsmappe wegen eines Reparse-Point-Schutzes nicht öffnen.

In English: The intended patch function cannot open this Windows workspace because of reparse-point protection.

Work subsequently used controlled in-memory text replacements with unique text anchors, which succeeded.

Similar patch-related problems have occurred during Codex development tasks.

I do not have the exact lower-level sandbox error message. The message quoted above was generated by Work.

Checks performed with ChatGPT's guidance

I used Windows PowerShell to inspect:

The root of drive G:\
Both affected project directories
The relevant documentation subdirectory
One of the affected Markdown files

The directories showed normal Directory attributes, and the Markdown file showed Archive. None of the inspected paths showed a ReparsePoint attribute. LinkType was empty and Target was {}.

I also checked for the sandbox log at:

%USERPROFILE%\.codex\.sandbox\sandbox.log

The file was not found at that location.

These checks do not prove that the sandbox's reparse-point detection is incorrect. They only establish what Windows reported for the inspected paths.

Diagnostic session reference

I submitted feedback directly from an affected ChatGPT Work session, including ChatGPT diagnostic logs.

Session / Feedback ID:

01a07ba2-675a-7083-a152-2d833ec0dff1

This identifier was also found in the corresponding local rollout-...jsonl session filename.

The earlier example of three rejected Markdown files may come from a different Work session.

Request

Could you investigate whether this is related to the same Windows path-handling issue described here, or whether a separate workspace permission or sandbox restriction is involved?

I would prefer not to weaken the sandbox security settings or restructure my projects without understanding the cause.

I am happy to perform simple, safe diagnostic steps if you provide clear instructions. However, I will need guidance because I do not have a programming background.

Thank you for looking into this.

fix(win32): map DOS drive roots before guarded file opens (#450)

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

My environment

What happens

Checks performed with ChatGPT's guidance

Diagnostic session reference

Request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 17, 2026

anilkrk commented on Sep 21, 2026

hararly-web commented on Sep 23, 2026

hararly-web commented on Sep 23, 2026

hararly-web commented on Sep 23, 2026

ubupl commented on Sep 27, 2026

smakeev78-byte commented on Sep 27, 2026

smakeev78-byte commented on Sep 28, 2026

hararly-web commented on Sep 28, 2026

dariokraljevic-design commented on Oct 1, 2026

rauberradischen-ship-it commented on Oct 9, 2026

My environment

What happens

Checks performed with ChatGPT's guidance

Diagnostic session reference

Request

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions