openshell sandbox create timeout reports ConfigurationPending when the pod could not be scheduled #5230

User Story

I'm a senior engineer at VicOne. We run OpenShell on an EKS cluster to sandbox the AI agents our teams operate, and the cluster is shared with other workloads, so node capacity varies during the day. When openshell sandbox create timed out I spent the first round of debugging on sandbox configuration, because the only thing the CLI printed was ConfigurationPending. The pod had simply not been scheduled. I reproduced it twice on 0.1.6. As an operator on a shared cluster, I want the timeout message to tell me that the pod could not be scheduled and why, so that I go and check capacity instead of the sandbox configuration.

Problem Statement

When the sandbox pod cannot be scheduled, the gateway's sandbox status already carries the cause (PodScheduled: False (Unschedulable) with the scheduler's "0/N nodes are available" message), but the CLI timeout message only reports the first Ready=False condition, which the gateway has replaced with ConfigurationPending while no supervisor configuration report has arrived. The user sees a configuration placeholder, not the scheduling failure. About five minutes after creation the Kubernetes driver removes the stale bootstrap, so sandbox get is only useful for a short window and most users will only ever see the CLI error.

Related: #5028 covers the same symptom family for image pull failures. The difference here is that the scheduling cause is already present in the sandbox status returned by the gateway, so a CLI-only change surfaces it; #5028 needs the gateway to relay pod events.

Impact / Why This Matters

• On any shared or autoscaled cluster, "cannot schedule" is one of the most common reasons a create fails, and today it is invisible from the CLI.
• The hint in the error points at image_preparation_timeout_seconds, which sends users in the wrong direction when the problem is capacity.
• The sandbox is rolled back a few minutes later, so the CLI message is the only durable signal.

Acceptance Criteria

• When provisioning times out and the sandbox status contains a PodScheduled condition with status False, the CLI error includes that condition's reason and message (for example Unschedulable: 0/11 nodes are available: 11 Insufficient cpu).
• When no such condition exists, the message is unchanged.
• PodScheduled=True does not affect the message.
• Covered by unit tests in the CLI crate; no gateway or driver behaviour change.

Reproduction Steps

1. Kubernetes gateway on a cluster where no node can satisfy the request (or any cluster at autoscaler max size).
2. openshell sandbox create --name repro --cpu 4 --memory 2Gi
3. While it waits, in another shell: openshell sandbox get repro
4. After 300 s the CLI exits 1 with the ConfigurationPending message below, while sandbox get shows PodScheduled: False (Unschedulable). About five minutes after creation the sandbox is removed by the driver.

Suggested UX (if applicable)

sandbox provisioning timed out after 300s. Last reported status:
Unschedulable: 0/11 nodes are available: 11 Insufficient cpu. ...

Implementation sketch (CLI only): in ready_false_condition_message (crates/openshell-cli/src/commands/common.rs), look for a PodScheduled condition with status False before falling back to the first Ready=False condition. I have this change with unit tests ready and will open the PR once the issue is accepted.

Environment

• Gateway / Helm chart: 0.1.6 (helm-chart-0.1.6), Kubernetes driver on EKS, cluster-autoscaler at max node group size
• CLI: 0.1.5; the message-building code was checked against current main and is unchanged
• Platform: Linux nodes (Amazon Linux 2023, kernel 6.12), CLI on macOS

Logs

CLI after 300 s (exit 1):

sandbox provisioning timed out after 300s. Last reported status:
ConfigurationPending: Waiting for effective configuration validation before workload activation

openshell sandbox get repro during the same window:

Phase: Provisioning
Conditions:
  - PodScheduled: False (Unschedulable) - 0/11 nodes are available: 11 Insufficient cpu. no new claims to deallocate, preemption: 0/11 nodes are available: 11 Preemption is not helpful for scheduling.
  - Bootstrapping: True (SandboxRuntimeGenerationStarting)
  - ConfigurationReady: False (ConfigurationPending) - Waiting for effective configuration validation before workload activation
  - Ready: False (ConfigurationPending) - Waiting for effective configuration validation before workload activation

Gateway log about 5 minutes after creation:

rolled back stale fail-closed sandbox-runtime bootstrap