[Feature] Add native Apple Containers support to Docker Sandbox

[Jubblin]

Use case
I don't want to install and run Docker Desktop just to get sandboxed agent runs — it's a heavyweight VM on top of an OS (macOS) that already ships a native, lightweight container runtime. Docker mode already exists as an alternative isolation backend to the Seatbelt cage; Apple's own container tool would let Apple Silicon users get that same stronger-filesystem-boundary isolation without the Docker Desktop dependency.

Proposal
Add Apple Containers as a third sandbox backend alongside the existing Seatbelt cage and Docker mode:

• Backend logic alongside the existing seatbelt/proxy code in src-tauri/src/sandbox.rs
• Surfaced as a new preset in src/lib/sandboxPresets.ts, matching how Docker mode is already exposed

Compatibility
Apple's container CLI requires macOS 15+ and Apple Silicon — this would need to be gated similarly to how the Seatbelt cage is already macOS-only, and further scoped to arm64 (Termic's baseline is macOS 12+, with Intel supported for dev).

Open question
Docker mode is currently experimental because network egress isn't restricted the way the in-process CONNECT proxy restricts the Seatbelt cage. Should an Apple Containers backend inherit that same allowlist proxy from day one, or ship with the same known limitation as Docker mode initially?

Related: #297 (exposing container CLI commands from within the sandbox) builds on this existing as a backend.

[Jubblin]

Implementation research: container run maps closely to the existing Docker backend

Compared the flag surface render_argv currently emits (src-tauri/src/docker.rs) against Apple's official container CLI (command reference):

Maps 1:1 (same syntax): -v host:container[:ro] (--mount also available), -e KEY=VALUE, --rm -i -t --name, -w (workdir), --cap-add/--cap-drop (accepts ALL, same as Docker), --user uid:gid (docker::host_uid_gid() could be reused as-is), --network, -p, --cpus, -m, --ulimit.

Gap — no equivalent: --security-opt no-new-privileges:true and --pids-limit aren't flags container run accepts. A render_argv-equivalent for this backend would have to drop both. Worth documenting explicitly in docs/sandbox.md as a known gap, the same way Docker mode's "network is unrestricted" gap is already documented, rather than silently omitting them. Partial mitigation: each Apple container already runs in its own dedicated lightweight VM (Virtualization.framework) rather than sharing a kernel the way Docker Desktop's Linux VM does, so the baseline blast radius is smaller regardless.

On the network gap specifically — this might be where an Apple Containers backend ends up ahead of Docker mode rather than inheriting the same gap. Each container gets its own network namespace in its own VM (not a shared bridge), and there's an early host-side container system pf prototype for scoping packet filters to one container's subnet (see apple/container#719) — closer in spirit to termic's own per-task CONNECT proxy allowlist than Docker's bridge model allows. Not stable yet, so I'd treat it as a fast-follow rather than a v1 blocker.

Prior art: openclaw/openclaw#91725 proposed nearly the same backend for a different project and confirmed the same close flag mapping, but was closed "not planned" (no reason visible in the issue) — worth a read before starting.

Also worth knowing about, not necessarily recommending: us/mocker is a third-party, unofficial Docker-CLI-compatible shim over the same Containerization framework. In principle docker_cmd() could point its binary at mocker instead of docker with near-zero backend changes. But it's AGPL, single-maintainer, and macOS 26+/Apple-Silicon-only — probably not the right dependency given CONTRIBUTING.md's "no new dependencies without justification." Flagging as the fastest possible prototype path, not the real solution.

Compatibility, confirmed: container requires macOS 15+ and Apple Silicon; some of its newer networking subcommands need macOS 26.

[simion]

Agreed on the implementation. We should convert existing docker implementation to support both and adapt the interface as needed. Docker sandbox should somehow be renamed Container sandbox or similar. Open to discussing terminology. Maybe we should even make it extendable like agents are? All the particularities of different container providers to be adaptable and fixable from a form. But the UI should be unified, one solution, sandbox via containers.