What version of the Codex App are you using?
Codex Desktop 26.715.10079.0 (Windows), embedded CLI/core reports client_version 0.145.0 in models_cache.json. Signed in with a ChatGPT account. config.toml has [windows] sandbox = "unelevated".
What platform is your computer?
Windows 11 Home 10.0.26200 — Node v22.23.1 (fnm), pnpm 9.12.3.
What issue are you seeing?
The Windows unelevated sandbox blocks child process creation with spawn EPERM, which makes any Node toolchain that forks workers unusable inside the sandbox: next dev, next build (Next.js 15), and esbuild all fail the moment they call child_process.fork()/spawn(). This has been recurring in our workflows since early June 2026; the local log DB (which only retains ~10 days) shows spawn-EPERM entries every single day:
| date (UTC) |
log entries matching spawn + EPERM |
| 2026-07-14 |
23 |
| 2026-07-15 |
21 |
| 2026-07-16 |
26 |
| 2026-07-17 |
85 |
| 2026-07-18 |
27 |
| 2026-07-19 |
8 |
| 2026-07-20 |
74 |
| 2026-07-21 |
67 |
| 2026-07-22 |
44 |
| 2026-07-23 |
38 |
| 2026-07-24 |
3 |
Example failure captured in ~/.codex/logs_2.sqlite (agent ran the project's dev server):
> @prtd/web@0.1.0 dev <workspace>\apps\web
> next dev
ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL @prtd/web@0.1.0 dev: `next dev`
Exit status 1
Error: spawn EPERM
at ChildProcess.spawn (node:internal/child_process:420:11)
at spawn (node:child_process:787:9)
Minimal reproduction
Inside the Codex sandbox:
node -e "const {spawnSync}=require('node:child_process'); const r=spawnSync(process.execPath,['-e','console.log(123)']); console.log(r.error)"
Result inside the sandbox:
code: EPERM
errno: -4048
syscall: spawnSync ...\node.exe
The identical command run escalated (outside the sandbox) prints 123 and exits 0. The project itself is healthy: with no leftover processes and a clean .next, a full production build completes normally in ~289 s outside the sandbox.
Compounding issue: orphaned process trees
When a tool call running next dev/next build is cancelled or hits the tool timeout, only the parent shell is terminated. Next/Turbopack child processes survive, keep multi-GB working sets, and contend over the same .next directory with the next build attempt — which then looks like a build hang and previously led us to misdiagnose build timeouts as a project problem.
Suggested improvements
- Reduce friction for the escalation path when a command is known to require child processes (the agent currently burns retries failing inside the sandbox before escalating), or allow the sandbox to permit spawning sandboxed children on Windows.
- On tool timeout/cancel, terminate the whole process tree (equivalent of
taskkill /T /F), not just the direct child.
- Provide a progress-aware or configurable (>10 min) timeout for long-running build commands.
Happy to provide fuller (redacted) log excerpts if useful.
What version of the Codex App are you using?
Codex Desktop 26.715.10079.0 (Windows), embedded CLI/core reports
client_version 0.145.0inmodels_cache.json. Signed in with a ChatGPT account.config.tomlhas[windows] sandbox = "unelevated".What platform is your computer?
Windows 11 Home 10.0.26200 — Node v22.23.1 (fnm), pnpm 9.12.3.
What issue are you seeing?
The Windows unelevated sandbox blocks child process creation with
spawn EPERM, which makes any Node toolchain that forks workers unusable inside the sandbox:next dev,next build(Next.js 15), and esbuild all fail the moment they callchild_process.fork()/spawn(). This has been recurring in our workflows since early June 2026; the local log DB (which only retains ~10 days) shows spawn-EPERM entries every single day:spawn+EPERMExample failure captured in
~/.codex/logs_2.sqlite(agent ran the project's dev server):Minimal reproduction
Inside the Codex sandbox:
Result inside the sandbox:
The identical command run escalated (outside the sandbox) prints
123and exits 0. The project itself is healthy: with no leftover processes and a clean.next, a full production build completes normally in ~289 s outside the sandbox.Compounding issue: orphaned process trees
When a tool call running
next dev/next buildis cancelled or hits the tool timeout, only the parent shell is terminated. Next/Turbopack child processes survive, keep multi-GB working sets, and contend over the same.nextdirectory with the next build attempt — which then looks like a build hang and previously led us to misdiagnose build timeouts as a project problem.Suggested improvements
taskkill /T /F), not just the direct child.Happy to provide fuller (redacted) log excerpts if useful.