RFC BI P1 ships two opt-in answers to the distroless-runtime-can't-run-code problem. Answer 1: the loomcycle-toolbox image is the SAME loomcycle binary on a Debian base preloaded with a dev toolchain (Python, Go, Rust, C++, Node + git, gh, curl, jq, rsync, wget, unzip, sqlite3) at the same uid 65532 and mount paths — a drop-in image swap that makes the existing Bash tool and Bashbox host-command fallback usable. Isolation is weak by design; single-tenant / trusted only. Answer 2: for untrusted / multi-tenant code, a standalone builder sidecar runs each session in a dedicated ephemeral container with --network none, --read-only rootfs, tmpfs /work, --cap-drop=ALL, no-new-privileges, non-root, cpu/mem/pids capped, and a pluggable --runtime (runc → runsc → kata). Loomcycle stays distroless and drives it over HTTP-MCP; loomcycle never runs a container engine itself. Six tools (sandbox_open, exec, write, read, close, list); one long-lived container per session for a compile-test-fix loop; constant-time bearer auth; principal-owned sessions; TTL GC plus boot orphan-sweep via a loomcycle.managed=1 label. Answer 3: the sandbox bundle. Enable with LOOMCYCLE_PRESETS=base,sandbox; registers the dev/sandbox agent + skill + mcp_servers.sandbox wiring. Additive: no wire RPCs, no schema migration; adapters bump to 1.23.0 in lockstep. v1.23.1 patch adds HOME in the fallback env for Go, Cargo, npm, pip caches.
Grok Walks Off With Your Repo? When the "Smartest Assistant" Becomes the Most Dangerous Tool