Thanks Kevin, that's fair for a stable hierarchy, but it doesn't really hold for this workload. The clone/disk-image approach assumes the input set is something you provision once and then snapshot per action. Bazel's isn't. The files I project live in output_base (external repo cache, bazel-out, action outputs), which is rewritten constantly across and within builds — so there's nothing stable to clone, and an image you have to unmount to clone cheaply is a non-starter when it's written on basically every action. The inputs are also spread across multiple volumes, and clonefile is same-volume only, so the cross-volume case can't clone at all — you'd have to first copy everything into one place, which reintroduces the per-action materialization cost (over a moving target) that passthrough is meant to avoid. On EndpointSecurity — interesting pattern, and I see the appeal over sandbox-exec, but it's the same model: observe an access and allow/deny it. Bazel's sandbox is already built on sandbox
Topic:
App & System Services
SubTopic:
Core OS
Tags: