User Story
As an OpenShell CLI user, I want sandbox create --from to behave consistently across compute drivers and local or remote gateways, so that the command does not depend on an implicit local Docker-only build path.
Problem Statement
openshell sandbox create --from currently treats a local Dockerfile path, or a directory containing a Dockerfile, as a request to build an image with the caller's local Docker daemon. This behavior only works with a local Docker-backed gateway and makes the meaning of --from depend on the selected driver and gateway location.
This contract should be removed before 0.1.0. --from should identify an existing sandbox or container image, not perform a local image build.
Impact / Why This Matters
The current convenience path creates a Docker-specific CLI contract that cannot work uniformly with Podman, Kubernetes, VM, MXC, or remote gateways. It also adds a hidden dependency on the caller's Docker daemon and makes scripts non-portable across gateway configurations.
Callers can build explicitly with docker build -t <image> ... and then pass that image tag to openshell sandbox create --from <image>. For non-local drivers, callers can push the image to a registry reachable by the driver. This workaround is explicit and sufficient, so retaining a second build workflow in the OpenShell CLI is unnecessary.
Proposed Design
Keep --from as the source selector for existing sandbox names and container image references. Remove detection and building of local Dockerfile paths and directories. When a value clearly refers to a local path, return an actionable error directing the caller to build and tag the image first, then pass the resulting image reference to --from.
Acceptance Criteria
Alternatives Considered
Retain the local Docker convenience behavior. This preserves an existing shortcut but leaves --from driver-dependent and keeps a hidden local Docker requirement.
Generalize image builds across drivers or add a remote build service. That is a substantially larger product and security surface and is not justified when callers can use standard image-build tooling directly.
Parent Issue
User Story
As an OpenShell CLI user, I want
sandbox create --fromto behave consistently across compute drivers and local or remote gateways, so that the command does not depend on an implicit local Docker-only build path.Problem Statement
openshell sandbox create --fromcurrently treats a local Dockerfile path, or a directory containing a Dockerfile, as a request to build an image with the caller's local Docker daemon. This behavior only works with a local Docker-backed gateway and makes the meaning of--fromdepend on the selected driver and gateway location.This contract should be removed before
0.1.0.--fromshould identify an existing sandbox or container image, not perform a local image build.Impact / Why This Matters
The current convenience path creates a Docker-specific CLI contract that cannot work uniformly with Podman, Kubernetes, VM, MXC, or remote gateways. It also adds a hidden dependency on the caller's Docker daemon and makes scripts non-portable across gateway configurations.
Callers can build explicitly with
docker build -t <image> ...and then pass that image tag toopenshell sandbox create --from <image>. For non-local drivers, callers can push the image to a registry reachable by the driver. This workaround is explicit and sufficient, so retaining a second build workflow in the OpenShell CLI is unnecessary.Proposed Design
Keep
--fromas the source selector for existing sandbox names and container image references. Remove detection and building of local Dockerfile paths and directories. When a value clearly refers to a local path, return an actionable error directing the caller to build and tag the image first, then pass the resulting image reference to--from.Acceptance Criteria
openshell sandbox create --fromno longer invokesdocker buildor otherwise builds an image.--from.0.1.0breaking CLI change and showdocker build -t <image> ...followed byopenshell sandbox create --from <image>.Alternatives Considered
Retain the local Docker convenience behavior. This preserves an existing shortcut but leaves
--fromdriver-dependent and keeps a hidden local Docker requirement.Generalize image builds across drivers or add a remote build service. That is a substantially larger product and security surface and is not justified when callers can use standard image-build tooling directly.
Parent Issue
0.1.0#2565