Windows sandbox cannot access a Box Drive workspace mounted through a Junction; CreateProcessWithLogonW 267 and apply_patch fs helper failures

Title:
Windows sandbox cannot access a Box Drive workspace mounted through a Junction; CreateProcessWithLogonW 267 and apply_patch fs helper failures

Environment

• OS: Windows
• VS Code extension:
• openai.chatgpt-26.803.41515-win32-x64
• openai.chatgpt-26.803.61601-win32-x64
• Codex CLI: 0.147.0-alpha.6.5
• Box Drive: 2.52.315.0
• Sandbox mode: workspace-write / managed restricted filesystem
• Workspace is inside Box Drive.

Box Drive is mounted as:

• NTFS Junction/ReparsePoint: C:\Users\<user>\Box
• Target: a Box virtual volume without a drive letter
• Reported filesystem: FAT32

Problem

Codex's Windows sandbox cannot reliably access a workspace located under the
Box Drive Junction.

A shell command whose cwd is the workspace fails with:

windows sandbox: CreateProcessWithLogonW failed: 267

Running the same read-only command outside the sandbox with
require_escalated succeeds.

When the command cwd is C:\, attempting to access the workspace from inside
the sandbox fails with:

Access is denied

apply_patch also fails intermittently or persistently with:

apply_patch verification failed: Failed to read ...:
fs sandbox helper failed ... windows sandbox failed:
CreateProcessWithLogonW failed: 267

Reproduction

1. Install Box Drive on Windows.
2. Open a VS Code workspace below C:\Users\<user>\Box\....
3. Use Codex with workspace-write sandbox permissions.
4. Run Get-Location with the workspace as cwd.
5. Run an apply_patch operation against a file in the workspace.

Actual behavior

• Sandboxed shell cannot start with the Box workspace as cwd.
• Sandboxed traversal from C:\ into the Box workspace is denied.
• apply_patch cannot reliably read or update workspace files.
• The same path works outside the sandbox.

Expected behavior

A workspace explicitly listed as a writable root should be accessible to the
sandbox, including when an ancestor is a Junction/ReparsePoint backed by Box
Drive.

Diagnostic evidence

The sandbox setup log reports:

granting write ACE to <workspace> for sandbox group and capability SID

granting read ACE to C:\Users\<user>\Box\ for sandbox users

setup refresh ... errors=[]

However, the first sandboxed access immediately fails.

Historical local rollout audit:

• Sandboxed shell commands against the Box workspace consistently failed.
• Most shell work succeeded only through require_escalated.
• apply_patch was intermittent:
• some calls succeeded;
• others failed to read the same Box workspace;
• it later became persistently unusable.

This suggests that ACL setup succeeds on the logical Junction path but does not
reliably grant traversal/access to the Box virtual-volume target.

Workaround

• require_escalated works for shell commands.
• It does not solve apply_patch, which still depends on the filesystem

sandbox helper.

• Moving the workspace to a normal local NTFS directory is the practical

workaround.

Possibly related: #30009