Windows app update broke workspace writes with EPERM inside project dist

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

26.527.7698.0

What subscription do you have?

Plus

What platform is your computer?

window 10

What issue are you seeing?

After the latest Codex Windows app update, Codex can no longer write inside a local project workspace.

Inside Codex, writes to the project fail with EPERM when trying to create files or folders inside the build output directory.

This breaks normal project builds inside Codex.

Important comparison:
Outside Codex, in normal PowerShell, the same project folder is writable and the same kind of write operation works correctly.

So the problem is not the project itself, not the output folder, and not system Node. The failure is specific to Codex on Windows after the update.

What steps can reproduce the bug?

1. Open Codex desktop app on Windows.
2. Open a local project workspace on a secondary drive.
3. Run a build that writes to the project output folder, or run a write test inside Codex.
4. Codex fails with EPERM when trying to create files/folders in the output directory.

Example failure:
EPERM: operation not permitted, mkdir '<project>\\dist\\<subfolder>'

Comparison outside Codex:
Open normal PowerShell in the same project folder and run:
node -e "require('fs').mkdirSync('dist\\\\test-folder',{recursive:true})"

That works outside Codex in the same project path.

What is the expected behavior?

**Codex should be able to write normally inside the local project workspace, including the build output folder, just like it did before the update.

Builds inside Codex should work normally when the same filesystem path is writable outside Codex.**

Additional information

Additional notes:

• Building to an external temporary folder works.
• Building to the project output folder does not work.
• The Codex sandbox was reset and reconfigured successfully, but workspace writes still fail with EPERM.
• Outside Codex, system Node can write to the same folder without problems.
• Windows Defender Protection History did not show an obvious block for the failing write.

Observed behavior suggests a regression in the Windows sandbox/runner behavior introduced by the app update.