›_ Codex Issues
Codex Issues / #33806

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

Open 💬 3 comments Opened Jul 17, 2026 by Gavin-Huang

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

26.715.2305.0

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows 10.0.19045.6456 x64

What issue are you seeing?

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

What version of Codex is running?

Codex Desktop build 26.715.2305.0.

The same failure was also present in local sandbox logs from Desktop builds:

  • 26.707.12708.0
  • 26.623.3763.0
  • 26.623.8305.0
  • 26.623.9142.0

What platform is your computer?

Microsoft Windows 10.0.19045.6456 x64.

What issue are you seeing?

Codex Desktop injects a special writable root named <special>:slash_tmp, which is materialized as C:\tmp on Windows.

If C:\tmp already exists but is owned by BUILTIN\Administrators and has no Codex sandbox-group ACE, codex-windows-sandbox-setup.exe tries to add the sandbox write ACE, receives ERROR_ACCESS_DENIED (SetNamedSecurityInfoW failed: 5), and aborts the entire sandbox setup refresh.

As a result, apply_patch cannot update an existing file in an otherwise writable workspace on another drive. The patch target itself is not under C:\tmp.

The current session has both:

  • <special>:tmpdir, which correctly resolves to the current user's %TEMP%;
  • <special>:slash_tmp, which separately resolves to C:\tmp.

%TEMP% and %TMP% are already:

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

Neither environment variable points to C:\tmp.

The effective ACL on C:\tmp is:

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

There is no CodexSandboxUsers ACE. The directory owner is BUILTIN\Administrators, while the Codex process is running with a restricted, non-elevated token and cannot change the directory ACL.

This is especially disruptive because ordinary read commands and some new-file creation can still succeed. The failure becomes visible when apply_patch needs its filesystem helper to update an existing source file.

Representative error

The user-visible tool error is:

apply_patch verification failed: Failed to read file to update
D:\workspace\repo\path\ExistingFile.cs:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error:
setup refresh had errors

The corresponding sandbox log is:

setup refresh: spawning ...\codex-windows-sandbox-setup.exe
granting write ACE to C:\tmp for sandbox group and capability SID
write ACE grant failed on C:\tmp: SetNamedSecurityInfoW failed: 5
setup refresh: processed 3 write roots; errors=["write ACE failed on C:\\tmp: SetNamedSecurityInfoW failed: 5"]
setup refresh completed with errors
setup error: setup refresh had errors

What steps can reproduce the bug?

  1. On Windows, create or retain a pre-existing C:\tmp directory whose owner is BUILTIN\Administrators and which does not contain a Codex sandbox-group ACE.
  2. Start a Codex Desktop task in workspace-write mode with:
  • a normal writable workspace, for example D:\workspace\repo;
  • <special>:tmpdir;
  • <special>:slash_tmp.
  1. Confirm that %TEMP% and %TMP% point to the user's normal local Temp directory, not C:\tmp.
  2. Use apply_patch to add a new Markdown file in the workspace. In this case it succeeded.
  3. Use apply_patch to update an existing source file in the same writable workspace.
  4. Observe that the update fails before reading the target file because sandbox setup cannot add an ACE to C:\tmp.
  5. Repeat against another existing workspace file. The same setup-refresh failure occurs.

This was reproduced in three consecutive Codex goal turns. The source files remained unchanged.

What is the expected behavior?

An optional compatibility temp root must not prevent apply_patch from operating on an unrelated, authorized workspace path.

At least one of the following should be true:

  1. On Windows, map the /tmp compatibility root to a user-owned per-user directory, preferably %TEMP% or a Codex-owned subdirectory under %LOCALAPPDATA%, instead of hard-coding C:\tmp.
  2. Allow users or managed permission profiles to remap or remove <special>:slash_tmp.
  3. If a special optional root cannot be stamped, report that root as unavailable but continue initializing authorized workspace roots.
  4. If C:\tmp must be used, provision its sandbox ACL through an installer/update path that has the required authority, rather than attempting an ACL mutation from every restricted task.

The fix should not require users to grant persistent Modify permission on a shared system-level C:\tmp directory.

Actual behavior

Failure to stamp the unrelated C:\tmp root aborts the complete filesystem-helper setup. apply_patch then cannot update any existing workspace file, including files on D:\.

Changing %TEMP% or adding another writable root such as D:\CodexTmp does not solve the problem while <special>:slash_tmp remains in the root list.

Impact

  • Existing source files cannot be updated with apply_patch.
  • Long-running Codex tasks become blocked even though the repository itself is writable.
  • Read-only shell commands may continue working, which makes the failure look path- or tool-specific.
  • Project policies that require apply_patch cannot safely fall back to shell-based file rewriting.
  • The only operator-side workaround found is a persistent ACL modification on C:\tmp or restarting with a permission profile that omits slash_tmp.

Timeline from local logs

The same C:\tmp ACL failure was observed on:

  • 2026-06-26: 103 failures;
  • 2026-06-29: 83 failures;
  • 2026-06-30: 1 failure;
  • 2026-07-16: 138 failures;
  • 2026-07-17: more than 500 failures.

There were no C:\tmp attempts in the local sandbox logs from 2026-07-01 through 2026-07-15, which suggests the special root is injected only for some task permission profiles or execution paths.

Related issues

  • #14585 — Windows sandbox ACL refresh can break repeated apply_patch.
  • #22044 — restricted-token sandbox paths without the Codex sandbox SID remain unwritable.

This report may share the same underlying ACL-stamping mechanism, but adds a Desktop-specific failure mode: an internally injected slash_tmp root maps to a pre-existing administrator-owned C:\tmp, and failure to stamp that optional root disables apply_patch for unrelated authorized workspace paths.

Additional note

There is a separate intermittent Windows Desktop failure when Codex directly launches the Microsoft App Execution Alias for pwsh.exe and CreateProcessAsUserW returns error 1920. That issue is intentionally excluded here so this report remains focused on slash_tmp and ACL refresh.

What steps can reproduce the bug?

  1. On Windows, create or retain a pre-existing C:\tmp directory whose owner is BUILTIN\Administrators and which does not contain a Codex sandbox-group ACE.
  2. Start a Codex Desktop task in workspace-write mode with:
  • a normal writable workspace, for example D:\workspace\repo;
  • <special>:tmpdir;
  • <special>:slash_tmp.
  1. Confirm that %TEMP% and %TMP% point to the user's normal local Temp directory, not C:\tmp.
  2. Use apply_patch to add a new Markdown file in the workspace. In this case it succeeded.
  3. Use apply_patch to update an existing source file in the same writable workspace.
  4. Observe that the update fails before reading the target file because sandbox setup cannot add an ACE to C:\tmp.
  5. Repeat against another existing workspace file. The same setup-refresh failure occurs.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗