Project images and desktop admission

Sandbox owns the root filesystem and desktop image contract in plugins/sandbox/lib/rootfsCatalog.mjs. The desktopCapability lookup reads ROOTFS_RECIPES['project-base'].desktop.imageContracts, which is the authoritative admission catalog. Documentation must refer to that catalog rather than pinning support to a particular revision.

An environment keeps its original image and artifact provenance through recreation. Recreate does not migrate an existing Project to a newer image; unsupported older images need a new Project to gain the current desktop contract. The host validates the guest's reported geometry against the admitted contract before accepting desktop results.

The shared controller and transport are described in Desktop runtime. The user guide explains how to use a Project desktop without implementation identifiers.

Packaged Project desktop

Image project-base@19, payload 13, retains correct AT-SPI state bits, derives GTK 4 menu labels from label relations or unambiguous descendants with provenance, includes transient popups in owner scope and carries the application of coordinate actions while skipping unrelated unresponsive accessibility applications. A starting window returns a useful partial look with success: true and snapshot_state: incomplete; it does not prove absence or completeness. Desktop admission is determined by rootfsCatalog.mjs::desktopCapability and the recipe's desktop.imageContracts; revisions without a contract have no supported desktop. The daemon and guest use one strict result parser without compatibility branches or optional fallbacks for older guests. Existing materialized Projects retain their image through start, restart and boot recovery. Recreate and restore involving a retired image are refused before stopping or changing the environment, including requests recovered after daemon restart. Create a new Project to use the current image.

Machine privilege and ownership boundary

The common host ownership pass preserves special permission bits on non-symlinks after Linux lchown clears them, and confines existing security.capability attributes to the machine UID namespace. Raw v2 attributes become v3 with the machine root UID; existing v3 rootids are mapped into that range, while already-mapped rootids remain stable. Before chown, a bounded user.elowen.ownership-privileges journal records special modes and confined capabilities. A retry restores them even when ownership was already shifted and then removes the journal. The host never restores a host-effective raw v2 capability. Published archives preserve packaged capability attributes; absent attributes remain absent. Symlink targets are never followed for restoration. The envelope does not impose machine-wide NoNewPrivileges: workloads already have guest-root execution, PrivateUsers maps guest root into an unprivileged host UID range, and the existing capability drop remains intact. In-guest setuid therefore adds no host authority. Chrome uses its packaged sandbox without application flags or configuration overrides; CAP_SYS_PTRACE remains dropped.

Artifact build and proof

The current recipe is project-base@19, with desktop payload 13 and its pin in lib/rootfsArtifacts.json, at rootfs-project-base-v19/project-base-v19.tar.gz. It is the only published pin and admitted desktop contract in this release. A changed guest payload or recipe needs a new image revision and independently verified archive before publication; never rebuild changed sources over a served archive. Existing materialized Projects retain their original disk identity independently of the download catalogue.

Artifact build and proof

Retired pins are removed from the catalogue. Existing materialized disks need no original archive to restart; recreate and restore of retired images fail explicitly without an image fallback. Never replace a served current archive or hand-type a digest. The host unit tests fake the guest CLI, so they prove admission and protocol validation but not GNOME, portals, accessibility geometry, RFB performance or survival across su desktop. Those need a disposable current-image guest and the image/agent smoke checks before rollout. Existing non-desktop machine proof retains its ownership guard and reserved Project identities; the old Python/X11 desktop proofs have been removed.