feat(gpu): support explicit all-GPU sandboxes on Docker Desktop WSL #4849

User Story

We use OpenShell to run GPU workloads inside isolated sandboxes and need Docker Desktop WSL support for our OpenShell 0.1.x upgrade. We have directly tested the proposed workflow on an ARM64 NVIDIA RTX Spark N1X host. This is the independently deliverable WSL slice of #4837; that issue retains the broader Jetson and integration qualification work.

Problem Statement

The Docker driver at #4204 revision 33350a881f55011286e7c3a68d8007e43e50e0bf supports CDI GPU selection. We need an explicit OpenShell-owned NVIDIA injection path for Docker Desktop WSL where usable CDI is unavailable. External workload recreation does not preserve the split runtime's ownership of bootstrap credentials, networking and restart identity.

Impact / Why This Matters

This blocks the Docker Desktop WSL GPU workflow needed for our upgrade. A direct Docker CUDA probe works on our host, but callers need that capability through normal OpenShell sandbox creation and lifecycle operations with enforcement active.

Proposed Design

Allow a gateway operator to enable an explicit all-GPU selection for Docker Desktop WSL. Create the sandbox through the normal OpenShell CLI, retain runtime ownership and isolation, and preserve the selection across sandbox and gateway restarts. Keep ordinary CDI selection unchanged. Unsupported hosts or conflicting selections must fail clearly.

Suggested UX

With the gateway operator's allow_driver_config enabled:

openshell sandbox create --gpu \
  --driver-config-json '{"docker":{"nvidia_wsl_gpus":"all"}}' \
  --from <gpu-workload-image> -- <command>

The setting explicitly selects all GPUs. It must not silently convert a request for one GPU into access to all GPUs.

Acceptance Criteria

• Normal OpenShell creation supports explicit NVIDIA all-GPU injection on Docker Desktop WSL, without requiring usable CDI or externally recreating the workload.
• Require operator opt-in and reject unsupported daemons, conflicting CDI configuration, invalid modes and explicit GPU counts for this all-GPU mode.
• Demonstrate CUDA initialization, enumeration, allocation and kernel execution as a non-root workload on the recorded ARM64 Docker Desktop WSL host.
• Preserve workload identity, explicit GPU selection and sandbox data through sandbox stop/start and gateway restart; repeat CUDA validation afterward.
• Keep Landlock, seccomp, capability restrictions and workload network isolation active. Demonstrate filesystem and direct network denials.
• Retain bootstrap credential custody within OpenShell, reject mismatched protected GPU selection and clean up owned resources after deletion or failed creation.
• Document configuration, supported scope and validation limits in the same PR.

Scope Boundaries

Initial hardware qualification is ARM64 Docker Desktop WSL on NVIDIA RTX Spark N1X with explicit all-GPU selection. Jetson, x86 hardware qualification, individual-device selection on multi-GPU hosts, Windows/Docker Desktop reboot, model inference and downstream compatibility-suite qualification remain outside this slice. This issue does not close #4837. Existing gateway endpoint configuration is used; no automatic WSL gateway-network discovery is proposed here.

Alternatives Considered

• CDI remains the normal path; feat(gpu): derive Docker sandbox requirements from CDI specs #4204 supplies the parent work but does not establish the non-CDI workflow requested here.
• External container recreation breaks runtime ownership and is not the proposed solution.
• Middleware, interceptors and inference providers do not own Docker workload GPU injection.
• Requiring all users to configure CDI would not establish support for the targeted host configuration.

Prototype Evidence

The local prototype and hardware results are summarized in #4837 (comment). The tested host uses Ubuntu24.04 WSL2, Docker Desktop4.96.0 / Engine29.9.1 and NVIDIA620.66. The prototype passed non-root CUDA kernel execution, enforcement checks, sandbox and gateway restarts, identity/state continuity and cleanup. The driver suite passed165 tests on macOS and ARM64 Linux, with two existing ignored tests.

This is a request for maintainer acceptance of the scoped workflow. It is not a claim that a supported release has shipped. The prototype remains unpublished pending issue acceptance.