Bubblewrap sandbox fails inside container for commands on bind-mounted host paths

Resolved 💬 7 comments Opened Mar 17, 2026 by JannikWolff Closed Apr 21, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

v0.115.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4 medium

What platform is your computer?

Linux 5.15.0-76-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

On a shared filesystem without sudo, I run Codex CLI inside an Apptainer container (1.4.1) to restrict Codex read access to the host.

Since Codex 0.115.0, reading a file from a bind-mounted path into the container fails before file access with a bubblewrap error.

This does not occur with Codex 0.114.0, so it appears related to the Linux sandbox change in 0.115.0, where bubblewrap became the default on Linux (#13996, @viyatb-oai).

What steps can reproduce the bug?

  1. Start an Apptainer container with a bind-mounted host directory.
  2. Start Codex CLI inside the container.
  3. Ask Codex to read a file in the bind-mounted directory.
  4. Observe that the command fails before file access with: bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to mount source on destination: Invalid argument

Running the same read through Codex CLI’s ! shell escape succeeds.

What is the expected behavior?

_No response_

Additional information

A native way to restrict Codex CLI filesystem read access, as discussed in #2847, would provide a workaround by allowing Codex to run directly on the host without relying on nested container sandboxing for read isolation.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #14825
  • #14694
  • #14875

Powered by Codex Action

zb-dvlpr · 4 months ago

Can confirm that this is happening at my end too. codex-cli 0.115.0

jocado · 4 months ago

I'm hitting the same issue with 0.115.0

loicgasser · 3 months ago

This is an issue for linux users:

<img width="549" height="127" alt="Image" src="https://github.com/user-attachments/assets/200ca155-f194-4bc7-85a8-526d3c31b6da" />

viyatb-oai contributor · 3 months ago

@loicgasser This should be fixed in Codex 0.117.0 by https://github.com/openai/codex/pull/15693, which fixes compatibility with older system bubblewrap versions that do not support --argv0.

Please update to 0.117.0 and let us know if you're still seeing this.

JannikWolff · 2 months ago

@viyatb-oai: The problem still exists: in v0.122.0, it's possible to run Codex CLI in a container with the legacy landlock, but not with the bwrap sandbox (then, bind-mounts to the host don't work). However, the legacy landlock will be discontinued soon. Why was the issue closed?

smocherla-brex · 2 months ago

+1 on the above , bwrap doesn't seem to work when the root is overlayfs backed

bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to mount source on destination: Operation not permitted

with errors like. Adding explicit sandbox mounts and permissions like below works but it is still tedious to add the paths I care about.

default_permissions = "container-scoped"

  [permissions.container-scoped.filesystem]
  ":minimal" = "read"
  "/home/owner" = "read"

  [permissions.container-scoped.filesystem.":workspace_roots"]
  "." = "write"

  [permissions.container-scoped.network]
  enabled = false