Repository navigation
bug: sandbox --label values are stored as metadata but never applied to the pod/container #2102
Closed as not planned
Description
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=vsends the label inCreateSandboxRequest.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 inObjectMeta.labels(sandbox metadata used for CLI filtering /--selector). They were never copied intoSandboxTemplate.labels. SandboxTemplate.labelsis the backend-neutral field documented as "Labels applied to compute-platform resources", mapped toDriverSandboxTemplate.labelsincrates/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 bridgesrequest.labels→template.labels. So there was no path for a user-supplied--labelto 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
- Register/select a Kubernetes-backed gateway.
openshell sandbox create --label env=dev -- claudekubectl get pods -l env=dev -n <sandbox-namespace>- Observe: no pod matches the label, even though
openshell sandbox list --selector env=devshows 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:
mainbranch
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
Activity
TaylorMutch commentedon Jul 1, 2026
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 commentedon Jul 1, 2026
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 commentedon Jul 1, 2026
@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 commentedon Jul 1, 2026
If we want to be productive we can add the openshell key prefix which is reserved only for openshell usage.
What do you think?
TaylorMutch commentedon Jul 10, 2026
I think propagating labels down to the sandbox in this case should be a driver specific choice. By default we shouldn't propagate labels down per @derekwaynecarr's reasoning, since that feels very much like the OpenShell deployer's choice here.
What I would propose is an "allowed_labels" list for labels that can be propagated down to the Agent Sandbox and therefore the Pod spec. I can see the utility to enable this workflow when paired with Kube, but we shouldn't allow arbitrary labels to be propagated down.
TaylorMutch commentedon Jul 10, 2026
I think we should reframe this as a feature request for the kube driver, and then we can take a contribution in that direction. What do you think @Gal-Zaidman ?
github-actions commentedon Jul 26, 2026
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.