Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix Linux sandbox (bubblewrap) uses non-unique temp registry path, breaking multi-user /tmp [1 pull requests, 1 comments, 2 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#21192•Fetched 2026-05-06 06:25:09
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
agolovanovagolovanov
Participants
agolovanovagolovanovlan13005lan13005
Timeline (top)
labeled ×3closed ×1commented ×1cross-referenced ×1

Error Message

Because the folder is not user or session-specific, the folder can be already created by another user working with Codex, so trying to create it again results in an error:

Root Cause

Because the folder is not user or session-specific, the folder can be already created by another user working with Codex, so trying to create it again results in an error:

failed to open synthetic bubblewrap mount registry lock
/tmp/codex-bwrap-synthetic-mount-targets/lock: Permission denied

Fix Action

Fixed

PR fix notes

PR #21234: fix(linux-sandbox): isolate Linux sandbox synthetic mount registry per user for shared codex use case

Description (problem / solution / changelog)

Summary

  • make the Linux sandbox synthetic mount registry path unique per effective UID
  • keep same-user coordination intact while avoiding collisions between users sharing /tmp
  • add a regression test for the registry path contract

Why

Issue #21192 reports that the Linux sandbox currently uses one global temp path at /tmp/codex-bwrap-synthetic-mount-targets. If another user creates that directory first, later users can fail to open the shared lock file with Permission denied.

Validation

  • just fmt
  • cargo test -p codex-linux-sandbox
  • cargo clippy -p codex-linux-sandbox --all-targets

Fixes #21192

Changed files

  • codex-rs/linux-sandbox/src/linux_run_main.rs (modified, +4/-1)
  • codex-rs/linux-sandbox/src/linux_run_main_tests.rs (modified, +11/-0)

Code Example

/tmp/codex-bwrap-synthetic-mount-targets

---

failed to open synthetic bubblewrap mount registry lock
/tmp/codex-bwrap-synthetic-mount-targets/lock: Permission denied
RAW_BUFFERClick to expand / collapse

What version of the IDE extension are you using?

v26.429.30905

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 5.14.0-427.42.1.el9_4.x86_64 x86_64 x86_64

What issue are you seeing?

By default, Codex Linux sandbox creates a bubblewrap folder at:

/tmp/codex-bwrap-synthetic-mount-targets

The relevant line of code is: https://github.com/openai/codex/blob/70807730f5a8e093d5182089ad5a4b1b4355f9fa/codex-rs/linux-sandbox/src/linux_run_main.rs#L1238

Because the folder is not user or session-specific, the folder can be already created by another user working with Codex, so trying to create it again results in an error:

failed to open synthetic bubblewrap mount registry lock
/tmp/codex-bwrap-synthetic-mount-targets/lock: Permission denied

What steps can reproduce the bug?

Create a /tmp/codex-bwrap-synthetic-mount-targets folder and make it not accessible by the current user. Try using Codex and observe failures to use the sandbox.

What is the expected behavior?

Codex creates a registry path unique to the user, so that sandboxing always works. The folder should probably use a per-user or per-session path, e.g. include UID or username.

Additional information

No response

extent analysis

TL;DR

The issue can be resolved by modifying the Codex Linux sandbox to use a user-specific or session-specific path for the bubblewrap folder.

Guidance

  • The error occurs because the /tmp/codex-bwrap-synthetic-mount-targets folder is not user-specific, leading to permission issues when multiple users try to access it.
  • To verify the issue, create the folder and restrict its access, then try using Codex and observe the failure.
  • A potential workaround is to use a different path for the bubblewrap folder, such as one that includes the user's UID or username.
  • The relevant line of code is in linux_run_main.rs#L1238, which may need to be modified to generate a user-specific path.

Example

No code example is provided as the necessary changes depend on the specifics of the Codex codebase and the desired solution.

Notes

The solution may require modifications to the Codex codebase, and the exact changes will depend on the specific requirements and constraints of the project.

Recommendation

Apply a workaround by modifying the Codex code to use a user-specific path for the bubblewrap folder, as this will allow for a more robust and secure solution.

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…
#prompt formatting#chain error#conversation history#tool integration#LLM response

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

codex - ✅(Solved) Fix Linux sandbox (bubblewrap) uses non-unique temp registry path, breaking multi-user /tmp [1 pull requests, 1 comments, 2 participants]