openai/codex · error

failed to register synthetic bubblewrap mount target {}: {er

Error message

failed to register synthetic bubblewrap mount target {}: {err}

What it means

After create_dir_all succeeds, the launcher writes the per-PID marker file (fs::write of marker_dir/<pid>) recording the target kind (SYNTHETIC vs EXISTING contents) used by owner checks and cleanup. The write panics on storage-level failures: ENOSPC or EDQUOT when the temp filesystem fills between create and write, EIO from failing storage. Registry mutations are flock-serialized across processes (with_synthetic_mount_registry_lock), so external racing is not the expected cause.

Source

Thrown at codex-rs/linux-sandbox/src/linux_run_main.rs:978

                    && synthetic_mount_marker_dir_has_active_synthetic_owner(&marker_dir)
                {
                    match target.kind() {
                        crate::bwrap::SyntheticMountTargetKind::EmptyFile => {
                            crate::bwrap::SyntheticMountTarget::missing(target.path())
                        }
                        crate::bwrap::SyntheticMountTargetKind::EmptyDirectory => {
                            crate::bwrap::SyntheticMountTarget::missing_empty_directory(
                                target.path(),
                            )
                        }
                    }
                } else {
                    target.clone()
                };
                let marker_file = marker_dir.join(std::process::id().to_string());
                fs::write(&marker_file, synthetic_mount_marker_contents(&target)).unwrap_or_else(
                    |err| {
                        panic!(
                            "failed to register synthetic bubblewrap mount target {}: {err}",
                            target.path().display()
                        )
                    },
                );
                SyntheticMountTargetRegistration {
                    target,
                    marker_file,
                    marker_dir,
                }
            })
            .collect()
    })
}

fn register_protected_create_targets(
    targets: &[crate::bwrap::ProtectedCreateTarget],
) -> Vec<ProtectedCreateTargetRegistration> {

View on GitHub (pinned to 339751715c)

Solutions

  1. Check and free space on the filesystem holding TMPDIR (df -h ${TMPDIR:-/tmp}), then retry.
  2. If /tmp is tmpfs, remount with a larger size (mount -o remount,size=2G /tmp).
  3. Check dmesg for I/O errors when the errno is not ENOSPC.
  4. Retry once after space is freed; transient exhaustion from a finishing session clears itself.

Example fix

# before: registry tmpfs fills under parallel sandboxed runs
mount -t tmpfs -o size=512m tmpfs /tmp

# after: headroom for marker files and synthetic targets
mount -t tmpfs -o size=4g tmpfs /tmp
Defensive patterns

Strategy: validation

Validate before calling

fn temp_free_bytes(min: u64) -> bool {
    let dir = std::env::temp_dir().canonicalize().unwrap_or_default();
    let c = std::ffi::CString::new(dir.as_os_str().as_encoded_bytes()).unwrap_or_default();
    let mut st: libc::statvfs = unsafe { std::mem::zeroed() };
    unsafe { libc::statvfs(c.as_ptr(), &mut st) } == 0 && (st.f_bavail as u64) * (st.f_bsize as u64) >= min
}

Prevention

When it happens

Trigger: A run with synthetic mount targets where the tmpfs or disk backing TMPDIR is exhausted or returns I/O errors exactly during registration, for example parallel sessions filling a size-capped /tmp.

Common situations: tmpfs /tmp with a small size= under concurrency; disk-full CI runners; degraded disks returning EIO; quota enforcement kicking in mid-write.

Related errors


AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/fbe022bbb4ccaa9d. Report an issue: GitHub.