bug: sandbox --label values are stored as metadata but never applied to the pod/container

[Gal-Zaidman]

Agent Diagnostic

Pointed an agent at the repo and traced the create-sandbox label flow across the gateway and compute drivers (codebase exploration + openshell-cli knowledge).

• openshell sandbox create --label k=v sends the label in CreateSandboxRequest.labels (crates/openshell-cli/src/main.rs → run.rs::sandbox_create).
• In the gateway, handle_create_sandbox_inner (crates/openshell-server/src/grpc/sandbox.rs) stores those labels only in ObjectMeta.labels (sandbox metadata used for CLI filtering / --selector). They were never copied into SandboxTemplate.labels.
• SandboxTemplate.labels is the backend-neutral field documented as "Labels applied to compute-platform resources", mapped to DriverSandboxTemplate.labels in crates/openshell-server/src/compute/mod.rs (driver_sandbox_template_from_public).
• Drivers consume template.labels: the Kubernetes driver applies them to pod metadata (crates/openshell-driver-kubernetes/src/driver.rs), the Docker driver to container labels (crates/openshell-driver-docker/src/lib.rs). The VM driver ignores them.
• Root cause: the CLI never populates template.labels, and the gateway never bridges request.labels → template.labels. So there was no path for a user-supplied --label to reach the pod/container; it only ever became sandbox metadata.

Description

Actual behavior: openshell sandbox create --label env=dev records env=dev as sandbox metadata (visible via openshell sandbox list --selector env=dev), but the label is not applied to the underlying Kubernetes pod (or Docker container). kubectl get pods -l env=dev returns nothing.

Expected behavior: User-supplied labels are applied to the underlying compute resource (pod / container) in addition to being stored as sandbox metadata, so operators can select the workload with native platform tooling.

Reproduction Steps

1. Register/select a Kubernetes-backed gateway.
2. openshell sandbox create --label env=dev -- claude
3. kubectl get pods -l env=dev -n <sandbox-namespace>
4. Observe: no pod matches the label, even though openshell sandbox list --selector env=dev shows the sandbox.

Environment

• OS: any (code-level bug, platform-independent)
• Compute driver: Kubernetes (Docker affected the same way; VM driver has no label support)
• OpenShell: main branch

Logs

No error is emitted — the labels are silently confined to sandbox metadata.

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., openshell-cli) and traced the create-sandbox flow across the gateway and compute drivers
• My agent could not resolve this without a code change — the diagnostic above explains the root cause and fix location

[TaylorMutch]

Can you expand on the use case? Sandbox labels are currently meant for organizing and selecting sandboxes by label - irrespective of compute backend.

[Gal-Zaidman]

Sure, when you are deploying against a k8s gateway all the sandboxs are actually k8s pods.
If you want to filter all the sandboxs of a specific type you need labels, if you want a custom controller to act upon them you need a label.

In my use case for example, I create multiple benchmark jobs in parallel all running several agents.
In the monitoring dashboard the only way I can filter agents from a specific jobs is by applying a label to the with the job name.

Generally speaking, k8s labels is a core mechanic which is used everywhere

[derekwaynecarr]

@Gal-Zaidman I want to think about this a bit more. k8s-labels can be used to potentially enable a pod to not be covered by a particular network policy or covered by an unintended network policy instead, so I want to reason a bit through the risk of propagating a bit more.

https://kubernetes.io/docs/concepts/services-networking/network-policies/

[Gal-Zaidman]

If we want to be productive we can add the openshell key prefix which is reserved only for openshell usage.
What do you think?