codex - 💡(How to fix) Fix Full Access /goal session can fall back to workspace-write and hit bwrap "Failed to make / slave"

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

Unknown / not relevant to the local CLI sandbox repro.

Which model were you using?

GPT-5 Codex in an interactive Codex CLI session. The issue appears to be permission/session state and local sandboxing behavior, not model-specific output.

What platform is your computer?

Linux 6.8.0-87-generic x86_64 x86_64

OS release:

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
UBUNTU_CODENAME=jammy

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

Jupyter/container-like Linux environment; no terminal multiplexer known.

Codex doctor report

not available

In this installation, codex doctor --json is not accepted:

error: unexpected argument '--json' found

codex doctor --help also prints the top-level CLI help and does not list a doctor subcommand.

What issue are you seeing?

A session where Full Access was enabled through /permissions and /goal was used still stopped on permission/approval prompts for ordinary file and command work.

After investigating locally, this looks like two behaviors interacting:

1. /permissions Full Access is a runtime/session override, not persisted as the default permission profile. This matches the explanation in #13934.
2. Some goal/subagent/resume-like paths can appear to use or inherit the config/default permission profile instead of the visible Full Access runtime override. That causes Codex to attempt workspace-write sandboxing again.
3. In this local environment, workspace-write sandboxing is not viable because bubblewrap fails before the command runs:

bwrap: Failed to make / slave: Permission denied

The result is confusing from the user's perspective: Full Access was selected, but later work still appears blocked by approval/sandbox behavior. The underlying failure is not a source-code/file permission problem; it is a fallback to sandboxed execution combined with a local bubblewrap incompatibility.

What steps can reproduce the bug?

The exact UI-level reproduction involved an interactive session that used /permissions and /goal:

1. Start Codex CLI in a repository.
2. Use /permissions and select Full Access.
3. Start or continue work under /goal, including subagent/file-operation work.
4. Observe that later work can still stop on approval prompts / sandbox failures, despite Full Access having been selected.
5. Inspecting the effective permission instructions shows behavior consistent with falling back to workspace-write / approval-managed execution rather than consistently honoring the runtime Full Access override.

Local sandbox diagnostics from the same environment:

$ which bwrap
/usr/bin/bwrap

$ bwrap --version
bubblewrap 0.6.1

$ sysctl kernel.unprivileged_userns_clone
kernel.unprivileged_userns_clone = 1

$ findmnt -no TARGET,PROPAGATION /
/ private

$ bwrap --unshare-user --ro-bind / / /bin/true
bwrap: Failed to make / slave: Permission denied

~/.codex/config.toml did not contain top-level sandbox_mode or approval_policy defaults, only trusted project entries. So the effective default after a runtime-only /permissions override can still be workspace-write / approval-managed behavior.

Related issues that seem adjacent but do not fully cover this combined /permissions + /goal + bwrap-failure case:

• #15434: exact bwrap: Failed to make / slave error, closed as a regression report.
• #15678: restricted / nested Linux environments where bubblewrap is not viable.
• #13934: /permissions is temporary and does not persist to config defaults.
• #15305: runtime sandbox override not inherited by a subagent/review path.
• #22362: /goal interaction with inherited approval policies is ambiguous.
• #22312: /goal runtime includes approval-wait time.

What is the expected behavior?

Within the active interactive session, Full Access selected through /permissions should be consistently honored by /goal and any spawned subagent/resume-like execution paths, or the UI should clearly communicate that those paths are using the config/default profile rather than the runtime /permissions override.

If execution falls back to workspace-write and bubblewrap fails with Failed to make / slave, Codex should surface that as a local bubblewrap/sandbox incompatibility rather than making it look like a normal source-code permission or approval problem.

For users who explicitly choose Full Access, a goal/subagent path should not silently reintroduce bubblewrap sandboxing unless that is clearly shown and intentionally configured.

Additional information

Launching Codex with explicit CLI/config defaults appears to be the more reliable workaround than relying on /permissions alone, for example setting both:

sandbox_mode = "danger-full-access"
approval_policy = "never"

or using:

codex --dangerously-bypass-approvals-and-sandbox

The confusing part is that /permissions makes the current session look like Full Access is active, while subsequent /goal/subagent behavior can still expose the default sandbox path.