Windows Codex Desktop sandbox blocks Node child_process, WSL, Schannel clients, and pip temp installs #21470

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

26.429.61741

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows, Codex Desktop app, PowerShell shell, WSL2 Ubuntu installed and working

What issue are you seeing?

Summary

On Windows Codex Desktop, several plugin/dev workflows fail inside the Codex shell even though the same project works in WSL2. The most visible failure was with the Remotion plugin/workflow, but the underlying issues appear broader: Node child processes are blocked, Windows Schannel-backed web clients fail TLS, pip temp folders become inaccessible, and wsl.exe cannot be started from the Codex shell.

The Remotion project successfully rendered in Ubuntu/WSL2 using the same source files, so the Remotion plugin/project itself appears healthy. The failures seem specific to the Windows Codex sandbox/runtime environment.

Environment

• OS: Windows, Codex Desktop app
• Workspace path: C:\Users\<user>\OneDrive\Desktop\OlderNewDocuments-todelete\New project
• Codex shell: PowerShell
• Installed plugin involved: Remotion plugin with remotion-best-practices skill present
• WSL2 Ubuntu installed and working
• Bundled Codex Node path:
  • C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
• Bundled Codex Python path:
  • C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe

Issues observed

1. Node can run, but Node child_process is blocked with EPERM

Node itself starts successfully in the Codex shell:

v24.14.0

But Node cannot spawn child processes, including itself or cmd.exe:

execPath FAIL EPERM spawnSync C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
cmd FAIL EPERM spawnSync cmd.exe
pwsh FAIL EPERM spawnSync powershell.exe

Copying node.exe into the workspace did not help:

fail C:\Users\<user>\OneDrive\Desktop\OlderNewDocuments-todelete\New project\tools\node.exe EPERM spawnSync ...
fail cmd.exe EPERM spawnSync cmd.exe

Python subprocesses do work from the same Codex shell:

python subprocess OK 123

Impact:

• Remotion CLI cannot run in Windows Codex because it needs Node child processes for esbuild, Chromium, and ffmpeg.
• Other Node-heavy plugins or workflows may be affected too.

2. Remotion CLI fails in Windows Codex but works in WSL2

Inside Windows Codex, after dependencies were installed, Remotion still failed because esbuild requires Node process spawning:

Error: spawn EPERM
at ensureServiceIsRunning (...\node_modules\esbuild\lib\main.js:1982:29)
at loadConfigFile (...\node_modules\@remotion\cli\dist\load-config.js:21:61)

Inside WSL2 Ubuntu, the same project works:

npm run still
Rendered still
out/slide-03-check.png

And:

npm run build
Rendered frames
Encoded video
out/slide-03-love-back.mp4 3.1 MB

This strongly suggests the project/plugin is not fundamentally broken; the Windows Codex sandbox is the blocker.

3. wsl.exe cannot be started from Codex shell

Trying to automate the WSL workaround from inside Codex failed:

Access is denied.
Error code: Wsl/Service/CreateInstance/E_ACCESSDENIED

Impact:

• Codex cannot directly run the WSL workaround, even though WSL works manually in Windows Terminal.
• Users have to manually copy/sync/run commands in Ubuntu, which is confusing and brittle.

4. PowerShell Invoke-WebRequest and Windows curl fail TLS via Schannel

PowerShell web requests fail:

Invoke-WebRequest FAIL https://registry.npmjs.org/npm/latest
The underlying connection was closed: An unexpected error occurred on a receive.
INNER System.ComponentModel.Win32Exception No credentials are available in the security package

Windows curl.exe fails similarly:

curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
No credentials are available in the security package

Setting TLS 1.2 did not fix it.

However, Node HTTPS fetch works:

node https fetch: OK 200

Python urllib HTTPS also works:

python https urllib: OK 200

Impact:

• PowerShell-based download/install scripts break.
• Workarounds need to use Node/OpenSSL or Python urllib instead of Windows Schannel-backed clients.

5. pip reaches PyPI but fails writing temp wheel/metadata files

pip can reach PyPI but fails when writing files into temp unpack folders:

ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied:
'...\pip-unpack-...\colorama-0.4.6-py2.py3-none-any.whl.metadata'

With legacy resolver:

Permission denied:
'...\pip-unpack-...\colorama-0.4.6-py2.py3-none-any.whl'

Manual Python can write similarly named files and extract wheel files in the same workspace, so this appears to be pip's temp/unpack behavior interacting badly with Codex sandbox ACLs.

Impact:

• Python package installs may fail inside Codex.
• Manual wheel download/extract works as a workaround for simple packages.

6. Browser plugin failed to initialize in this session

When attempting to use the Browser plugin to open the GitHub issue page, Browser initialization failed:

failed to write kernel assets: The system cannot find the path specified. (os error 3)

Retrying from a fresh Node REPL state produced the same error. A minimal Node REPL sanity check also failed with the same message before any browser code could run:

failed to write kernel assets: The system cannot find the path specified. (os error 3)

Impact:

• Browser automation was not available to submit or inspect the issue from within Codex.
• The failure appears to be at the Node REPL/kernel asset setup layer, which Browser depends on, not at a specific website or GitHub page.

What steps can reproduce the bug?

These are the concrete workflows/commands that reproduced the failures in Windows Codex Desktop:

Reproduction details

1. Node can run, but Node child_process is blocked with EPERM

Node itself starts successfully in the Codex shell:

v24.14.0

But Node cannot spawn child processes, including itself or cmd.exe:

execPath FAIL EPERM spawnSync C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
cmd FAIL EPERM spawnSync cmd.exe
pwsh FAIL EPERM spawnSync powershell.exe

Copying node.exe into the workspace did not help:

fail C:\Users\<user>\OneDrive\Desktop\OlderNewDocuments-todelete\New project\tools\node.exe EPERM spawnSync ...
fail cmd.exe EPERM spawnSync cmd.exe

Python subprocesses do work from the same Codex shell:

python subprocess OK 123

Impact:

• Remotion CLI cannot run in Windows Codex because it needs Node child processes for esbuild, Chromium, and ffmpeg.
• Other Node-heavy plugins or workflows may be affected too.

2. Remotion CLI fails in Windows Codex but works in WSL2

Inside Windows Codex, after dependencies were installed, Remotion still failed because esbuild requires Node process spawning:

Error: spawn EPERM
at ensureServiceIsRunning (...\node_modules\esbuild\lib\main.js:1982:29)
at loadConfigFile (...\node_modules\@remotion\cli\dist\load-config.js:21:61)

Inside WSL2 Ubuntu, the same project works:

npm run still
Rendered still
out/slide-03-check.png

And:

npm run build
Rendered frames
Encoded video
out/slide-03-love-back.mp4 3.1 MB

This strongly suggests the project/plugin is not fundamentally broken; the Windows Codex sandbox is the blocker.

3. wsl.exe cannot be started from Codex shell

Trying to automate the WSL workaround from inside Codex failed:

Access is denied.
Error code: Wsl/Service/CreateInstance/E_ACCESSDENIED

Impact:

• Codex cannot directly run the WSL workaround, even though WSL works manually in Windows Terminal.
• Users have to manually copy/sync/run commands in Ubuntu, which is confusing and brittle.

4. PowerShell Invoke-WebRequest and Windows curl fail TLS via Schannel

PowerShell web requests fail:

Invoke-WebRequest FAIL https://registry.npmjs.org/npm/latest
The underlying connection was closed: An unexpected error occurred on a receive.
INNER System.ComponentModel.Win32Exception No credentials are available in the security package

Windows curl.exe fails similarly:

curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
No credentials are available in the security package

Setting TLS 1.2 did not fix it.

However, Node HTTPS fetch works:

node https fetch: OK 200

Python urllib HTTPS also works:

python https urllib: OK 200

Impact:

• PowerShell-based download/install scripts break.
• Workarounds need to use Node/OpenSSL or Python urllib instead of Windows Schannel-backed clients.

5. pip reaches PyPI but fails writing temp wheel/metadata files

pip can reach PyPI but fails when writing files into temp unpack folders:

ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied:
'...\pip-unpack-...\colorama-0.4.6-py2.py3-none-any.whl.metadata'

With legacy resolver:

Permission denied:
'...\pip-unpack-...\colorama-0.4.6-py2.py3-none-any.whl'

Manual Python can write similarly named files and extract wheel files in the same workspace, so this appears to be pip's temp/unpack behavior interacting badly with Codex sandbox ACLs.

Impact:

• Python package installs may fail inside Codex.
• Manual wheel download/extract works as a workaround for simple packages.

6. Browser plugin failed to initialize in this session

When attempting to use the Browser plugin to open the GitHub issue page, Browser initialization failed:

failed to write kernel assets: The system cannot find the path specified. (os error 3)

Retrying from a fresh Node REPL state produced the same error. A minimal Node REPL sanity check also failed with the same message before any browser code could run:

failed to write kernel assets: The system cannot find the path specified. (os error 3)

Impact:

• Browser automation was not available to submit or inspect the issue from within Codex.
• The failure appears to be at the Node REPL/kernel asset setup layer, which Browser depends on, not at a specific website or GitHub page.

Workaround validation

Created workspace-local helper scripts:

• tools\npm.cmd / tools\npx.cmd: call local npm via bundled/workspace Node
• tools\fetch-url.js: Node/OpenSSL downloader replacing PowerShell/curl web requests
• tools\Invoke-NodeWebRequest.ps1: PowerShell wrapper around Node downloader
• tools\wheel_install.py: direct PyPI wheel download/extract bypassing pip temp folders
• tools\codex_env_check.py: diagnostic script showing Node child_process failure and HTTPS status
• render-remotion-wsl.cmd / tools\render-remotion-wsl.ps1: Windows-side wrapper intended to sync/render via WSL, but this cannot run from inside Codex because wsl.exe is access denied

Manual WSL2 workflow succeeded:

cd ~/code
rsync -av --exclude node_modules --exclude .npm-cache --exclude .npm-tmp --exclude out \
  "/mnt/c/Users/<user>/OneDrive/Desktop/OlderNewDocuments-todelete/New project/relationship-slide-03-animation/" \
  "$HOME/code/relationship-slide-03-animation/"

cd ~/code/relationship-slide-03-animation
npm install
npm run still
npm run build

Additional WSL libraries were needed for Remotion Chrome headless shell:

sudo apt install -y libnss3 libnspr4 libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 \
  libxkbcommon0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 \
  libasound2t64 libpango-1.0-0 libcairo2 libx11-xcb1 libxcb1 libxext6 libxshmfence1

What is the expected behavior?

• Node child_process should be allowed for workspace-local/bundled tools when running with appropriate Codex permissions, or Codex should clearly document that Node CLIs requiring child processes are unsupported in Windows sandbox mode.
• wsl.exe should either be callable from Codex Desktop when WSL is installed, or Codex should provide a supported bridge/workflow for WSL execution.
• PowerShell/curl HTTPS should not fail with Schannel SEC_E_NO_CREDENTIALS, or the Codex docs should recommend Node/Python download paths inside this sandbox.
• pip package installs should work with workspace-local temp/cache dirs, or docs should explain known limitations and provide recommended install patterns.
• Plugin workflows such as Remotion should detect Windows sandbox limitations and suggest WSL2 automatically.

Additional information

Questions

1. Is Node child_process intentionally blocked in Windows Codex Desktop sandbox?
2. Is wsl.exe intentionally blocked from Codex Desktop?
3. Are Schannel clients expected to fail with SEC_E_NO_CREDENTIALS in Codex Desktop?
4. Is there a recommended way for plugins like Remotion to run Node-heavy CLI workflows on Windows?
5. Should plugin authors add Windows Codex checks/fallbacks for these sandbox limitations?

Note

Local Windows username/path segments were redacted before posting. The Browser automation note in the source report may have been session-specific; the browser was available while preparing this GitHub issue.