Pi Support and Security

Pi is a NemoClaw agent runtime. Docker is the initial compute runtime. Pi-specific code does not own Docker lifecycle, backup or snapshot, recovery, or cleanup behaviour.

Initial Support Matrix

Podman, macOS, Windows, WSL, messaging, dashboards, device pairing, managed MCP, host mounts, and automatic third-party package installation are outside the initial matrix.

Package and Image Identity

NemoClaw pins one Pi package version and npm integrity value. Installation disables package lifecycle scripts. Runtime self-update, package auto-update, mutable image tags, and host-side stock Dockerfile builds are unsupported. The reviewed Dockerfile is used only by trusted CI to create the managed image.

Candidate image receipts bind each accepted platform to:

• the canonical ghcr.io/nvidia/nemoclaw/pi-sandbox repository;
• one immutable image digest;
• the NVIDIA/NemoClaw source repository and source revision;
• one release and publication cohort;
• managed-image, startup-profile, and capability contract version 1.

Final activation must publish both platform digests in the same complete cohort. A partial platform set cannot advertise Pi support. When protected Pi image inputs change, repository validation requires refreshed receipts for both platforms. Each receipt must match the protected inputs and an image digest in the candidate authority.

Managed Inference and Credentials

Pi reads a generated /sandbox/.pi/agent/models.json file. The file contains the model, managed route, API family, and a non-secret route placeholder. It does not contain the upstream provider credential.

The upstream credential remains in OpenShell provider state. It survives rebuild and sandbox destruction until an operator runs nemoclaw credentials reset <provider> --yes after all dependent sandboxes are gone. Most providers give Pi the managed inference.local route. NVIDIA Endpoints instead uses the least-privilege OpenShell provider attached to the sandbox for integrate.api.nvidia.com. Direct unmanaged provider access is denied. NemoClaw rejects an unsupported API family, empty model, credential-bearing base URL, or malformed model tuning before Pi starts.

When Pi uses the recorded openrouter-api provider, https://inference.local/v1/models returns HTTP 404 by design because NemoClaw’s OpenRouter adapter serves Chat Completions without a model catalog. NemoClaw reports the route ready only after a bounded inference request successfully serves the selected model. If that request fails, the expected catalog response does not make the route ready.

The initial qualification requires streaming, a structured read tool call, a successful tool result, and an independently checked final response with nvidia/nemotron-3-super-120b-a12b.

Model Metadata and Route Changes

Pi accepts NEMOCLAW_CONTEXT_WINDOW, NEMOCLAW_MAX_TOKENS, and NEMOCLAW_REASONING through the managed startup profile. The context window must be a positive integer no larger than 4194304, the output limit must be from 1 to 1000000000, and reasoning accepts true or false. Unset fields remain absent from models.json, so Pi uses the selected model’s defaults.

A rebuild replays the recorded values. Pi does not support NEMOCLAW_REASONING_EFFORT or runtime mutation through nemoclaw inference set. Changing the provider, model, or model metadata requires nemoclaw onboard --agent pi --name <sandbox-name> --fresh --recreate-sandbox.

Network and Filesystem Policy

The baseline network policy permits only the managed inference endpoint and the required Chat Completions routes. Network capability is limited to the root-owned Pi and Node runtime binaries.

Direct access to provider endpoints, GitHub, npm, host control, and container-runtime sockets is denied. Operators must select an explicit maintained policy before additional services become reachable.

Pi runs as the unprivileged sandbox user. Landlock strict mode and the OpenShell filesystem policy protect the image and host boundary. Writable paths are limited to /sandbox, /sandbox/.pi, /tmp, and /dev/null.

Startup and Corporate CA Controls

The managed image starts as root only to establish the protected workspace, merge an optional corporate CA, enforce resource limits, and switch to the sandbox user with setpriv. Pi and its interactive or headless commands never run as root. Startup and independent shell hooks fail closed when the privilege drop or exact limits cannot be verified.

Set NEMOCLAW_CORPORATE_CA_BUNDLE before onboarding when an enterprise proxy re-signs TLS. The managed startup profile carries the validated public CA without changing the exact Pi image digest. On a successful merge, the entrypoint appends it to the OpenShell trust bundle, protects the merged file as root-owned mode 0444, and points curl, Python, Git, and Node.js at that bundle. An ordinary runtime merge failure warns and keeps OpenShell-only trust, so external TLS through the corporate proxy may fail. A symlinked source or invalid root-to-sandbox handoff aborts startup because it breaks the trust boundary. Invalid explicit CA input stops onboarding rather than weakening trust.

Tool and Project Trust

The supported baseline includes Pi’s built-in read, bash, edit, and write tools and reviewed image resources.

Interactive users may trust project-local skills, extensions, prompts, and packages explicitly. Those resources are user-owned and outside release qualification. Pi loads AGENTS.md and CLAUDE.md context files before the project-trust decision; --no-context-files disables them. Headless --no-approve ignores project-local executable resources but does not disable context files. OpenShell policy continues to govern filesystem, process, network, and credential access in both modes.

A project-trust decision is agent-native state. Whole-home rebuild transfer preserves the native files that record it; NemoClaw does not reinterpret or elevate that decision.

Persistent and Reconstructed State

The complete Pi native home/workspace is persistent user state. Rebuild transfer does not filter settings.json, sessions, prompts, themes, tools, executable resources, model configuration, caches, project trust, or unknown future files by path. OpenShell-owned credentials remain outside the transferred tree.

Pi starts with umask 077, so generated configuration and session files are private to the sandbox user. Runtime setup sets PI_OFFLINE=1 and PI_TELEMETRY=0.

Qualification Evidence

The full lifecycle release gate runs one repository-owned target on a native Linux AMD64 runner. The target records:

• CLI, workflow, receipt, package, image, platform, and OpenShell identities;
• Docker as the compute runtime;
• provider, model, API, route, and policy digest;
• buildless onboarding through nemoclaw onboard --agent pi;
• one interactive session and versioned headless structured-tool tasks;
• session preservation across rebuild;
• recovery after an OpenShell gateway restart;
• denial of undeclared network and container-runtime access;
• absence of the upstream credential from sandbox environment, files, registry, logs, and uploaded evidence;
• cleanup after destroy.

Linux ARM64 remains release-gated by its native managed-image build, startup, publication, and receipt evidence. The checked-in AMD64 and ARM64 image receipts must identify one source revision, release, and publication cohort. These receipts prove exact image publication; they are not live agent-runtime results.

The versioned qualification task uses the structured event oracle and the AMD64 receipt. Each trusted lifecycle run uploads a bounded pi-agent-qualification.json oracle result and the standard evidence-manifest.json. Final activation must retain durable links to the passing AMD64 lifecycle result and both platform managed-image results, and must not require manual sandbox repair.