@@ -110,6 +110,15 @@ compute to zero, and VM retains its launch request and writable overlay beside
 a stop marker. Delete remains a separate operation that removes these
 resources.
 
+Gateway shutdown does not stop Docker or Podman sandbox containers. The
+gateway-owned VM driver process exits, so its running VM launchers exit with
+it. On gateway startup, persisted running intent for Docker, Podman, and VM is
+reconciled through the shared idempotent `StartSandbox` RPC before watch
+processing begins. This restarts a retained local resource when necessary and
+is a no-op when it is already running. Explicitly `Stopped` sandboxes are
+excluded from the sweep. Kubernetes workloads are cluster-owned and continue
+running without a startup `StartSandbox` call.
+
 ## Deletion Lifecycle
 
 Lifecycle requests use per-sandbox gates to serialize stop, start, and
 
@@ -26,6 +26,10 @@ policy. Start starts that same container, so files in the resolved OCI
 workspace remain available. A durably stopped sandbox is excluded from
 gateway startup recovery and stays stopped across gateway restarts. Delete
 continues to force-remove the container and clean up driver-owned material.
+Gateway shutdown does not stop running Docker containers. On startup, the
+gateway sends an idempotent `StartSandbox` request for each sandbox whose
+persisted phase requires running compute, recovering a retained container if
+the Docker runtime stopped it while the gateway was offline.
 
 Before creating the container, the driver inspects the final sandbox image and
 captures its immutable image ID, raw OCI `Config.User`, and OCI
 
@@ -1055,69 +1055,6 @@ impl DockerComputeDriver {
         }
     }
 
-    pub async fn stop_managed_containers_on_shutdown(&self) -> Result<usize, Status> {
-        let containers = self.list_managed_container_summaries().await?;
-        let targets = containers
-            .into_iter()
-            .filter_map(|container| {
-                let state = container.state.unwrap_or(ContainerSummaryStateEnum::EMPTY);
-                if container_state_needs_shutdown_stop(state) {
-                    summary_container_target(&container)
-                } else {
-                    None
-                }
-            })
-            .collect::<Vec<_>>();
-        let target_count = targets.len();
-        let mut stopped = 0usize;
-        let mut failures = Vec::new();
-        let stop_timeout_secs = self.config.stop_timeout_secs;
-
-        let mut stop_results = futures::stream::iter(targets.into_iter().map(|target| {
-            let docker = self.docker.clone();
-            async move {
-                let result = docker
-                    .stop_container(
-                        &target,
-                        Some(
-                            StopContainerOptionsBuilder::default()
-                                .t(docker_stop_timeout_secs(stop_timeout_secs))
-                                .build(),
-                        ),
-                    )
-                    .await;
-                (target, result)
-            }
-        }))
-        .buffer_unordered(16);
-
-        while let Some((target, result)) = stop_results.next().await {
-            match result {
-                Ok(()) => {
-                    stopped += 1;
-                }
-                Err(err) if is_not_found_error(&err) || is_not_modified_error(&err) => {}
-                Err(err) => {
-                    warn!(
-                        container = %target,
-                        error = %err,
-                        "Failed to stop Docker sandbox container during shutdown"
-                    );
-                    failures.push(target);
-                }
-            }
-        }
-
-        if !failures.is_empty() {
-            return Err(Status::internal(format!(
-                "failed to stop {} of {target_count} Docker sandbox containers during shutdown",
-                failures.len()
-            )));
-        }
-
-        Ok(stopped)
-    }
-
     async fn reserve_pending_sandbox(&self, sandbox: &DriverSandbox) -> Result<(), Status> {
         let mut pending = self.pending.lock().await;
         if pending
@@ -3200,15 +3137,6 @@ fn summary_container_target(summary: &ContainerSummary) -> Option<String> {
         .or_else(|| summary_container_name(summary))
 }
 
-fn container_state_needs_shutdown_stop(state: ContainerSummaryStateEnum) -> bool {
-    matches!(
-        state,
-        ContainerSummaryStateEnum::RUNNING
-            | ContainerSummaryStateEnum::RESTARTING
-            | ContainerSummaryStateEnum::PAUSED
-    )
-}
-
 /// States from which a managed container can be brought back to running by
 /// `start_container`. Skip `Restarting` (already coming up), `Removing`,
 /// `Dead` (terminal), `Paused` (needs `unpause`, not `start`), and
 
@@ -32,6 +32,12 @@ The stop call waits until Podman reports the container as stopped or exited.
 This keeps an immediate start from racing a rootless Podman stop that is still
 finishing after its API request returns.
 
+Gateway shutdown does not stop running Podman containers. On startup, the
+gateway sends an idempotent `StartSandbox` request for each sandbox whose
+persisted phase requires running compute. This is a no-op for a container that
+survived and recovers a retained container stopped by a Podman machine or
+runtime restart. Explicitly stopped sandboxes are excluded.
+
 ## Architecture
 
 The Podman driver communicates with the Podman daemon over a Unix socket and
 
@@ -197,7 +197,11 @@ The driver also writes the accepted `DriverSandbox` launch request to
 new VM driver process; that process scans the sandbox state directories,
 restarts each persisted VM launcher, and preserves any existing `overlay.ext4`
 instead of cloning a fresh overlay template. If a restart happened before the
-overlay was created, the driver creates it during the start attempt.
+overlay was created, the driver creates it during the start attempt. After
+driver initialization, the gateway also sends the shared idempotent
+`StartSandbox` request for each persisted running-intent sandbox. Already
+restored VMs are unchanged, while stopped markers continue to exclude
+explicitly stopped sandboxes from startup.
 
 Stop writes a marker in the sandbox state directory before terminating
 the launcher and releasing host GPU and network allocations. It retains