Support Apple container runtime (container CLI) as Docker alternative / clarify compatibility #566
Description
Problem Statement
OpenShell has a hard dependency on a Docker daemon (via /var/run/docker.sock or Docker-compatible API).
This prevents usage with newer container runtimes that:
- support OCI images
- provide container lifecycle management
- but do NOT implement full Docker daemon semantics
A concrete example is Apple’s container runtime:
https://opensource.apple.com/projects/container/
Even when a Docker-compatible API shim is provided (e.g. via socktainer), OpenShell fails during gateway bootstrap due to:
- assumptions about Docker socket location
- reliance on Docker-specific behavior beyond standard API compatibility
This limits portability and prevents OpenShell from running on emerging native runtimes (especially on macOS where Docker Desktop is increasingly avoided).
Proposed Design
OpenShell should treat the container backend as a runtime interface rather than assuming Docker everywhere.
Internally, gateway bootstrap and sandbox lifecycle management should depend on a ContainerRuntime abstraction that covers the operations OpenShell actually needs, such as pulling images, creating containers, starting/stopping containers, log access, exec, and required networking or volume setup.
The current Docker implementation would remain the default backend, but it would become one runtime implementation instead of the hardcoded system model. A second implementation could target Apple container directly, and other runtimes could be added later if they satisfy the same runtime contract.
Gateway startup should no longer assume /var/run/docker.sock or Docker-specific behavior by default. Instead, OpenShell should select the runtime from configuration or environment, initialize the matching backend, and validate the runtime capabilities required for gateway launch. If a runtime does not support a required feature such as port mapping, volumes, or exec, OpenShell should fail early with an explicit capability error rather than failing through Docker client initialization.
At the user interface level, runtime selection should be explicit and stable. For example:
export OPEN_SHELL_RUNTIME=docker
export OPEN_SHELL_RUNTIME=apple-container
### Alternatives Considered
### Only fix `DOCKER_HOST` handling
A narrower alternative is to keep Docker as the only supported backend, but make OpenShell fully respect `DOCKER_HOST` and stop assuming `/var/run/docker.sock`.
That would improve compatibility with Docker-compatible shims and remote daemons.
**Why this is better than the status quo:**
- Minimal implementation effort
- Removes hardcoded socket assumptions
- Allows some non-default Docker environments to work
**Why this is still not enough:**
- It does not address deeper Docker-specific assumptions during gateway bootstrap
- It still treats Docker as the only real backend
- Compatibility with runtimes like Apple `container` would remain accidental rather than designed
This is a good short-term improvement, but not a complete design.
### Rely on Docker API shims such as `socktainer`
Another alternative is to recommend that users run Apple `container` behind a Docker-compatible shim.
**Why this is weaker:**
- Shims provide only partial compatibility
- Failures become hard to diagnose because OpenShell cannot distinguish between missing features and shim bugs
- OpenShell behavior would remain dependent on undocumented Docker API expectations
This approach may be useful for experimentation, but it is too fragile to be the primary design.
### Agent Investigation
_No response_
### Checklist
- [x] I've reviewed existing issues and the architecture docs
- [x] This is a design proposal, not a "please build this" request