Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix Linux bwrap fails when protected symlinked carveout points outside writable roots (No such file or directory) [1 pull requests, 3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17079•Fetched 2026-04-09 08:02:41
View on GitHub
Comments
3
Participants
3
Timeline
8
Reactions
0
Author
rebroadrebroad
Participants
github-actions[bot]github-actions[bot]rebroadrebroadviyatb-oaiviyatb-oai
Timeline (top)
commented ×3labeled ×3renamed ×1unlabeled ×1

Linux sandbox startup can fail when a protected read-only carveout path (for example .git) is a symlink under a writable root and that symlink points to an absolute target outside writable roots.

bwrap is currently invoked with a mask like:

--ro-bind /dev/null /var/tmp/src-builds/codex.other/.git

In this scenario, preflight can fail before any command/tool runs with:

bwrap: Can't create file at /var/tmp/src-builds/codex.other/.git: No such file or directory

Error Message

  • non-escalated commands (including apply_patch) fail at sandbox preflight
  • error appears before command execution

Root Cause

Linux sandbox startup can fail when a protected read-only carveout path (for example .git) is a symlink under a writable root and that symlink points to an absolute target outside writable roots.

bwrap is currently invoked with a mask like:

--ro-bind /dev/null /var/tmp/src-builds/codex.other/.git

In this scenario, preflight can fail before any command/tool runs with:

bwrap: Can't create file at /var/tmp/src-builds/codex.other/.git: No such file or directory

Fix Action

Fix / Workaround

Observed behavior

  • non-escalated commands (including apply_patch) fail at sandbox preflight
  • error appears before command execution

PR fix notes

PR #15981: fix(permissions): fix symlinked writable roots in sandbox permissions

Description (problem / solution / changelog)

Summary

  • preserve logical symlink paths during permission normalization and config cwd handling
  • bind real targets for symlinked readable/writable roots in bwrap and remap carveouts and unreadable roots there
  • add regressions for symlinked carveouts and nested symlink escape masking

Root cause

Permission normalization canonicalized symlinked writable roots and cwd to their real targets too early. That drifted policy checks away from the logical paths the sandboxed process can actually address, while bwrap still needed the real targets for mounts. The mismatch caused shell and apply_patch failures on symlinked writable roots.

Impact

Fixes #15781.

Also fixes #17079:

  • #17079 is the protected symlinked carveout side: bwrap now binds the real symlinked writable-root target and remaps carveouts before masking.

Related to #15157:

  • #15157 is the broader permission-check side of this path-identity problem. This PR addresses the shared logical-vs-canonical normalization issue, but the reported Darwin prompt behavior should be validated separately before auto-closing it.

This should also fix #14672, #14694, #14715, and #15725:

  • #14672, #14694, and #14715 are the same Linux symlinked-writable-root/bwrap family as #15781.
  • #15725 is the protected symlinked workspace path variant; the PR preserves the protected logical path in policy space while bwrap applies read-only or unreadable treatment to the resolved target so file-vs-directory bind mismatches do not abort sandbox setup.

Notes

  • Added Linux-only regressions for symlinked writable ancestors and protected symlinked directory targets, including nested symlink escape masking without rebinding the escape target writable.

Changed files

  • codex-rs/Cargo.lock (modified, +1/-0)
  • codex-rs/core/src/exec_tests.rs (modified, +2/-8)
  • codex-rs/exec/src/lib.rs (modified, +4/-1)
  • codex-rs/linux-sandbox/src/bwrap.rs (modified, +310/-23)
  • codex-rs/protocol/src/permissions.rs (modified, +30/-60)
  • codex-rs/protocol/src/protocol.rs (modified, +9/-6)
  • codex-rs/sandboxing/src/policy_transforms.rs (modified, +2/-2)
  • codex-rs/sandboxing/src/policy_transforms_tests.rs (modified, +5/-7)
  • codex-rs/tui/src/lib.rs (modified, +22/-4)
  • codex-rs/utils/absolute-path/Cargo.toml (modified, +1/-0)
  • codex-rs/utils/absolute-path/src/lib.rs (modified, +117/-0)
RAW_BUFFERClick to expand / collapse

Summary

Linux sandbox startup can fail when a protected read-only carveout path (for example .git) is a symlink under a writable root and that symlink points to an absolute target outside writable roots.

bwrap is currently invoked with a mask like:

--ro-bind /dev/null /var/tmp/src-builds/codex.other/.git

In this scenario, preflight can fail before any command/tool runs with:

bwrap: Can't create file at /var/tmp/src-builds/codex.other/.git: No such file or directory

Repro shape

  • workspace-write sandbox with writable root that canonicalizes to /var/tmp/src-builds/codex.other
  • protected carveouts include .../.git
  • .../.git is a symlink to an absolute path outside writable roots

Example:

  • /var/tmp/src-builds/codex.other/.git -> /home/rebroad/src/codex/.git

Observed behavior

  • non-escalated commands (including apply_patch) fail at sandbox preflight
  • error appears before command execution

Expected behavior

Sandbox should start successfully. It should not hard-fail when masking a symlinked protected path in this layout.

Related issues

  • #15725 (symlinked directory carveout variant)
  • #16161 (.git symlink Is a directory variant)

This appears to be a related but distinct failure mode (No such file or directory) triggered by symlink target layout and mount semantics.

extent analysis

TL;DR

The issue can be resolved by modifying the bwrap invocation to handle symlinked protected paths correctly, potentially by using a different bind mount approach.

Guidance

  • Investigate using the --bind option instead of --ro-bind to handle the symlinked path, as it may provide more flexibility in handling absolute targets outside writable roots.
  • Verify the behavior of bwrap when encountering symlinks with absolute targets, to understand the root cause of the No such file or directory error.
  • Consider modifying the sandbox setup to avoid using symlinks that point to absolute paths outside writable roots, if possible.
  • Review related issues (#15725 and #16161) to see if any of the solutions or workarounds applied there can be adapted to this scenario.

Example

No code snippet is provided, as the issue does not explicitly mention a specific code change that can be applied.

Notes

The solution may depend on the specific version of bwrap being used, as well as the underlying Linux distribution and filesystem configuration.

Recommendation

Apply a workaround, such as modifying the bwrap invocation or adjusting the sandbox setup, as the issue appears to be related to the specific use case and configuration rather than a straightforward version upgrade.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Sandbox should start successfully. It should not hard-fail when masking a symlinked protected path in this layout.

#api#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING