Safe code execution: the toolbox image and a sandbox sidecar (v1.23.0 to v1.23.1)

Loomcycle released v1.23.0–v1.23.1 with two opt-in approaches for safe code execution: a toolbox image for trusted single-tenant environments and a sandbox sidecar for untrusted multi-tenant code. The sandbox sidecar runs each session in an ephemeral container with strict security constraints, supporting pluggable runtimes and HTTP-MCP integration. The release also adds a sandbox bundle and a patch for HOME environment fallback.

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.