Context

The current sandbox surface in crates/tui/src/sandbox/ is platform-native and
already best-in-class for an in-process Rust agent:

• macOS: Seatbelt (seatbelt.rs)
• Linux: Landlock (landlock.rs)
• Windows: restricted token (windows.rs)

A user asked whether we should add Alibaba's
OpenSandbox (~10.4k stars, very
active) as a fourth backend.

Decision

Skip OpenSandbox for now. It's a service-mesh sandbox for AI agents:
Python/Go server, Docker+Kubernetes runtime, multi-language SDKs (Python,
Java, JS, .NET, Go — no Rust). It does isolate FS/network/syscalls, but
only by orchestrating gVisor/Kata/Firecracker containers via a daemon. Wrong
shape for crates/tui/src/sandbox/: it would require Docker as a hard runtime
dep, replace (not complement) seatbelt/landlock, and stand up a FastAPI
server next to the TUI. Reasonable as a future MCP server the user runs
themselves, not an in-process backend.

Other Alibaba-adjacent projects evaluated: ChatLearn (RLHF training, no
overlap), qwen-code (TS Gemini-CLI fork, competitor not backend),
AgentScope runtime (Docker-orchestrated, same shape mismatch). All skip.

What this issue tracks

If a future "stronger isolation" requirement arrives — e.g. running untrusted
agent-generated code on Linux servers — track adding a single optional backend:

• fctools (rust-firecracker/fctools) — real Rust SDK for Firecracker microVMs. Linux-KVM only, ~125ms boot, ~5MB memory overhead per VM.

Constraints if/when we ship this:

• Behind a Cargo feature flag (--features sandbox-firecracker) so the
  default build doesn't pull a heavy dep.
• Linux-only; macOS/Windows users keep their current native sandbox.
• Opt-in at runtime via [sandbox] mode = "firecracker"; never default.
• Vendor a small reference rootfs or document how to build one.

Reference

Existing ai-sandbox / koda-sandbox / ai-jail crates already mirror the
seatbelt+landlock+restricted-token split we have. Worth reading
ai-sandbox for prior art on a Linux
fallback when landlock is unavailable on older kernels (<5.13) — that's a
much smaller second-step than a Firecracker backend.

Out of scope here

• Hosted-relay sandboxing (e.g. e2b cloud) — overlaps with Whalescale's
  control-surface story; not for deepseek-tui.
• Replacing the existing seatbelt/landlock backends.
• Adding Docker as a runtime dependency.

Status

Tracking only. Promote to "in progress" when we have a concrete user request
that the current sandbox surface can't satisfy.