Codex CLI on Native Windows with PowerShell: Vitest spawn EPERM and frequent fail to apply patch on large edits
What version of Codex CLI is running?
codex-cli 0.118.0
What subscription do you have?
plus
Which model were you using?
gpt-5.4 high fast
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
Windows Powershell
What issue are you seeing?
I am seeing two recurring issues with Codex CLI on native Windows.
- Vitest fails to start inside Codex with:
spawn EPERM
This happens while loading vitest.config.mts, before the tests actually run.
Command:
pnpm exec vitest run --config ./vitest.config.mts tests/int/order-draft-pages.int.spec.ts tests/int/account-pages.int.spec.ts
- Larger edits often fail with:
fail to apply patch
This seems to happen more often when Codex generates a long patch, edits a long file, or makes multiple nearby edits in the same file.
Relevant config:
approval_policy = "never"
sandbox_mode = "workspace-write"
[windows]
sandbox = "elevated"
What steps can reproduce the bug?
Issue 1: spawn EPERM
Steps:
- Run Codex CLI on native Windows.
- Use PowerShell as the shell.
- Use this configuration:
- approval_policy = "never"
- sandbox_mode = "workspace-write"
- [windows] sandbox = "elevated"
- Ask Codex to run:
pnpm exec vitest run --config ./vitest.config.mts tests/int/order-draft-pages.int.spec.ts
- Codex fails during startup while loading
vitest.config.mtswithspawn EPERM.
Important comparison:
- The same command runs successfully in my normal local PowerShell session outside Codex.
- The failure happens when Codex tries to run it.
Issue 2: fail to apply patch
Steps:
- Use Codex CLI on native Windows with the same configuration.
- Ask Codex to make a relatively large edit in a long file, or generate a long patch touching multiple nearby sections.
- Codex frequently returns
fail to apply patchinstead of completing the edit.
What is the expected behavior?
Expected behavior for Issue 1:
- Codex should be able to run the same pnpm/Vitest command successfully if it works in normal local PowerShell, or
- Codex should return a clearer environment-specific error explaining exactly which Windows sandbox restriction is blocking subprocess creation.
Expected behavior for Issue 2:
- Codex should be able to apply larger patches reliably, even for long files or multi-section edits, or
- Codex should provide a more specific error message describing the actual limitation, such as patch size limit, context mismatch, or Windows-specific patch application failure.
Additional information
Additional context:
- This is on native Windows, not WSL.
- I am using PowerShell.
- The Vitest issue appears before test execution, during toolchain/config startup.
- The patch issue is frequent enough to disrupt normal development in larger files.
- Because the same pnpm command works in my normal local PowerShell session, this looks more like a Codex execution/sandbox issue than a project-level pnpm or Vitest issue.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional reproducibility note:
This is still reproducible on the affected machine, including after a full Windows reinstall. The same two problems existed both before and after reinstall:
spawn EPERMwhen Codex tries to run thepnpm exec vitest ...commandfail to apply patchon larger editsI also have another Windows machine where the same Codex CLI workflow does not reproduce either problem.
So the current pattern is:
Because the issue survives a reinstall on one machine but does not reproduce on another, this looks less like a project-level pnpm/Vitest problem or a transient local setup problem, and more like a machine-specific native Windows/Codex interaction.
I was using Codex desktop app on Windows 10 and encountered seemingly the same error, as Codex reported:
After that I set its permissions from "Default Permissions" to "Full Access"
<img width="223" height="133" alt="Image" src="https://github.com/user-attachments/assets/ce90e282-08f9-4888-a4f6-f091beacba74" />
and tried again:
which would indicate a permissions conflict causing the
spawn EPERMproblem.Three months later, the problem persists.
Running in Yolo mode to run tests correctly is overkill.
Is anyone addressing this issue?