Codex App runtime cache triggers OneDrive FileScanner loop on Windows

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

Codex App package version: 26.616.9593.0

What subscription do you have?

Individual ChatGPT account. Plan details should not matter for this local Windows runtime cache issue.

What platform is your computer?

Microsoft Windows 11 Pro, 10.0.26200, x64

OneDrive version: 26.098.0524.0004

What issue are you seeing?

After Codex App installs its local runtime under:

C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\node_modules\.pnpm\...

Microsoft OneDrive enters a repeated "Looking for changes" loop. The tray UI briefly turns green / says synced, then immediately starts looking for changes again.

This appears to be a local FileScanner / NTFS file ID interaction rather than actual file upload activity:

• OneDrive CPU stays around one logical core (about 8% total CPU on this machine).
• OneDrive writes large volumes of local SyncEngine-*.odl logs, but there is no meaningful upload queue.
• In one measurement, OneDrive wrote about 335 MB of SyncEngine logs in about 15 minutes.
• In another 15-second measurement, OneDrive consumed about 16 seconds of CPU and wrote about 12 MB of SyncEngine logs.

The latest OneDrive logs repeatedly contain scanner-related frames/strings such as:

FileScanner::DetectDuplicateItemByFSIDInternalWindows
FileScanner::FindFileByNameAndRepairFSIDCacheIfRequired
DriveChangeGenerator::HandleRecycledFile

Extracting the high-frequency NTFS File IDs from the newest SyncEngine-*.odl files and resolving them with fsutil file queryfilenamebyid C:\ <file-id> maps them to files inside the Codex runtime .pnpm tree, for example:

C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\node_modules\.pnpm\@pdf-lib+standard-fonts@1.0.0\node_modules\pako\README.md
C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\node_modules\.pnpm\@pdf-lib+standard-fonts@1.0.0\node_modules\pako\index.js
C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\node_modules\.pnpm\readable-stream@2.3.8\node_modules\safe-buffer\LICENSE

Those files have multiple hard links inside the .pnpm tree. Example hardlink list for one file includes:

...\.pnpm\pdf-lib@1.17.1\node_modules\pako\README.md
...\.pnpm\pako@1.0.11\node_modules\pako\README.md
...\.pnpm\node_modules\pako\README.md
...\.pnpm\@pdf-lib+upng@1.0.1\node_modules\pako\README.md
...\.pnpm\@pdf-lib+standard-fonts@1.0.0\node_modules\pako\README.md
...\.pnpm\jszip@3.10.1\node_modules\pako\README.md

What steps can reproduce the bug?

1. Use Codex App on Windows with OneDrive installed and active.
2. Let Codex App install or refresh its local runtime under C:\Users\<user>\.cache\codex-runtimes.
3. Observe OneDrive repeatedly showing "Looking for changes" and consuming about one logical CPU core.
4. Exit Codex App and rename C:\Users\<user>\.cache\codex-runtimes.
5. OneDrive becomes quiet immediately without restarting OneDrive. CPU drops to near idle.
6. Restart Codex App. It installs a new runtime under the same codex-runtimes path.
7. OneDrive immediately starts the repeated "Looking for changes" loop again.

What is the expected behavior?

Codex App runtime installation should not cause OneDrive to enter a persistent FileScanner loop. Ideally Codex should either:

• place large runtime/package-manager hardlink caches in a location that OneDrive is unlikely to scan, or
• provide a documented setting/environment variable to relocate codex-runtimes, or
• avoid a runtime layout on Windows that triggers OneDrive's FSID/hardlink scanner behavior.

Additional information

This does not appear to be caused by actual user files being uploaded. Renaming the Codex runtime cache stops the issue immediately, and Codex App reinstalling the runtime reproduces it immediately.

A local workaround is to redirect C:\Users\<user>\.cache\codex-runtimes to a non-OneDrive-touched NTFS volume via a directory junction, but this is not discoverable and may not be robust across Codex App updates.