The next time you upgrade a Jetson, the recommended first step is no longer a long list of apt-get commands. It is a single line, lifted straight from NVIDIA's developer blog on JetPack 7.2: curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash. That one-liner is the front door to NemoClaw, NVIDIA's new agent runtime for Jetson, and it is the most consequential change in the JetPack 7.2 release (Jetson Linux 39.2, dated 2026-06-02). What that line actually pulls, stages, and starts talking to is the question the release notes do not fully answer. It is the question an operator should answer before running it.
NemoClaw is NVIDIA's distribution layer for running AI agents on Jetson devices, packaged as a Docker-based sandbox that sits on top of OpenShell (the cluster runtime) and k3s (a lightweight Kubernetes). The one-command install is not a single binary. It is a wrapper around a real install chain, and the JetsonHacks walkthrough and the github.com/jetsonhacks/NemoClaw-Orin repo walk through what that chain actually does on a Jetson Orin.
Here is the chain, end to end. The host prereqs land first: kernel modules for br_netfilter are loaded, bridge sysctls are set, and Docker is installed in cgroupns=host mode. On some hosts an overlay filesystem is required. Then a patched OpenShell cluster image is built, swapping nf_tables for iptables-legacy because the 5.15 Tegra kernel on Orin does not support the newer netfilter backend. The OpenShell CLI, the NemoClaw CLI, and Node.js are installed. Finally, the NemoClaw onboarding flow stages a Docker build context from the local clone and stands up a NemoClaw sandbox on k3s.
That last step is where most of the network surface appears. The installer fetches nemoclaw.sh from nvidia.com, pulls the OpenShell cluster image and the NemoClaw sandbox image, and can be pointed at Ollama or vLLM for local inference or at NVIDIA Endpoints (an OpenAI-compatible remote inference service) for cloud inference. Container images for Triton and the rest of the NVIDIA SDK stack come down from the NGC catalog, NVIDIA's container registry.
In other words, "what it sends home" is the wrong frame. The NVIDIA developer blog, the NemoClaw product page, the JetPack SDK landing page, and the release notes do not document a hidden telemetry upload from the installer to nvidia.com. The honest story is what the installer fetches and executes on the Jetson host, and which remote endpoints the resulting NemoClaw runtime is configured to call. That is still a real story, and a more useful one for an operator.
What else is in 7.2
JetPack 7.2 is not just the NemoClaw installer. The release, paired with CUDA 13.2.1, TensorRT 10.16.2, and cuDNN 9.20.0 on a 6.8 kernel and Ubuntu 24.04, also adds:
Multi-Instance GPU (MIG), a feature that partitions a single GPU into isolated instances, as a technology preview on Jetson Thor T5000. NVIDIA's release notes label it a preview; treat it as preview, not GA.
Super Mode (MAXN_SUPER) on Jetson AGX Orin 32GB, which lifts AI compute from 200 to 241 TOPS, roughly 20% above the original spec. Per NVIDIA's release notes, not an independent measurement.
Official Yocto Project recipes for Orin and Thor via OE4T, the OpenEmbedded for Tegra layer, and a unified ISO install method.
SBSA (Server Base System Architecture) alignment for Thor, which is why Thor's flashing steps differ from Orin's.
Three categories of Jetson agent skills, executable instructions derived from NVIDIA's docs and design guides: Jetson Linux customization, memory optimization, and model benchmarking. The companion skills for DeepStream (the streaming analytics SDK) and Metropolis VSS (the vision pipeline framework) are bundled for the vision side.
The trust model
The one-command install is a real capability gain. It is also a trust decision the operator is being asked to make on faith, before the first packet hits the wire.
The trust model implied by curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash is: trust the URL, trust TLS to nvidia.com, trust the script, trust the script's transitive downloads, and trust the sandbox image you pull next. Each of those is a different thing, and each can fail in a different way. The URL can be hijacked. TLS terminates at nvidia.com, but the script you pull is not pinned. The script reaches out to NGC, to OpenShell, to a configurable inference endpoint, and to whatever Node.js packages its installer adds. None of this is hidden. All of it is documented, in fragments, across the developer blog, the product page, the NVIDIA corporate blog announcement, and the GitHub repos. The point is that "one command" is shorthand for a chain an operator should inspect once before they script it across a fleet.
Aragon Research frames NemoClaw as a Red Hat-style "plumbing" wrap around OpenClaw, with OpenShell providing the runtime policy controls. That label is analyst commentary, not independent verification, but it points at the same picture: NemoClaw is a distribution and a sandbox gateway, not a single tool. Treating it as a single tool is what makes the install feel simpler than it is.
What "privacy and security controls" actually covers
NVIDIA's product page talks about privacy and security controls in NemoClaw. The observable scope, based on the public documentation, is: the sandbox runs in containers, the runtime is OpenShell, and the inference path can be local (Ollama, vLLM) or remote (NVIDIA Endpoints). That is a real control surface. It is not the same as a claim that the installer makes no outbound calls, and it is not a claim that nothing is logged. Operators who care about either should plan to capture.
A pre-install checklist
Before running the one-liner on a Jetson that is doing real work, capture:
A baseline of outbound traffic: tcpdump -w before.pcap on the Jetson's uplink, or a span port on the switch.
A list of currently installed packages and their versions: dpkg --get-selections > before.pkgs on a Debian-based system, and the equivalent on a Yocto-based image.
The current kernel module set and the bridge/netfilter state: lsmod > before.mod, iptables-save, sysctl net.bridge.bridge-nf-call-*.
A snapshot of running containers and k3s state if it is already present.
After install, the same four captures are the diff. The biggest expected change is the addition of the NemoClaw sandbox containers and the OpenShell agent processes, with outbound calls to nvidia.com (for the script and the product), NGC (for container images), and whatever inference endpoint you point it at. If the Jetson is air-gapped, expect to seed those images locally and to redirect the installer at a local mirror; the JetsonHacks walkthrough is the most concrete operator guide for what that looks like.
What to watch
Two things are worth tracking over the next few weeks. First, whether the iptables-legacy workaround on the Tegra kernel survives upstream kernel changes, or whether NemoClaw moves to a newer kernel where nf_tables works and the patch goes away. Second, whether the agent skills, housed in the jetson-device-skills and jetson-bsp-skills repos, become a real ecosystem or stay a curated NVIDIA list. The skills are the most novel part of the release: they let an agent read a board support package reference and act on it. If third parties start shipping skills, the trust model shifts from "trust NVIDIA's installer" to "trust the skill author," which is a different problem to manage.
JetPack 7.2 is a real release with real capability gains. The one-command install is the headline. The actual work is reading the chain it triggers before you let it run.