Linux sandbox rejects valid nsfs mount roots from snapd: `mountinfo path is not absolute`

Summary

Codex 0.155.0-alpha.15 fails before executing any filesystem-restricted command on a native Ubuntu host when /proc/self/mountinfo contains valid nsfs entries created by snapd.

The failure is:

error building bubblewrap command: mountinfo path is not absolute

The affected mountinfo entries have an nsfs root such as mnt:[4026532835]. That is a valid Linux representation for a persisted mount namespace, but codex-rs/linux-sandbox/src/daemon_mounts.rs passes the mount root through mount_path(), which rejects any decoded path for which PathBuf::is_absolute() is false.

Environment

• Codex CLI: 0.155.0-alpha.15
• Native Codex SHA-256: fa6c7e9ec934ffc2257208cc25586214a9f83b0d52b9e7494b083336bda31b13
• OS: Ubuntu 26.04.1, native Linux
• Architecture: x86_64
• Kernel: 7.0.0-31-generic
• bubblewrap: 0.11.1
• snapd installed and providing persisted mount namespaces under /run/snapd/ns

Reproduction

Run a filesystem-restricted Codex command using 0.155.0-alpha.15 on a system whose /proc/self/mountinfo contains snapd nsfs namespace mounts.

In the observed case, Codex emitted a public command_execution item but failed before the requested command started:

status: failed
exit code: 1
output: error building bubblewrap command: mountinfo path is not absolute

The requested positive-control command was never executed.

Relevant mountinfo entries

The actual Codex process tree and the invoking shell shared the same mount namespace (mnt:[4026531832]). The Codex processes saw these valid entries:

2202 397 0:5 mnt:[4026532835] /run/snapd/ns/snapd-desktop-integration.mnt rw - nsfs nsfs rw
5180 397 0:5 mnt:[4026532900] /run/snapd/ns/prompting-client.mnt rw - nsfs nsfs rw
6212 397 0:5 mnt:[4026532636] /run/snapd/ns/firmware-updater.mnt rw - nsfs nsfs rw

For each entry:

• filesystem type: nsfs
• field 4 / root: mnt:[...] (valid, but not an absolute filesystem pathname)
• field 5 / mount point: absolute /run/snapd/ns/*.mnt path

These are normal Linux nsfs representations for persisted mount namespaces.

Root cause

In codex-rs/linux-sandbox/src/daemon_mounts.rs, check_mounts() parses both the mount root and destination using mount_path():

let root = mount_path(root)?;
let destination = mount_path(destination)?;

mount_path() then rejects non-absolute decoded values:

if !path.is_absolute() {
    return Err(io::Error::other("mountinfo path is not absolute"));
}

Calling mount_path("mnt:[4026532835]") deterministically produces the observed error. The first nsfs line therefore aborts sandbox construction before bubblewrap or the requested command runs.

Expected behavior

Valid nsfs mount roots such as mnt:[...] should not cause sandbox construction to fail. The mount-alias hardening should handle or safely ignore mountinfo roots whose semantics are not ordinary absolute filesystem paths, while preserving the intended isolation guarantees.

Actual behavior

Any filesystem-restricted command fails during bubblewrap argument construction on this host before command execution begins.

Additional notes

• No system mounts, snapd configuration, Codex configuration, or sandbox settings were changed as part of diagnosis.
• The Codex processes were not in a different mount namespace from the invoking shell.
• The failure is specific to the newer mountinfo validation path; the same machine did not hit this error with Codex 0.154.0.
• No workaround that disables bubblewrap or weakens the sandbox has been applied.

Start in codex-rs/linux-sandbox/src/daemon_mounts.rs, reading check_mounts() and mount_path() and reproducing the failure with the nsfs mountinfo entries in the report. Done means valid mnt:[...] nsfs roots no longer abort sandbox construction, while mount-alias hardening and isolation guarantees remain intact.