Windows: granting write access to a directory on a non-system drive breaks exec in projectless tasks

Open 💬 2 comments Opened Aug 24, 2026 by peanutsmighty-source
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.818.41509

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On Windows, in a projectless Codex Desktop task, granting write access to a directory on a non-system drive can cause every subsequent exec command to fail before the process starts.

The failure happens even for Get-Date, before any filesystem write is attempted.

Actual result

The command fails before startup:

CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }

### What steps can reproduce the bug?

## Reproduction

1. Create a new task without selecting a project.
2. Confirm `Get-Date` succeeds.
3. Approve write access to an existing directory on a non-system drive, outside the task workspace (for example, `E:\some-directory`).
4. Do not perform any write.
5. Run `Get-Date`.

### What is the expected behavior?

exec success

### Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 days ago

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

  • #40215
  • #40044
  • #39841
  • #39697
  • #38898

Powered by Codex Action

peanutsmighty-source · 4 days ago

I reviewed #40215, #40044, #39841, #39697, and #38898.

They share the final setup refresh had errors symptom, but this report has a different and reproducible trigger:

  • A new projectless task starts with Get-Date working.
  • Approving write access to an existing directory outside the workspace on a non-system drive causes the next Get-Date to fail before process creation.
  • No write operation is required to trigger the failure.
  • The same location is writable from manually launched PowerShell.
  • The same permission does not reproduce when the task is created with a real project selected.

So this appears to be a permission-refresh regression in the projectless-task path, rather than a general failure to start the command runner.

Keeping this issue open because the permission-transition reproduction and the projectless-vs-project control are not covered by the linked reports.