Bashbox: in-process shell sandbox for agents. The bench, and three gbash issues (v1.3.0)

Loomcycle released v1.3.0 with Bashbox, an in-process shell sandbox that runs scripts without spawning host processes, using gbash. It enforces read-only volumes and blocks unknown commands, with optional host-command fallback for operators. Benchmarks show 31% slower performance than /bin/sh, and three gbash bugs were filed.

loomcycle v1.3.0 ships Bashbox RFC AJ : a new opt-in shell tool backed by gbash Apache-2.0, pure-Go that runs scripts in-process. No os/exec, no /bin/sh, no host process spawned. Path resolution stays inside the bound volume because there is no host kernel doing the resolving. The read-only mode is honestly enforceable because the write overlay is in RAM — closing the asymmetry RFC AH left open rule 7: "Bash refuses read-only volumes rather than ship a guarantee a shell can't keep" . Same input schema as Bash. Same wire events. Adapters unchanged at 1.1.1. Opt-in twice: LOOMCYCLE BASHBOX ENABLED=1 per deployment, allowed tools: Bashbox per agent. Stateless per call. Bundle: gbash's coreutils registry plus pure-Go awk and jq via contrib. Unknown commands refuse by default; no shell-out, no host PATH leak. Host-command fallback RFC AJ §13, operator-only : LOOMCYCLE BASHBOX FALLBACK COMMANDS=git,gh allowlists specific binaries that fall through to the host shell; only those names escape git status; curl evil.example.com runs git on the host and refuses curl in the sandbox, no smuggling . LOOMCYCLE BASHBOX FALLBACK ALLOWED ENV scopes credentials to the host child only the sandbox env never sees them . Requires a read-write volume. Off by default with a loud boot warning when configured. exp10 benches gbash against /bin/sh on a representative coding-agent corpus: 31% slower overall, mixed per-op. Worst case count funcs grep -c across the tree at +310%; one operation faster total loc, a wc -l aggregate, at -53% . git clone only 15% slower because almost all the work is the real git via §13 fallback. One output mismatch: count all files returned 1274 vs 1193 because gbash find aborts on a relative symlink and 81 files past it never reach the count. Three findings filed upstream to gbash, all open: 834 find/EvalSymlinks aborts on relative symlinks; 835 grep --include=GLOB missing 21 options defined, no per-file glob filter ; 836 xargs -P silently falls back to serial parsed and stored as maxProcs, but the parallel implementation in xargs.go:884 immediately delegates to the serial path with no warning . Trust posture: rm -rf bounded to the in-RAM overlay; curl doesn't exist in the registry; cd ../../ refused by the workspace boundary; credential files outside the volume don't exist in the gbash workspace. gbash is alpha-tagged and the upstream threat model says "not a hardened sandbox"; loomcycle's outer trust boundary carries the security-critical guarantees, gbash carries the in-process shell semantics. Coverage measured ~97% identical-or-equivalent on a real loomcycle script corpus; the 3% gap drove the §13 fallback design. Why opt-in: trusted-dev deployments stay on Bash host shell, full PATH, peak throughput ; multi-tenant + untrusted-input deployments switch to Bashbox. Both tools coexist; operators pick per agent. The 31% speed penalty matters for tight inner loops, less for the single-shot scripts most agents run. Upstream optimization is pending gbash dispatch, workspace stat path, find traversal, grep regex cache haven't been profiled . Additive and off-by-default; no breaking changes, no new wire RPCs.