Add Apple Container as an OpenShell compute backend

[shiju-nv]

Problem Statement

OpenShell does not currently have a first-class compute driver for Apple's Container runtime. On macOS, a user who wants to run local OpenShell sandboxes through Apple's native Container runtime cannot select apple-container in gateway configuration, so the gateway cannot create, resume, stop, delete, list, or watch those sandboxes through the normal OpenShell compute-driver contract.

This matters because Apple Container has reached a stable 1.0.0 release, and Apple documents Container as a tool for creating and running Linux containers as lightweight virtual machines on Mac. OpenShell users on Apple silicon should be able to use that runtime without maintaining a local out-of-tree driver or pretending it behaves like Docker or Podman.

Proposed Design

Add an opt-in apple-container compute driver implemented as a new openshell-driver-apple-container crate.

The driver should:

• use Apple's container CLI as the runtime boundary;
• use --format json where the Apple CLI provides machine-readable output;
• implement the existing OpenShell compute-driver lifecycle: validate, create, resume, stop, delete, get, list, and watch;
• register apple-container as a ComputeDriverKind;
• keep Apple Container explicit-only and out of auto-detection, preserving the existing Kubernetes, Podman, Docker auto-detection order;
• wire the driver into gateway config, telemetry, server runtime selection, and local mTLS defaults;
• derive a host-reachable supervisor callback endpoint for Apple Container guests, because 127.0.0.1 inside the guest is not the macOS host gateway;
• default that callback path to host.container.internal when no explicit endpoint is configured;
• register any discovered Apple Container network gateway listener needed for guest-to-host callback traffic;
• stage sandbox JWT and optional guest TLS material as host files mounted read-only into the guest;
• reject partial TLS configuration and non-empty Apple driver_config payloads until the driver has an explicit supported config schema;
• document the driver, explicit selection, Apple CLI prerequisite, integer CPU-limit behavior, TLS/JWT expectations, and supervisor delivery model.

The first change request should remain scoped to the Apple Container driver and the minimum config, docs, and server wiring required to make it usable.

Alternatives Considered

Keep Apple Container support out of tree.

This avoids OpenShell maintenance cost, but it leaves macOS users without a supported Apple-native backend after the runtime has reached a stable release. Users would still need local scripts or another runtime even when Apple's Container stack is installed.

Reuse the Docker or Podman drivers.

Those drivers do not model Apple Container's CLI, one-VM-per-container topology, or guest-to-host callback needs.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request

[drew]

I think this is worth considering.

We're currently working through improvements to the Sandbox Runtime, #1720. I'd like to finish that effort before committing to another in-tree driver.

The current OpenShell VM implementation uses the same virtualization framework as containers so we do actually have an Apple native solution already. Ideally we would just have a single Apple native solution.