Windows app sandbox blocks Node path traversal and elevation approval fails internally

[benjaminisawolfe]

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

26.715.72359

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

In the Codex App for Windows, Node/npm commands cannot run when a repository is nested beneath directories that are outside the configured workspace root.

The sandbox grants access to the workspace directory itself but not enough traversal or read-attribute access to its ancestors. Node canonicalizes absolute paths during startup and calls lstat on those ancestors, causing EPERM.

Changing the workspace root to the immediate parent does not solve the problem. It only moves the failure to the next inaccessible ancestor and causes Codex to request broad access to an unrelated higher-level directory.

The normal elevation path also fails internally even after I explicitly approve the requested command.

Repository layout

E:\Work\blip\blip-bloop

I later tried this workspace root:

E:\Work\blip\

With the second root, the same problem recurred at E:\Work, and Codex requested access to all of that directory. Broad access to E:\Work is neither necessary nor appropriate.

What steps can reproduce the bug?

Steps to reproduce

1. Open a repository nested several directories deep in the Codex App for Windows.

2. Use the repository itself as the workspace root.

3. Ask Codex to run a Node-based command such as:

   npm run build
   

4. The default PowerShell process may fail to launch under the sandbox.

5. When the command is run using cmd.exe, Node starts but fails while resolving an ancestor of the repository.

6. Explicitly approve elevated execution.

7. The elevation approval broker fails internally instead of running the command.

8. Change the workspace root to the repository's immediate parent and retry.

9. The failure moves to the next ancestor, resulting in a request for broad access to that directory.

Node error

Error: EPERM: operation not permitted, lstat 'E:\Work\blip'
    at Object.realpathSync (node:fs:2787:29)
    at toRealPath (node:internal/modules/helpers:63:13)
    at Module._findPath (node:internal/modules/cjs/loader:803:22)
    at resolveMainPath (node:internal/modules/run_main:35:21)
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:146:20)
    at node:internal/main/run_main_module:33:47 {
  errno: -4048,
  code: 'EPERM',
  syscall: 'lstat',
  path: 'E:\\Work\\blip'
}

Node.js v24.16.0

After moving the workspace root to E:\Work\blip, the same ancestor-boundary problem recurred at E:\Work.

Elevation approval error

This occurred after I explicitly granted approval:

This action was rejected due to unacceptable risk.

Reason: Automatic approval review failed:
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "unsupported_value",
    "message": "This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.",
    "param": "model"
  },
  "status": 400
}

Because the automatic reviewer fails internally, explicit user approval cannot unblock the command.

Related shell-launch symptom

The default PowerShell launcher also failed before running the command:

CreateProcessAsUserW failed: 5 (Access is denied.)

Shell:
C:\Users\<USER>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

Using cmd.exe allows the process to start, but Node then encounters the ancestor lstat failure described above.

Additional evidence

Within the original repository-root sandbox:

icacls .

succeeds and shows Modify access for the Codex sandbox identity, while:

icacls ..

returns:

Access is denied.

Git read-only commands can run, but Node/npm validation and development-server commands fail because Node performs absolute-path canonicalization.

The same npm commands succeed from my normal Windows terminal outside the Codex sandbox.

What is the expected behavior?

Expected behavior

• Node/npm commands should work inside an authorized repository even when it is nested beneath other directories.
• The sandbox should provide only the minimal ancestor permissions Node needs, such as directory traversal and read-attribute access.
• It should not request broad read/write access to unrelated contents of a higher-level directory.
• Explicitly approved elevation should execute successfully.
• The approval broker should not fail because of an unsupported internal model configuration.

Actual behavior

• Node fails while calling lstat on a repository ancestor.
• Expanding the workspace root only moves the failure to the next ancestor.
• Codex then requests unnecessarily broad access to that ancestor.
• Explicit elevation approval cannot proceed because the automatic approval reviewer returns an internal model-routing error.
• Codex cannot independently run project builds, tests, formatting checks, or the local development server.

Suggested resolution

On Windows, grant the sandbox identity only the minimal traversal/read-attribute permissions required on the workspace's ancestor chain while retaining normal repository permissions exclusively on the selected workspace.

Separately, correct the elevation-reviewer configuration so that explicit approvals are not blocked by the unsupported X-OpenAI-Internal-Codex-Responses-Lite model error.

### Additional information

This problem only occurred after installing the most recent Codex update. Prior to that, I had no issues on the same project.

[Gavin-Lee-hub]

Additional cross-platform reproduction on macOS:

• OS: macOS 15.5
• ChatGPT/Codex Desktop: 26.715.72359
• Bundled Codex CLI: 0.145.0-alpha.30
• Time zone: Asia/Shanghai
• Observed: 2026-07-23 12:04–16:08
• Frequency: 27 failed review turns across 8 automatic-review sessions

With managed/restricted permissions, tasks requiring automatic permission review remained blocked during startup. The review turns failed with:

model=codex-auto-review

HTTP 400 invalid_request_error
code=unsupported_value
param=model

This model is not supported when using
X-OpenAI-Internal-Codex-Responses-Lite.

The same error occurred during startup prewarming and during the actual review turn, so this was not only a harmless prewarm warning. The parent task did not receive a review decision and remained blocked.

Switching the task to Full Access allowed it to start because the automatic-review path was bypassed. This is only a temporary workaround because it removes the normal filesystem and network isolation.

No user prompts, conversation contents, account details, workspace names, local paths, or business data are included in this report. Private diagnostic/session identifiers can be provided to OpenAI maintainers if needed.

[benjaminisawolfe]

I tried to solution in #34967 and it worked. Going back to "asking for approval" on every action bypasses the issue.