Windows sandbox: pnpm dlx fails with EPERM realpath C:\Users\<user>

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

26.513.4821.0

Codex CLI bundled with the app: codex-cli 0.131.0-alpha.9

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

PowerShell: 7.6.1

Node: v26.1.0

pnpm: 11.0.8

What issue are you seeing?

In the native Windows Codex App sandbox, pnpm dlx fails before running the package command:

PS C:\Users\<user>\workspaces\codex> pnpm dlx --package figlet figlet --version
[ERROR] EPERM: operation not permitted, realpath 'C:\Users\<user>'
For help, run: pnpm help dlx

This happens even when the pnpm write locations are configured as writable roots, including:

• C:\Users\<user>\AppData\Local\pnpm
• C:\Users\<user>\AppData\Local\pnpm-cache
• C:\Users\<user>\.cache\pnpm
• C:\Users\<user>\.local\share\pnpm
• C:\Users\<user>\.npm\_cacache\tmp

The same pnpm dlx --package cowsay cowsay --version command works in a normal PowerShell session outside Codex.

What steps can reproduce the bug?

1. Open the native Windows Codex App.
2. Use workspace-write sandboxing with network access enabled.
3. Add the pnpm cache/global locations above as writable roots.
4. Run:

pnpm dlx --package figlet figlet --version

What is the expected behavior?

pnpm dlx should be able to run when its cache/global write locations are writable, without requiring the whole user profile directory to be writable.

If Codex intentionally blocks this path, the error should identify the missing sandbox permission clearly enough to configure a narrow root.

Additional information

A controlled test suggests the missing permission is not another pnpm cache write root. When HOME/USERPROFILE are redirected to a temp workspace path, the C:\Users\<user> realpath error disappears.

Separately, a temp Codex sandbox profile that grants access to C:\Users\<user> plus the same narrow pnpm writable roots allows pnpm dlx --package cowsay cowsay --version to complete. That makes this look like a Windows sandbox read/realpath permission issue around the user profile path, not a normal pnpm cache write issue.