Windows elevated sandbox cannot read pnpm hardlinked files due to ACL mismatch while host user can

What version of the Codex App are you using?

Codex Desktop / sandbox runtime:

codex-cli 0.154.0-alpha.6.2

Standalone executable observed at:

C:\Users\jack0\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7\codex.exe

Separately, the npm-installed host CLI reports:

0.147.0

The Desktop runtime and npm-installed CLI appear to use the same CODEX_HOME but report different Windows sandbox provisioning status.

What subscription do you have?

ChatGPT paid plan.

What platform is your computer?

Windows 11
Windows 10.0.26200
x86_64

Native Windows Codex elevated sandbox.

What issue are you seeing?

The Codex elevated Windows sandbox cannot read some files inside an existing pnpm node_modules tree even though the same files are readable by the normal Windows user outside Codex.

This is reproducible as a host-vs-sandbox A/B test.

Example file:

D:\Users\jack0\Documents\MyProject\stage-tracker\node_modules\.pnpm\zod@4.6.4\node_modules\zod\v4\index.js

Result:

Codex elevated sandbox: Access denied
Ordinary host PowerShell: file read succeeds

The file is a hardlink.

ACL inspection showed:

• the host user jack0, SYSTEM, and Administrators have FullControl;
• a parent directory includes CodexSandboxUsers with Modify;
• the target hardlinked file's own security descriptor does not contain CodexSandboxUsers;
• no explicit deny ACE was found;
• the sandbox identity is:

desktop-aqelrf2\codexsandboxoffline

As a result, applications running inside Codex fail when they read files from the pnpm hardlink tree.

For example, a verification run eventually failed with:

EPERM: operation not permitted, open
...\node_modules\.pnpm\zod@4.6.4\node_modules\zod\v4\index.js

A direct read of the same file inside the Codex sandbox also returns Access denied, so this is not specific to Node.js, pnpm, Turbo, or Zod.

Sandbox provisioning state also differs between Desktop and host CLI

CODEX_HOME is:

C:\Users\jack0\.codex

The elevated sandbox was explicitly provisioned from an Administrator PowerShell using:

$env:CODEX_HOME='C:\Users\jack0\.codex'
codex sandbox setup --elevated --current-user --codex-home 'C:\Users\jack0\.codex'

The setup command reported success:

Windows elevated sandbox setup completed for jack0 at C:\Users\jack0\.codex.

Afterward, the npm-installed host CLI codex doctor reported a healthy sandbox with no provisioning warning.

However, the Desktop/standalone runtime still reports the provisioning as incomplete/outdated.

The shared marker is:

C:\Users\jack0\.codex\.sandbox\setup_marker.json

Observed marker information:

version: 5
offline_username: CodexSandboxOffline
online_username: CodexSandboxOnline

Importantly, the sandbox principal itself could not read setup_marker.json because of its ACL.

This may explain why the Desktop sandbox runtime considers provisioning incomplete even though setup completed successfully from the host CLI.

Steps to reproduce

1. On Windows, use a pnpm project with an existing node_modules created outside the Codex sandbox.
2. Ensure the dependency tree contains pnpm hardlinked files, for example:

node_modules\.pnpm\<package>\node_modules\<package>\<file>

3. Use the native Codex elevated Windows sandbox.
4. Inside a Codex execution, try to read a specific dependency file, for example:

Get-Item 'D:\path\to\repo\node_modules\.pnpm\zod@4.6.4\node_modules\zod\v4\index.js'
Get-Content 'D:\path\to\repo\node_modules\.pnpm\zod@4.6.4\node_modules\zod\v4\index.js' -TotalCount 1

5. Observe Access denied.
6. Open an ordinary PowerShell as the normal user outside Codex and run the same read.
7. Observe that the read succeeds.
8. Compare ACLs for the parent directory and the hardlinked file.

In my environment, the parent grants access to CodexSandboxUsers, while the file itself does not.

Expected behavior

Files that are legitimately readable from the repository by the host user and are within the Codex sandbox's allowed workspace should also be readable by the sandbox identity.

Specifically, sandbox provisioning should ensure that existing dependency trees containing hardlinks do not become selectively unreadable because their file-level security descriptors lack the sandbox principal.

The Desktop runtime should also be able to read and validate the sandbox setup marker created by the supported elevated setup command.

Actual behavior

The host user can read the dependency file, but the Codex sandbox cannot:

Host PowerShell: PASS
Codex sandbox: FAIL — Access denied

This causes otherwise read-only build/lint/test operations to fail with errors such as:

EPERM: operation not permitted, open ...

The Desktop runtime also appears unable to validate the shared sandbox marker because the sandbox principal cannot read it.

Related but separate pnpm issue

There is also a separate package-manager resolution problem in this environment matching:

• #30440 — Codex uses bundled pnpm instead of host toolchain

The project declares:

pnpm@12.4.1

while Codex injects:

C:\Users\jack0\.cache\codex-runtimes\codex-primary-runtime\dependencies\bin\fallback\pnpm.cmd

which reports:

11.19.0

That issue is independently reproducible and can cause:

ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY

However, the ACL problem described in this report is separate:

• it reproduces with a direct file read;
• it does not require pnpm execution;
• the host user can read the exact same file;
• only the Codex sandbox identity is denied.

I am therefore filing this issue specifically for the Windows elevated sandbox ACL/filesystem behavior.

Additional information

Current sandbox:

backend: elevated
filesystem: restricted
network: restricted
approval: OnRequest

No workaround was applied.

I deliberately did not:

• change the file or directory ACLs;
• delete/reinstall node_modules;
• modify the sandbox marker;
• disable the sandbox;
• run Codex permanently with unrestricted filesystem access;
• modify repository scripts or configuration to work around the problem.

No repository tracked files were changed during the diagnostic.

The behavior suggests either:

1. elevated sandbox provisioning does not correctly account for existing pnpm hardlinked files whose security descriptors differ from their parent directory; and/or
2. the Desktop/standalone runtime and npm-installed CLI have incompatible expectations around the shared Windows sandbox provisioning state / marker ACLs.

I can provide additional Get-Acl output or a redacted codex doctor --json report if useful.

Start with the Windows elevated sandbox setup flow invoked by codex sandbox setup --elevated --current-user and inspect how it handles the shared .codex\.sandbox\setup_marker.json. Reproduce the direct Get-Content read failure and compare ACLs on the parent directory, hardlinked file, and marker. Done means the sandbox can read allowed hardlinked dependency files and validate the setup marker without weakening unrelated permissions.