›_ Codex Issues
Codex Issues / #34970

apply_patch fails on Windows with multiple writable roots

Open 💬 2 comments Opened Jul 23, 2026 by aniketp166
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Version 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?

On Windows, apply_patch fails before it opens any workspace file.

Error:
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

The task is launched with two writable roots:

I uninstalled the Visualize plugin and restarted both the laptop and Codex, but new Codex tasks still receive the visualization writable root. This prevents apply_patch from editing any file.

Expected: apply_patch should work in a normal local project task, or Codex should not attach the stale visualization root.

What steps can reproduce the bug?

  1. Open the Codex desktop app on Windows.
  2. Open a local project task in
  3. Ask Codex to make any small file edit using apply_patch.
  4. The task environment includes the project root plus a .codex\visualizations\...\ directory as writable roots.
  5. apply_patch fails before reading or modifying the target file.

I also uninstalled the Visualize plugin and restarted both Codex and Windows. New tasks still get the extra visualization writable root and reproduce the same failure.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34088

Powered by Codex Action

Loumeister · 3 days ago

I can reproduce a distinct elevated-sandbox variant of this bug on Windows Codex Desktop. The CLI installed alongside it reports codex-cli 0.146.0.

The effective permission graph includes:

  • writable: C:\Users\<user>
  • protected/read-only: C:\Users\<user>\.codex
  • writable again: C:\Users\<user>\.codex\visualizations\<date>\<thread>
  • the actual repository as another writable root

Every command spawn then fails before the command runs with:

windows elevated sandbox cannot reopen writable descendants under read-only carveouts directly; refusing to run unsandboxed

A fresh CLI run constrained to the exact repository with --sandbox workspace-write --cd <repo> succeeds. That indicates the repository ACLs are not the cause; Desktop is emitting an impossible writable-parent / protected-child / reopened-writable-descendant root graph.

User impact

This has turned into an almost six-hour troubleshooting task. The complete task's cumulative local counters at audit time show:

  • 32,572,578 total processed tokens
  • 31,385,472 cached input tokens
  • 1,043,896 non-cached input tokens
  • 143,210 output tokens, including 68,198 reasoning tokens

I am not claiming that every one of those tokens is directly billable or solely attributable to this defect; cached and non-cached usage are accounted differently. The figures show the total scale of the troubleshooting task and its substantial credit/usage-limit impact.

Separately, three specifically measured exact-repository workaround runs consumed 81,276 additional tokens outside the actual benchmark, including a 26,315-token failed child and a 35,417-token successful child. The fallback reloads task context, so every failed Desktop spawn can cause significant duplicated work.

Please address both layers:

  1. Treat this exact elevated error as deterministic in Desktop: do not retry the same sandbox spawn; automatically continue once through an exact-repository workspace-write child and return its result to the original task.
  2. Fix the workspace-root producer so it does not grant a broad home ancestor together with a writable capability directory inside protected CODEX_HOME.

The elevated backend's fail-closed behavior should remain intact; weakening the sandbox or using full access is not an acceptable fix.

This is related to #34970 because the same visualization root is injected, but it is not the same refusal path: #34970 reports the unelevated split-root check, while this report reaches the elevated reopened-descendant check.