[Windows Desktop] Injected slash_tmp root maps to C:\tmp and blocks apply_patch for otherwise writable workspaces

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32937
• #33388
• #33208

Powered by Codex Action

Hey are you using a ramdisk?

A fresh reproduction confirms that the advertised writable-root contract can be false even when ordinary repository writes work.

Environment:

• Codex CLI 0.144.5
• Native Windows workspace-write sandbox
• Codex shell host: Windows PowerShell 5.1.26100.8875 (powershell.exe) on CLR 4
• PowerShell 7 (pwsh.exe) is not installed or available on this machine; sandboxed and elevated checks agree

The session advertised C:\tmp as a writable root. A bounded archive-inspection step then attempted to create a unique child directory with New-Item -ItemType Directory -Path C:\tmp\<unique-name> and received UnauthorizedAccessException. The same step succeeded when redirected to the repository's ignored tmp/ directory. No file was created under C:\tmp.

This also exposed an agent-orientation problem: a repository owner may intentionally designate a repository-local disposable workspace, but the injected writable-root list can appear more authoritative and lead the agent toward a root that is both inappropriate for the repository and unusable in the sandbox.

A useful product contract would provide one preferred scratch-workspace setting globally with a trusted-project override. Codex should resolve that setting into both the sandbox grant and the agent-visible environment, validate writability when the session starts, identify it explicitly as the disposable working location, and report an unavailable optional root without presenting it as writable or blocking the actual workspace. A project override would let repository owners keep temporary extraction, generated inspection data, and recoverable working notes inside an ignored repository directory when that is their intended file-organization boundary.

I appear to be hitting the same issue on another Windows machine, with a slightly different C:\tmp ACL configuration.

Codex version: codex-cli 0.145.0

Feedback/session ID: 019fa9f6-3b9e-7462-b357-8c57316f9253

The affected chat's sandbox profile contains both:

<entry access="write"><special>:slash_tmp</special></entry>
<entry access="write"><special>:tmpdir</special></entry>

Codex reports that:

• <special>:tmpdir maps to C:\Users\Sundar\AppData\Local\Temp
• <special>:slash_tmp maps separately to C:\tmp
• apply_patch launches:

C:\Users\Sundar\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper

• sandbox setup then fails before applying the patch:

write ACE grant failed on C:\tmp: SetNamedSecurityInfoW failed: 5

The actual patch target is inside the writable workspace and is unrelated to C:\tmp. Avoiding apply_patch and writing the same workspace files through ordinary shell operations succeeds.

My environment variables do not point to C:\tmp:

Process TEMP:  C:\Users\Sundar\AppData\Local\Temp
Process TMP:   C:\Users\Sundar\AppData\Local\Temp
User TEMP:     C:\Users\Sundar\AppData\Local\Temp
User TMP:      C:\Users\Sundar\AppData\Local\Temp
Machine TEMP:  C:\WINDOWS\TEMP
Machine TMP:   C:\WINDOWS\TEMP

C:\tmp is an ordinary directory rather than a junction:

FullName   : C:\tmp
Attributes : Directory
LinkType   :
Target     : {}

Its ACL differs somewhat from the original report:

Owner                   : NT AUTHORITY\SYSTEM
AreAccessRulesProtected : True

C:\tmp BUILTIN\Administrators:(F)
       BUILTIN\Administrators:(OI)(CI)(IO)(F)
       NT AUTHORITY\SYSTEM:(F)
       NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
       NT AUTHORITY\Authenticated Users:(M)
       NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
       BUILTIN\Users:(RX)
       BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

So ordinary authenticated users have Modify access to the directory contents, but the non-elevated Codex sandbox helper cannot modify the directory's ACL because it is SYSTEM-owned and its ACL is protected.

This seems to independently reproduce the issue's central failure mode:

1. Codex injects <special>:slash_tmp on Windows even though %TEMP% and %TMP% point elsewhere.
2. Because C:\tmp happens to exist, Codex treats it as a writable sandbox root.
3. The helper attempts to add its sandbox ACE to that directory.
4. The ACL update fails with Windows error 5.
5. Failure to prepare this unrelated compatibility root aborts apply_patch for valid workspace files.

This also suggests the problem is not specific to C:\tmp being owned by BUILTIN\Administrators; a SYSTEM-owned directory with a protected ACL produces the same result.

I agree with the proposed fixes in this issue, particularly mapping slash_tmp to a per-user Codex-owned directory on Windows, allowing the root to be omitted/remapped, or not aborting all workspace patching when this auxiliary root cannot be prepared.

Additional confirmed variant on a current Windows Desktop build: sandbox setup refresh reports success, but <special>:slash_tmp remains stamped with a stale restricted SID.

Environment

• Codex Desktop MSIX: 26.727.6591.0
• Bundled command runner: 0.146.0-alpha.9.2
• Windows 11 Pro 10.0.26200 x64
• Native Windows workspace-write sandbox with three write roots: a workspace, a visualization output root, and <special>:slash_tmp mapped to C:\tmp

Sanitized observations

• The shell runs as <machine>\CodexSandboxOffline and is a member of CodexSandboxUsers.
• C:\tmp is a normal, non-reparse directory owned by the signed-in user.
• Its DACL already contains CodexSandboxUsers:(OI)(CI)(M) plus a synthetic restricted-SID Modify ACE left by an earlier sandbox setup.
• Every current setup refresh reports:

``text
setup refresh: processed 3 write roots (read roots delegated); errors=[]
``

• The actual command token is restricted and contains one synthetic SID for each of the three write roots. The current workspace SID and visualization SID are present on their corresponding roots. C:\tmp contains an older synthetic SID instead of the token's third current SID.
• A bounded file creation under C:\tmp therefore fails with Access denied, despite the root being advertised as writable and despite errors=[].

Control

Adding only the token's third current restricted SID to C:\tmp as an inheritable Modify ACE, using the Windows SecurityIdentifier API, immediately made the same restricted sandbox able to create and delete a 15-byte probe file. No broad user, group, or profile ACL was added.

This extends the original report: the failure can occur even when C:\tmp is user-owned and already has the sandbox-group ACE. The refresh can silently retain a stale synthetic SID and still claim success.

Expected behavior

• Setup refresh should stamp every writable root with the restricted SID present in the command token for that root.
• errors=[] should only be emitted after validating the effective token/root mapping.
• If an auxiliary root cannot be made writable, Codex should report that root as unavailable instead of advertising it as writable.

All usernames, machine names, raw SIDs, project paths, task/thread IDs, and business command text have been removed.

Additional diagnostics from another Windows Desktop installation with the same failure family:

The failure occurred before PowerShell/cmd execution. Codex's sandbox log showed:

granting write ACE to C:\Temp for sandbox group and capability SID
write ACE grant failed on C:\Temp: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors: ["write ACE failed on C:\\Temp: SetNamedSecurityInfoW failed: 5"]

Environment:

• Codex Desktop build 26.818.5229.0
• Local NTFS workspace under the user Documents\Codex tree
• User-level TEMP and TMP were both configured as C:\Temp
• C:\Temp was owned by BUILTIN\Administrators
• The workspace ACLs themselves were healthy; only C:\Temp failed

The issue persisted across app reinstall and Windows restart. It was resolved by changing the user-level TEMP and TMP variables to the user-owned folder:

C:\Users\<user>\AppData\Local\Temp

After fully restarting Codex, a PowerShell command succeeded immediately.

This appears to be the same ACL-stamping failure described here, with C:\Temp as the concrete temp root instead of C:\tmp. In this variant, TEMP/TMP themselves pointed at the administrator-owned directory, so redirecting them to the per-user temp directory removed the failing root. The broader symptom was also reported in #35353.

Suggested improvement: report the failing ACL target and Windows error directly, or skip an optional temp root that cannot be stamped instead of aborting the entire sandbox setup.