Platform Support and Launch Claims
This page is the canonical reference for what NemoClaw supports today. Any documentation, demo, blog post, sales conversation, or support reply that describes NemoClaw capability should agree with the entries below.
The tables on this page are generated from ci/platform-matrix.json.
Update the JSON; the tables and the partial views on other pages stay in sync with scripts/generate-platform-docs.py.
Status vocabulary
Project status
For version highlights, see Release Notes.
- Stage: alpha
- Label: Early preview
- Since: 2026-03-16
- Notes: Maintainers review issues, discussions, and PRs on a best-effort basis without guaranteed response timelines.
Owners
- Engineering owner: @NVIDIA/nemoclaw-maintainer (reviews through CODEOWNERS and signs off on launch-facing claim changes before they reach demos or sales material).
The engineering owner is the GitHub team auto-assigned to review changes to ci/platform-matrix.json through CODEOWNERS, and the same team signs off on launch-facing claim changes before they reach demos, blog posts, or sales material.
Review process
- A change to a status or note opens a PR that touches
ci/platform-matrix.json. - CODEOWNERS auto-requests review from the engineering owner team.
- If the change is launch-facing (any status promotion, demotion, or new public claim), the engineering owner team explicitly acknowledges the launch impact in the PR review before approval.
- The
platform-matrix-syncpre-commit hook runspython3 scripts/generate-platform-docs.pyand stages the regenerated tables on every commit that touches the matrix, the generator, or any rendered page, so commits cannot land with the tables out of sync. Runpython3 scripts/generate-platform-docs.py --checklocally or in CI to verify the rendered tables match the JSON without regenerating. - After merge, the next NemoClaw release picks up the updated matrix automatically through the docs build.
Agents
NemoClaw supports the agent runtimes listed below. Pick the matching onboarding entry point for each agent.
Platforms
The table below lists every platform tracked by NemoClaw, including deferred entries that are on the roadmap but not yet validated.
The CI column reports whether the platform has a dedicated GitHub Actions job.
A “Tested with limitations” row that is not in CI carries a stronger caveat than one that is.
For the onboarding-time supported set without deferred rows, see Prerequisites.
Inference providers
NemoClaw routes inference through the OpenShell gateway. Each row below is a provider the onboarding wizard can configure end-to-end.
Messaging integrations
NemoClaw configures messaging channels during onboarding. The OpenShell gateway runs each channel as a supervised process; NemoClaw supplies onboarding, credential delivery, and policy presets for the sandbox egress rules.
Capabilities
Each row below is a launch-facing capability claim that NemoClaw makes in docs, blog posts, or demos. Use the status to decide whether the claim is safe to repeat verbatim or needs a caveat.
Deployment paths
How NemoClaw can be brought up on a given host. Pick the row that matches the target environment.
Out of scope and not supported
The items below come up in conversations but are explicitly out of scope. They are listed here so launch material, sales conversations, and support triage have a clear “we do not claim to do this” reference.
Known caveats and active blockers
- Sandbox bounding-set capability drop on hosts without
CAP_SETPCAPis partially fixed. The agent process tree drops dangerous caps withNEMOCLAW_REQUIRE_CAP_DROP=1(see #4707). Thenemoclaw <name> connectshell still inherits the container’s create-time bounding set on Colossus, Docker Desktop, and WSL hosts whereCAP_SETPCAPis absent. The remaining fix is upstream in NVIDIA/OpenShell#1452. See tracking #3280.
Using this matrix
- Docs and READMEs that reference any row above should link to this page instead of restating status. Partial tables, such as the prerequisites page, generate from the same JSON and stay in sync with
scripts/generate-platform-docs.py. - Demos and launch material should cite the status verbatim. A “Tested with limitations” row is not a “Tested” row.
- Customer support can use the matrix to triage incoming reports. A failure on a Tested row is a bug. A failure on a Deferred row is an unsupported configuration request. A failure on an Unsupported row is a feature request that needs separate triage.
- Roadmap changes land in the JSON first, then propagate to this page on the next generator run.
Updating the matrix
- Edit
ci/platform-matrix.json. - Run
python3 scripts/generate-platform-docs.pyto regenerate this page and the partial tables on prerequisites and inference-options. - Open a PR. The engineering owner team is auto-assigned through CODEOWNERS and explicitly acknowledges launch impact in the PR review for any launch-facing claim change.
- The
platform-matrix-syncpre-commit hook regenerates and stages the rendered tables before the commit lands; runpython3 scripts/generate-platform-docs.py --checkto verify drift without regenerating.