Windows sandbox: Node fs.unlinkSync() returns EPERM on existing workspace files while shell delete succeeds

What version of Codex CLI is running?

codex-cli 0.137.0-alpha.4

What subscription do you have?

Enterprise

Which model were you using?

5.4

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What terminal emulator and version are you using (if applicable)?

VS Code

Codex doctor report

Main issues:

No Codex credentials found
Required provider endpoint unreachable: https://chatgpt.com/backend-api/
WebSocket reachability warning with Windows socket error 10013
Git repo detected, but git executable not found on PATH
Notable environment details:

Codex version: 0.137.0-alpha.4
Executable: c:\Users\AlexandreGranger\.vscode\extensions\openai.chatgpt-26.602.71036-win32-x64\bin\windows-x86_64\codex.exe
Sandbox: filesystem restricted, network restricted
Config path checked: C:\Users\CodexSandboxOffline\.codex\config.toml and it was missing

What issue are you seeing?

Bug Report: Windows Sandbox Blocks Node.js fs.unlink*() on Existing Workspace Files

Summary

On Windows, Codex running inside the VS Code sandbox fails with EPERM when Node.js attempts to delete an existing file using fs.unlinkSync() (or equivalent APIs).

The same file can be deleted successfully:

• using shell commands (del, Remove-Item) inside the sandbox
• using Node.js outside the sandbox
• by running the same command with escalation

This appears to be a sandbox-specific filesystem permission issue affecting Node.js unlink operations.

---

Environment

OS

Windows

Codex

VS Code Codex extension

Sandbox Configuration

model = "gpt-5.4"
model_reasoning_effort = "medium"
service_tier = "default"

[windows]
sandbox = "elevated"

[projects.'c:\projects\k6-test']
trust_level = "trusted"

Node.js

node -v
v24.13.0

where node

C:\Program Files\nodejs\node.exe
C:\nvm4w\nodejs\node.exe

The same Node version and executable paths are visible both inside and outside the sandbox.

---

Project Path

Trusted workspace:

C:\Projects\k6-test

Example failing file:

generated/api/tests/mutation/post-conditions.mutation.ts

Full path:

C:\Projects\k6-test\generated\api\tests\mutation\post-conditions.mutation.ts

The file is inside the trusted workspace.

---

Original Failure

Codex executes:

npm run generate:mutation-tests

Failure:

Error: EPERM: operation not permitted, unlink
'generated/api/tests/mutation/post-conditions.mutation.ts'

The same command succeeds when run outside the sandbox or with escalation.

Successful run output:

generatedFiles: 38
generatedWorkflowTests: 10
generatedOperations: 18
skippedEntries: []

---

Reproduction

Test 1: Shell Delete Inside Sandbox

Command:

del generated\api\tests\mutation\post-conditions.mutation.ts

Result:

SUCCESS

The file is deleted successfully.

---

Test 2: Node.js Delete Inside Sandbox

Command:

node -e "require('fs').unlinkSync('generated/api/tests/mutation/post-conditions.mutation.ts')"

Result:

EPERM: operation not permitted

Failure occurs consistently.

---

Test 3: Same Node.js Delete Outside Sandbox

Command:

node -e "require('fs').unlinkSync('generated/api/tests/mutation/post-conditions.mutation.ts')"

Result:

SUCCESS

The file is deleted successfully.

---

Test 4: Generator

Inside sandbox:

npm run generate:mutation-tests

Result:

EPERM unlink(...)

Outside sandbox:

npm run generate:mutation-tests

Result:

SUCCESS

Generation completes normally.

---

Expected Behavior

Node.js filesystem deletion APIs should behave consistently with shell deletion commands for files located inside a trusted workspace.

The following should succeed:

require('fs').unlinkSync(path);

when:

• the file is inside the trusted workspace
• the sandbox is configured as elevated
• shell deletion of the same file is permitted

---

Actual Behavior

Inside the sandbox:

require('fs').unlinkSync(path);

fails with:

EPERM: operation not permitted

while:

del path

succeeds on the same file.

---

Why This Appears Sandbox-Related

Evidence collected:

• Reboot performed.
• File is inside trusted workspace.
• Workspace trust is active.
• Elevated Windows sandbox configured.
• Same Node version inside and outside sandbox.
• Shell deletion succeeds inside sandbox.
• Node deletion fails inside sandbox.
• Node deletion succeeds outside sandbox.
• Generator succeeds outside sandbox.
• Generator succeeds when escalation is granted.

This suggests a sandbox restriction or regression specifically affecting Node.js unlink operations rather than a project-specific issue or filesystem lock.

---

Minimal Reproduction Request

Please verify whether Windows sandbox policy currently treats:

fs.unlinkSync(existingWorkspaceFile)

differently from:

del existingWorkspaceFile

when operating on files inside a trusted workspace.

The behavior appears inconsistent and may be a regression in sandbox filesystem handling.

What steps can reproduce the bug?

node -e "require('fs').unlinkSync('generated/api/tests/mutation/post-conditions.mutation.ts')"

What is the expected behavior?

Expected Behavior

Node.js filesystem deletion APIs should behave consistently with shell deletion commands for files located inside a trusted workspace.

The following should succeed:

require('fs').unlinkSync(path);

when:

• the file is inside the trusted workspace
• the sandbox is configured as elevated
• shell deletion of the same file is permitted

Additional information

_No response_