Bubblewrap process boundary

Investigated 2026-08-01 against the upstream security model and release 0.11.2. FractalOps currently installs the distribution package in the workspace image and pins the deployed outer image by digest. The inner Bubblewrap package version is not yet a reproducible source pin; that is explicit build debt, not an implied 0.11.2 deployment.

Native path

Use Bubblewrap only to construct each provider process’s mount, PID, IPC, and temporary filesystem view. The launcher must explicitly choose every writable path.
Bind the owned worktree and profile state writable; expose peer profiles, shared source, Git common metadata, runtime binaries, and observation roots read-only or not at all.
Require a private /tmp, PID namespace, dropped capabilities, and PR_SET_NO_NEW_PRIVS. Pair the boundary with a generation-owned cgroup v2 leaf.
Keep identity, authorization, lease fencing, and reaping outside Bubblewrap. It cannot prove any of them.

Traps

Bubblewrap is a low-level mechanism, not a complete sandbox policy. Security is the launcher argument set; bwrap appearing in a process command proves little by itself.
User namespaces may be disabled by the host or container runtime. Admission must fail closed instead of launching the provider without isolation.
apt-get install bubblewrap against mutable package indexes can change bytes on an identical source revision. Before the next workspace rebuild, pin the base image by digest and lock the package repository snapshot/version; record bwrap --version in build provenance.
Do not change the workspace image during an active 24-hour soak. Any containment-byte change requires a new digest and fresh evidence.

Authoritative references: Bubblewrap README, release 0.11.2, and security policy.