What happened
NVIDIA’s GitHub release notes say OpenShell v0.1.7 was published on November 3, 2026. The release includes a quick-install command that pins the version with OPENSHELL_VERSION=v0.1.7. One notable addition lets Kubernetes sandboxes update their image, command, environment, and metadata without being recreated or losing persistent storage. An operator must activate the feature, and the sandbox must be stopped before it can be updated. The notes also clarify that stopping a completed, failed, or timed-out sandbox moves it to Stopped while retaining its exit code or timeout diagnosis.
The release adds a path for sandboxed agents to send OpenTelemetry traces to a collector without an egress rule. Operators enable it through [openshell.gateway.otlp.agent]; the supervisor tags each span with the sandbox ID before forwarding it. OTLP export can now use HTTP with http/protobuf, while gRPC remains the default. Collectors requiring authentication or routing headers can use headers or headers_file. Private certificate authorities and mutual TLS are also supported through ca_file and, optionally, cert_file and key_file. The notes say the agent trace relay supports these collector headers and HTTPS, and mention MLflow ingestion using x-mlflow-experiment-id.
There are additional network and service changes. The new [openshell.supervisor.network].additional_ca_bundle setting lets sandbox egress trust a PEM bundle alongside the default roots across first-party compute drivers. An opt-in supervisor TLS listener lets declared HTTP and WebSocket services receive application traffic directly rather than through the gateway; it is disabled by default. For multiple gateways sharing a Kubernetes cluster, ingress, and wildcard certificate, operators can set service_hostname_format = "hashed" to give exposed services unique hostnames. The existing readable hostname format remains the default.
For containerized CLI use, browser login now supports a fixed callback port with OPENSHELL_CALLBACK_PORT and a changed bind address with OPENSHELL_CALLBACK_BIND_ADDRESS; defaults are unchanged. SDK behavior also changes: Rust, Go, Python, and TypeScript send exec calls directly to the gateway replica that owns the sandbox when replica routing is enabled. Go also does this for port-forward and SSH tunnel calls, while TypeScript does so for port-forward. Separately, the release makes native OCSF 1.8.0 records the only emitted format. Older schema-version settings and environment variables are deprecated and ignored, with a warning when set.
What the archive adds
New Runtime covered OpenShell v0.1.6 on October 28, 2026, when gateway authentication became a startup requirement, and the CLI callback-port change on October 31, 2026. This release is a new event in that sequence: it packages the callback configuration into a tagged version and adds separate sandbox, telemetry, and schema changes. OpenShell v0.1.6 note · Callback-port note
Trend signal
This release does not yet fit a pattern New Runtime tracks. Its changes span sandbox lifecycle, observability, networking, SDK routing, and event-schema compatibility; together they are not enough to establish one durable architectural shift.
Why now
The release notes identify a temporary v0.1.6 protobuf compatibility exception as removed from release qualification. They do not explain a broader timing rationale for the release. The practical timing issue for operators is the transition to OCSF 1.8.0-only records, which can affect downstream consumers as soon as they upgrade.
Why it matters
These additions make OpenShell easier to operate alongside existing infrastructure. Updating a stopped Kubernetes sandbox without discarding persistent storage can reduce the friction of maintaining long-lived environments. Direct agent trace export, configurable OTLP transport, and collector authentication give teams more options to observe agent behavior within their own telemetry stack. That matters when teams need to debug or evaluate agent runs rather than treat them as opaque requests.
The release also puts a clear compatibility obligation beside those conveniences: deployments that expected OCSF 1.1 or 1.3 records will instead receive 1.8.0 records. This is not only a version-label change; downstream parsers and dashboards may depend on a particular schema. Teams should treat the upgrade as both a feature release and a telemetry migration, checking event consumers and configuration before rollout.
Limits and uncertainty
The release notes describe the new controls but do not report performance, reliability, or adoption measurements. They do not quantify the cost or operational impact of trace forwarding, nor do they provide comparative evidence about updating sandboxes in place versus recreating them. The OCSF transition is documented, but the release notes do not establish whether every downstream consumer in a deployment will accept 1.8.0 records. No independent compatibility or security assessment is described. Operators should validate these behaviors in their own environment, particularly where telemetry pipelines or persistent sandbox state are critical.
Skill to build now
Before upgrading, inventory the systems that consume OpenShell OCSF events and test them against 1.8.0 records. In a staging environment, enable agent OTLP export with the same collector authentication and certificate setup used in production. Then stop a representative Kubernetes sandbox, update its image or environment, and verify that its persistent storage and expected metadata remain intact.
Reader takeaway
OpenShell v0.1.7 is more than a callback-port packaging release: it adds useful sandbox lifecycle and agent-observability controls. The clearest migration task is to account for OCSF 1.8.0-only output before upgrading, then test the new capabilities against real collector and sandbox configurations.