feat: integrate Tensorlake MicroVM sandbox as a new sandbox backend

[ajjimeno]

Summary

Add Tensorlake as a first-class sandbox provider, giving users access to Firecracker MicroVM-backed sandboxes with sub-second startup, durable filesystem state, and automatic lifecycle management.

Context

The blackbox CLI already supports sandboxing via docker, podman, and macOS sandbox-exec. Tensorlake offers a complementary cloud-based option using Firecracker MicroVMs — lightweight, isolated, and suitable for CI/CD or environments where Docker is unavailable. This PR wires Tensorlake into the existing sandbox abstraction with minimal surface area changes so the rest of the CLI is unaffected.

Changes

• SandboxConfig type — extended the command union in packages/core to include 'tensorlake'
• sandboxConfig.ts — added 'tensorlake' to the valid commands list; maps to the tl CLI binary for availability checking; skips the container image URI requirement (Tensorlake provisions its own MicroVMs); added tensorlake as the last fallback in the auto-detection chain (sandbox-exec → docker → podman → tensorlake)
• sandbox.ts — implemented start_tensorlake_sandbox() which:
  1. Creates a MicroVM via tl sbx new (JSON output with text-parse fallback)
  2. Copies the current workspace into the sandbox via tl sbx cp
  3. Installs Node.js and the blackbox CLI inside the sandbox (best-effort, non-fatal)
  4. Forwards all relevant API keys and environment variables (GEMINI_API_KEY, TENSORLAKE_API_KEY, BLACKBOX_API_KEY, etc.)
  5. Runs blackbox inside the sandbox with the original CLI arguments, streaming stdio back to the host
  6. Terminates the sandbox on exit, SIGINT, and SIGTERM
• TENSORLAKE_API_KEY forwarding also added to the docker/podman --env block for completeness
• sandboxConfig.test.ts (new) — 8 unit tests covering the full Tensorlake config-loading path

Key Implementation Details

Tensorlake sandboxes are identified by an opaque sbx-* ID returned by the tl CLI. The SANDBOX env var is set to tensorlake-<sbx-id> inside the MicroVM so the CLI's existing guard against double-sandboxing continues to work. The tl binary is the indicator used for availability detection rather than tensorlake because that is the actual installed binary name.

Use Cases

# Explicit opt-in
export GEMINI_SANDBOX=tensorlake
export TENSORLAKE_API_KEY=tlk_...
blackbox

# Via CLI flag
TENSORLAKE_API_KEY=tlk_... blackbox --sandbox tensorlake

# Auto-detected when only tl is installed
GEMINI_SANDBOX=true TENSORLAKE_API_KEY=tlk_... blackbox

# Optional tuning
TENSORLAKE_CPUS=4 TENSORLAKE_MEMORY=8192 TENSORLAKE_TIMEOUT=7200 blackbox

Testing

Unit tests (no Tensorlake account needed)

cd packages/cli
../../node_modules/.bin/vitest run src/config/sandboxConfig.test.ts

All 8 tests should pass covering: explicit env var, missing tl binary error, CLI argv, settings file, image override ignored, already-inside-sandbox guard, auto-detection priority, and tl-only auto-detection.

Integration test (requires tl CLI + TENSORLAKE_API_KEY)

export TENSORLAKE_API_KEY=tlk_...
export GEMINI_SANDBOX=tensorlake
blackbox --version   # should print version from inside a MicroVM

Verify via tl sbx list that a sandbox was created and then terminated after the command exits.

TypeScript type check

npm run build -w packages/core
node_modules/.bin/tsc --noEmit -p packages/cli/tsconfig.json

No new errors in sandbox or tensorlake files.