codex - 💡(How to fix) Fix Windows elevated sandbox fails on Cryptomator-mounted workspace (UNC/network drive)

Summary

Codex Desktop on Windows fails to run sandboxed shell commands when the workspace is located inside a Cryptomator vault mounted as a drive letter. The same commands work when re-run with elevated permissions from Codex, but fail in the default sandbox path with:

windows sandbox: setup refresh failed with status exit code: 1

This may be related to the workspace being exposed to Windows as a UNC/network drive (\\cryptomator-vault\...) rather than as a normal local NTFS volume.

Environment

• OS: Windows
• App: Codex Desktop
• Codex Desktop package version: OpenAI.Codex 26.527.3686.0
• Bundled Codex CLI/helper version: codex-cli 0.135.0-alpha.1
• Codex config includes:

[windows]
sandbox = "elevated"

Workspace setup

The workspace is in a Cryptomator vault mounted with default settings as drive H:.

PowerShell sees H: as a FileSystem drive, but with a UNC-style Cryptomator backing path:

Name        : H
Provider    : Microsoft.PowerShell.Core\FileSystem
Root        : H:\
DisplayRoot : \\cryptomator-vault\<vault-id>\<share-name>

net use H: reports it as a remote disk:

Local name  H:
Remote name \\cryptomator-vault\<vault-id>\<share-name>
Resource type Disk

Get-Volume -DriveLetter H does not return a volume, and fsutil fsinfo volumeinfo H: returns access denied, which also suggests this is not a regular local volume from Windows' perspective.

Reproduction

1. Mount a Cryptomator vault on Windows using default settings as a drive letter, e.g. H:.
2. Open a Codex Desktop workspace inside that mounted drive.
3. In Codex, run a simple shell command without escalation, for example:

Get-Date -Format "yyyy-MM-dd HH:mm:ss zzz"

or:

Get-Content -Raw -Encoding UTF8 "some-file.md"

Actual behavior

The command fails before the actual PowerShell command appears to run:

execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

If the same command is re-run with elevated permissions through Codex, it succeeds.

Expected behavior

Codex should either:

• support sandboxed access to workspaces mounted through Cryptomator/UNC-backed drive letters, or
• detect this workspace type and provide a clearer diagnostic/workaround, e.g. suggesting sandbox = "unelevated" or a local WinFsp mount point.

Notes / hypothesis

This looks similar to other Windows sandbox setup failures, but the Cryptomator angle may be a distinct trigger. The mount is presented as \\cryptomator-vault\..., so the elevated sandbox setup may be trying to apply ACLs or user access rules to a virtual/network filesystem that does not behave like a normal local volume.

Cryptomator's documentation notes that drive-letter mounts can be user-specific and that alternative volume types/mount points may be needed when access from different users or elevated contexts is required. Since Codex's elevated sandbox model uses separate Windows users, this may explain why sandbox setup fails while explicitly elevated commands can still run.

A useful fix might be either better support for this kind of mounted workspace or a targeted error message when the workspace is on a UNC/network-backed filesystem.