Add smolvm as a microVM-based sandbox backend

[fwilhe]

Summary

Add smolvm as an optional sandbox backend for command execution, providing hypervisor-level isolation as an alternative to the existing macOS seatbelt approach.

Motivation

The current sandbox implementation uses macOS seatbelt (syscall-level filtering within the same kernel). While effective and low-overhead, it:

• Only works on macOS
• Can potentially be circumvented by kernel-level exploits
• Does not provide a reproducible execution environment

smolvm offers hardware-isolated microVMs with:

• Sub-second cold boot (<200ms) — acceptable for tool call latency
• Cross-platform: macOS (Hypervisor.framework) + Linux (KVM)
• Built-in network control: opt-in networking with host allowlists
• Volume mounts: expose project directories into the guest
• OCI images: pre-bake reproducible dev environments
• Rust-native: same language as code-assistant

Proposed Design

New executor: SmolVmCommandExecutor

Implements the existing CommandExecutor trait in crates/command_executor/:

pub struct SmolVmCommandExecutor {
    machine_name: String,
    policy: SandboxPolicy,
    workspace_mount: PathBuf,
}

Lifecycle

1. Session start: Create/start a persistent VM per session
   • smolvm machine create --name <session-id> -v /project:/workspace [--net] [--allow-host ...]
2. Tool calls: Execute commands inside the running VM
   • smolvm machine exec --name <session-id> -- sh -c "<command>"
   • Pipe stdout/stderr to StreamingCallback
3. Session end: Stop (or optionally destroy) the VM
   • smolvm machine stop --name <session-id>

Policy mapping

SandboxPolicy	smolvm behavior
DangerFullAccess	bypass — use DefaultCommandExecutor
ReadOnly	VM with read-only volume mount, no network
WorkspaceWrite	VM with read-write volume on project root, network per policy

Configuration

New sandbox mode selectable via CLI flag or session config:

--sandbox-mode smolvm
--sandbox-image alpine  # or a custom OCI image with dev tools

Trade-offs vs. Seatbelt

	Seatbelt	smolvm
Isolation	Syscall filtering (same kernel)	Hypervisor boundary (separate kernel)
Overhead	~0ms	~200ms boot (persistent VM amortizes this)
Platform	macOS only	macOS + Linux
Environment	Host tools available	Guest tools only (OCI image)
Dependency	Built-in (/usr/bin/sandbox-exec)	Requires smolvm installed + signed

Implementation Steps

1. Add SmolVmCommandExecutor to crates/command_executor/
2. Add VM lifecycle management (create/start/stop) tied to session lifecycle
3. Map SandboxPolicy to smolvm flags (network, volumes, allow-hosts)
4. Wire up streaming output from smolvm machine exec
5. Add smolvm as a --sandbox-mode option alongside seatbelt and full-access
6. Documentation and tests (integration tests gated on smolvm availability)

References

• smolvm: https://github.com/smol-machines/smolvm
• Current sandbox plan: docs/sandbox-plan.md (Phase 4 mentions Linux backend placeholders)
• Command executor trait: crates/command_executor/src/lib.rs
• Sandboxed executor: crates/command_executor/src/sandboxed_executor.rs