Windows: Codex-created node_modules junctions in OneDrive folders trigger severe handle leak

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

26.825.6671.0

What subscription do you have?

PRO

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On Windows with OneDrive Known Folder Move enabled for Documents, Codex artifact/runtime tasks created NTFS directory junctions named node_modules inside OneDrive-backed output and temporary directories. These junctions pointed into the shared Codex runtime cache under %USERPROFILE%\.cache\codex-runtimes.

OneDrive Files On-Demand then entered a repeated placeholder-conversion loop involving paths that shared the same filesystem identities.

Impact and evidence

• OneDrive.exe reached approximately 1.63 million handles—about 88% of all system handles—and continued growing by roughly 60–600 handles per second.
• Total system handles reached approximately 1.86 million.
• OneDrive continuously consumed approximately one CPU core.
• Windows recorded RADAR_PRE_LEAK_64 for OneDrive.
• The entire Windows session became sluggish; opening the screenshot interface took about five seconds.
• OneDrive generated approximately 100 MB of diagnostic logs in 37 seconds.
• ODL signatures included:
  • FileSyncFALWB / WinboxConvertToPlaceholder / UnexpectedFailure
  • Realizer::StartBatchOperationIfNeeded
  • Odfs::-2
  • duplicate-FSID reports

Four Codex-generated junction entries were found in OneDrive-backed output/temp directories. The currently active Documents\Codex workspace itself was not implicated.

Workaround and verification

I moved only those four junction entries outside the OneDrive tree and reset/restarted OneDrive. Their target files and the shared runtime cache were not removed.

Afterward:

• OneDrive stabilized around 1,800 handles with no upward trend.
• Total system handles returned to approximately 245,000.
• CPU, memory, SSD, GPU, Explorer, and DWM behavior returned to normal.
• No recurrence was detected during extended monitoring.
• No data loss was observed.

I did not intentionally recreate the junctions afterward because doing so had caused system-wide resource exhaustion.

Expected behavior

Codex should detect OneDrive/Known Folder Move/cloud-synced paths and avoid creating dependency junctions there. It should instead use an unsynced local staging directory, copy dependencies, or clearly warn the user.

Possibly related

• #35745: Windows skills creating node_modules junctions to the shared runtime
• #28729: Warning or blocking development workspaces inside cloud-synced folders

What steps can reproduce the bug?

Reproduction conditions

I did not intentionally recreate the problem after remediation because it caused system-wide resource exhaustion. The following conditions and sequence were observed:

1. Enable OneDrive Known Folder Move for Windows Documents and Files On-Demand.
2. Run a Codex artifact task inside an existing OneDrive-backed folder that requires the bundled Node workspace dependencies.
3. Codex creates one or more NTFS junctions with a layout equivalent to:

%OneDrive%\Documents\<project>\<task-output-or-temp>\node_modules
  -> %USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\node_modules

4. Leave OneDrive running so that Files On-Demand scans the junction-backed files.
5. Monitor OneDrive's handle count with this bounded PowerShell diagnostic:

1..15 | ForEach-Object {
    Get-Process OneDrive |
        Select-Object Id, ProcessName, Handles, CPU
    Start-Sleep -Seconds 2
}

6. The OneDrive handle count begins increasing continuously while its diagnostic logs repeatedly report placeholder-conversion failures and duplicate filesystem identities.
7. Windows responsiveness progressively degrades.

The original incident involved four such junction entries. After moving only those junctions outside OneDrive and restarting OneDrive, the handle growth stopped immediately.

What is the expected behavior?

Codex should not create dependency junctions inside OneDrive Known Folder Move or another cloud-synchronized root.

When a task needs the shared runtime, Codex should use an unsynced local staging directory, copy or otherwise safely resolve the required dependencies, or clearly warn the user before creating an incompatible filesystem layout.

OneDrive scanning a Codex-generated task directory should not result in unbounded handle growth or system-wide performance degradation.

Additional information

Environment

• Windows 11 Pro 25H2, build 26200.9168, x64
• Codex desktop app 26.825.6671.0
• OneDrive 26.153.0809.0004
• Documents protected by OneDrive Known Folder Move
• Files On-Demand enabled

The active Documents\Codex workspace was not implicated. The affected junctions were located in separate, pre-existing OneDrive-backed output and temporary directories.

After remediation, OneDrive remained stable around 1,800 handles for more than 45 minutes. Its diagnostics reported zero pending changes, stalls, realizer errors, or resyncs. No data loss was observed.

I can provide redacted process samples, junction metadata, Windows event records, and OneDrive diagnostic excerpts if needed.

Token/context-window usage: Not applicable; this was a local filesystem and OneDrive Files On-Demand interaction.

Possibly related:

• https://github.com/openai/codex/issues/35745
• https://github.com/openai/codex/issues/28729

No source file or test is named. Start by reading related issues #35745 and #28729, then trace Windows artifact/runtime dependency junction creation; use the bounded PowerShell OneDrive diagnostic rather than intentionally reproducing the resource exhaustion. Done means Codex avoids junctions under OneDrive Known Folder Move or another cloud-synced root and provides a safe alternative or warning.