Native Windows Codex app: workspace dependency repair fails; npx/tsx and esbuild hit EPERM in sandbox

Open 💬 6 comments Opened Apr 21, 2026 by borealcountry

💡 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)?

The installed Codex app build visible in this session is OpenAI.Codex_26.415.1938.0_x64, so the app version appears to be 26.415.1938.0.

What subscription do you have?

Business plan monthly

What platform is your computer?

Windows 10 x64

What issue are you seeing?

Feedback/session ID: d16ff2fe-4cf9-4bf2-8a8c-ebb4ecbad680

Additional context: this machine is on an out-of-support Windows 10 build and Windows Update reports it is missing important security and quality fixes, so this may be interacting with the native Windows sandbox/runtime.

I’m seeing what looks like a native Windows Codex app sandbox/runtime issue rather than a repo-specific failure.

Environment

Codex app on Windows
Sandbox mode: workspace-write
Approval policy: never
Network: enabled
Working directory: C:\AspenMetrics2\receiptcheck-engine

What happened

“Reset and install workspace” failed
“Diagnose issues in Codex Workspace” says: “codex dependencies may need repair, send feedback if this keeps happening”
Codex can run basic Node commands, but fails on npx/tsx and esbuild paths with EPERM

Repro
These work:

node -v
node -e "console.log('ok')"
node -e "require('child_process').spawnSync(process.execPath,['-e','console.log(123)'],{stdio:'inherit'})"

This fails before tsx starts:

npx tsx --version
Error: EPERM: operation not permitted, lstat 'C:\Users\andre'

These work:

.\node_modules\.bin\tsx.cmd --version
node .\node_modules\tsx\dist\cli.mjs --version

esbuild repro:

node -e "console.log(require('esbuild').version)" works
node -e "require('esbuild').transformSync('const x: number = 1',{loader:'ts'})" fails with spawn EPERM

Direct binary execution from PowerShell works:

.\node_modules\@esbuild\win32-x64\esbuild.exe --version

But Node cannot spawn that same binary:

spawnSync('.\\node_modules\\@esbuild\\win32-x64\\esbuild.exe',['--version'])
result: EPERM

Additional signal

fs.realpathSync('C:\\Users\\andre') returns EPERM
This suggests the sandbox is blocking access to that path
Node child-process spawning appears to fail in the mode esbuild relies on

Why this seems like a Codex/runtime issue

Basic Node execution works
Repo-local tsx works
PowerShell can execute the esbuild binary directly
The failure appears at sandboxed path access and child-process spawn behavior

Questions

Is this a known issue with the native Windows Codex app sandbox?
Is there a recommended fix or config change?
My app UI does not appear to show the documented Windows-native vs WSL agent switch. Is that expected for some builds?

What steps can reproduce the bug?

Session ID: d16ff2fe-4cf9-4bf2-8a8c-ebb4ecbad680

Bug summary:
On the native Windows Codex app, the workspace dependency repair/install path appears broken, and Node-based toolchains that rely on certain sandboxed filesystem and child-process behavior fail with EPERM. Basic Node execution works, but npx tsx fails before startup with an lstat EPERM against C:\Users\andre, and esbuild fails with spawn EPERM when invoked through Node. Direct execution of the same local binaries from PowerShell works, which suggests this is a Codex native Windows sandbox/runtime issue rather than a repo-specific dependency failure.

Environment:

Codex app on Windows
Sandbox mode: workspace-write
Approval policy: never
Network: enabled
Working directory: C:\AspenMetrics2\receiptcheck-engine

Observed behavior:

“Reset and install workspace” failed
“Diagnose issues in Codex Workspace” says: “codex dependencies may need repair, send feedback if this keeps happening”
npx tsx --version fails with EPERM: operation not permitted, lstat 'C:\Users\andre'
node -e "require('esbuild').transformSync('const x: number = 1',{loader:'ts'})" fails with spawn EPERM

Expected behavior:

Workspace dependency repair/install should complete successfully
npx tsx --version should run normally
esbuild should be spawnable from Node inside the Codex environment

Minimal repro snippets:

1) Repro the blocked path access:

node -e "require('fs').realpathSync('C:\\Users\\andre')"

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

#18666
#17112
#18620
#18451
#18845

Powered by Codex Action

borealcountry · 3 months ago

Thanks — I reviewed the suggested duplicates.

My issue seems closest to:

#17112 (workspace-write fails while danger-full-access works / PowerShell path behavior)
#18451 (Windows sandbox token/setup failure)
possibly #18620 / #18845 if those are the same Windows sandbox process-launch/setup-helper family

However, my repro is specifically:

npx tsx --version -> EPERM: operation not permitted, lstat 'C:\Users\andre'
node -e "require('esbuild').transformSync('const x: number = 1',{loader:'ts'})" -> spawn EPERM
Reset and install workspace failed
Diagnose issues in Codex Workspace says dependencies may need repair

So I’m leaving this open for now unless maintainers think one of the linked issues already fully covers this exact native Windows repro.

borealcountry · 3 months ago

I did a narrower environment diagnosis inside Codex Desktop on native Windows + PowerShell, and the failure looks more specific than a repo bug.

Environment from this session:

Codex desktop package path observed via bundled Node path: OpenAI.Codex_26.415.1938.0_x64__2p2nqsd0c76g0
sandbox mode: workspace-write
approval policy: never
network: enabled
cwd: C:\AspenMetrics2\receiptcheck-engine

What works:

node -v -> v20.18.0
where.exe node -> resolves to both C:\nvm4w\nodejs\node.exe and the app-bundled Node
node -e "console.log('ok')" -> prints ok
node -e "require('child_process').spawnSync(process.execPath,['-e','console.log(123)'],{stdio:'inherit'})" -> works, prints 123
.\node_modules\.bin\tsx.cmd --version -> works, prints:
tsx v4.21.0
node v20.18.0
node .\node_modules\tsx\dist\cli.mjs --version -> also works
direct PowerShell launch of native esbuild binary works:
.\node_modules\@esbuild\win32-x64\esbuild.exe --version -> 0.27.4

What fails:

npx tsx --version fails before tsx starts with:
Error: EPERM: operation not permitted, lstat 'C:\Users\andre'
direct Node access to user home path also fails:
fs.realpathSync('C:\\Users\\andre') -> EPERM
node -e "require('esbuild').transformSync('const x: number = 1',{loader:'ts'}); console.log('transform-ok')" fails with:
Error: spawn EPERM
stack includes ensureServiceIsRunning in node_modules\esbuild\lib\main.js
spawning the native esbuild executable from Node fails even though launching it directly from PowerShell works:
spawnSync('.\\node_modules\\@esbuild\\win32-x64\\esbuild.exe',['--version']) -> EPERM

Important nuance:

Node child process behavior is not completely broken. This specific case works:
spawnSync(process.execPath, ..., {stdio:'inherit'})
But default/piped stdio spawn fails:
spawnSync(process.execPath, ..., default stdio) -> EPERM
spawn(...) with piped stdio -> EPERM

My reading of this:

This does not look like repo logic.
This does not look like a general Node failure.
There appear to be two sandbox/runtime issues on Windows desktop:

sandboxed Node sees env/home paths like C:\Users\andre, but access to them is denied (lstat / realpathSync -> EPERM)
sandboxed Node child-process creation is restricted in a way that breaks the spawn mode used by esbuild (and likely other tools using piped stdio / IPC)

That combination explains why:

plain node works
local tsx version check can work
npx can fail on home-path access
esbuild-backed execution fails with spawn EPERM

If useful, I can provide the exact command transcripts, but the shortest reliable repro on this machine is:

node -e "require('esbuild').transformSync('const x: number = 1',{loader:'ts'}); console.log('transform-ok')"
observe Error: spawn EPERM

and separately:

npx tsx --version
observe EPERM: operation not permitted, lstat 'C:\Users\andre'

Yinglianchun · 2 months ago

我也遇到了这个问题

Yinglianchun · 2 months ago

我也遇到了这个问题

无法重新安装 Codex 依赖项
npm.cmd 拒绝访问 / 找不到模块
Vite listen UNKNOWN
Python asyncio _overlapped WinError 10106

Tahiti18 · 2 months ago

I am seeing the same native Windows Codex desktop dependency repair issue.

Environment:

Codex desktop on Windows 10 x64
Codex app version/build: OpenAI.Codex_26.415.1938.0_x64, version appears to be 26.415.1938.0
Subscription: Business monthly
Feedback/request ID: e494dceb-0d96-405b-882c-83f4c6dabce0
Windows user path from local logs: C:\Users\mar1

Symptoms:

In Settings / Configuration, Diagnose reports: “Codex dependencies may need repair.”
Reinstall / repair fails with: “Couldn’t reinstall Codex dependencies.”
Running the Microsoft Visual C++ Redistributable x64 installer returned 0x80070666 because a newer version is already installed.
The Visual C++ log shows installed runtime version 14.50.35719.0, so this does not appear to be a missing Visual C++ runtime issue.

Why I think this may be the same native Windows sandbox/runtime bug:

The issue appears similar to the reported Windows sandbox / EPERM dependency failures.
Codex can open, but the dependency repair/install path fails.
The machine is Windows 10 x64 and Windows Update reports missing important security and quality fixes, which may be interacting with the native Windows sandbox/runtime.

Question:
Is the recommended workaround currently to reset %APPDATA%\Codex, switch to WSL2 mode, change the Windows sandbox configuration, or wait for a Codex desktop app fix?