apply_patch and view_image fail with false "os error 206" (filename too long) under restricted permission profile on Windows

English translation:

codex-cli 0.142.5 (Windows, elevated sandbox). Reporting an issue where apply_patch and view_image fail with a false "filename too long" error under a custom profile (extending :workspace and setting :root=deny).

• The actual path length is only about 60-70 characters (nowhere near Windows' 260-character limit)
• Access to the same file via PowerShell (Copy-Item/Set-Content, etc.) succeeds normally in the same session
• The path is within the granted writable/readable range (no approval prompt and no applicable deny rule)
• Reproduces with both long paths and short ASCII paths, so the path length itself is not the cause
• It previously worked normally with the :root=read setting -> consistently reproduces after switching to :root=deny
• Impact: apply_patch can be worked around via the shell. There is no workaround for view_image, so under this configuration the model cannot visually inspect images

<!-- codex-issue-translator -->

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

• #31248
• #31229

Powered by Codex Action

This may be related to a broader pattern of Windows-specific failures involving OS error 206, seen across several other issues:

• #17107 — apply_patch fails on Windows with CreateProcessAsUserW failed: 206 for large patch payloads
• #15003 — Windows: apply_patch fails for large patches because the patch body is still transported via argv
• #13574 — apply_patch fails under sandboxed default permission on Windows

Those issues attribute the failure to argv length limits for large patch bodies. However, in this issue the failure reproduces under different conditions:

• view_image fails too (a read-only tool with no patch payload at all)
• Paths are short (60-70 chars, far under any argv/path length limit)
• It only started after switching the permission profile to include ":root" = "deny" (previously worked fine under ":root" = "read", and shell-invoked commands like PowerShell continue to work fine under the same ":root" = "deny" profile)

This suggests the root cause may not be specific to apply_patch's argv-based patch transport, but something more general about how codex's native file tools (as opposed to shell-invoked commands) spawn or communicate with a sandboxed child process under restrictive permission profiles on Windows — possibly in how CreateProcessAsUserW (or an equivalent call) is invoked for these tools specifically.

Environment: codex-cli 0.142.5, Windows, [windows] sandbox = "elevated", default_permissions profile with ":root" = "deny".

Root cause identified — deterministic repro and un-repro for the false os error 206

I hit this bug on 2026-07-07 and finally isolated the trigger on 2026-07-26. Sharing because the err
or message points in the wrong direction (it cost me 19 days).

TL;DR: The false os error 206 ("filename or extension too long") from apply_patch / view_im
age is triggered by the combination of :root = "deny" in a permission profile and a non
-glob (folder) deny_read entry nested inside a root that the profile grants "read". Neither co
ndition alone triggers it. Actual path length is irrelevant (fails at 55 chars, works at 145 after t
he fix).

Environment

• Windows 11 Pro, Codex CLI 0.145.0 (first hit on an earlier 0.14x build), elevated Windows sandbox

([windows] sandbox = "elevated"), admin-managed requirements.toml

Repro (5 steps)

1. Define a permission profile with a denied root and one allowed read root, e.g.:

``toml
[permissions.restricted.filesystem]
":root" = "deny"
"C:/work/allowed" = "read"
``

1. Add a non-glob folder deny nested inside the allowed root:

``toml
[permissions.filesystem]
deny_read = ["C:/work/allowed/private_folder"]
``

1. Restart Codex. On startup it stamps Windows ACLs: the denied folder gets DENY ACEs for the `Codex

SandboxUsers group (visible via icacls: (DENY)(R) on the folder plus an inherited-only (OI)(CI
)(IO)(DENY)(R,GR)`).

1. Ask Codex to view_image or apply_patch any file under C:/work/allowed — even files comp

letely outside private_folder, with short paths → both tools fail with os error 206 ("filename o
r extension too long"). shell commands on the same files still work.

1. Remove that single deny_read line, remove the stale DENY ACEs (`icacls "C:/work/allowed/private

_folder" /remove:d ...` — note Codex does not auto-remove ACEs when the config line is removed),
restart → both tools work again. Re-adding the line re-breaks them. Fully deterministic in both dir
ections.

What does NOT trigger it (all verified)

• :root = "deny" alone (with no nested non-glob deny) — tools work.
• Glob-pattern deny_read entries inside the same allowed root (e.g. `"C:/work/allowed/**/*.xls

x"`) — these stamp DENY ACEs on matching files rather than an inherited folder DENY, and the tools
keep working.

• A non-glob folder deny outside any allowed read root — harmless.

Mechanism (working hypothesis — not verified in source)
The distinguishing factor on disk is an inheritable folder DENY ACE inside the allowed tree. Whe
n the native file tools walk/canonicalize paths under the allowed root and encounter that inherited
DENY, the failure appears to be mis-mapped to ERROR_FILENAME_EXCED_RANGE (206) instead of ERROR_A
CCESS_DENIED (5). Genuine denials elsewhere correctly surface as os error 5, which is how the fal
se 206 can be distinguished in the wild.

Impact / ask

• The misleading error text sends users chasing long-path/\\?\ issues. If the underlying cause can

't be fixed quickly, even correcting the error mapping (206 → 5, or a specific message) would save a
lot of debugging time.

• Workarounds until then: express nested denies as glob patterns, or move sensitive folders outside

allowed read roots.