fix(onboard): permit Jetson GPU policy paths

[sandl99]

Summary

Two boundaries blocked Jetson CUDA. OpenShell's creation-time filesystem policy hid the injected Jetson libraries and Tegra device nodes. After that policy was corrected, OpenShell rebuilt the sandbox account's supplementary groups with initgroups(), discarding the device GIDs supplied by Docker.

OpenClaw direct-GPU onboarding now grants /opt/nvidia read-only and only detected, eligible Tegra character devices read-write. Before the compatibility replacement starts the fixed OpenShell supervisor, a bounded image-owned wrapper records those detected device GIDs in the sandbox account's group database so the required memberships survive startup.

The branch remains draft pending final end-to-end acceptance on Jetson hardware.

Related Issue

Fixes #7610

Changes

• Require /dev/nvmap to be an existing, non-symlink character device before adding Jetson filesystem entries.
• Add /opt/nvidia read-only and each existing, non-symlink device from the curated Tegra GPU path list read-write for OpenClaw direct-GPU onboarding only.
• Add a bounded, root-owned OpenClaw image wrapper that validates at most 16 detected GIDs, updates only the replacement container's sandbox account, verifies membership, and hands off only to /opt/openshell/bin/openshell-sandbox.
• Verify the wrapper is present before stopping the original container.
• Keep generic GPU, CPU-only, Hermes, and Deep Agents outside this path.
• Add positive and negative coverage for policy selection, clone composition, compatibility recreation, image metadata, input bounds, missing-wrapper handling, and unaffected paths.
• Resolve ShellCheck's chained-control-flow findings with explicit fail-closed conditionals.
• Remove the redundant diagnostic-policy conditional and always restore the baseline policy in finally.
• Stage the new helper in the image-permission integration fixture, fixing CI shard 5.
• Document the OpenClaw-only Jetson policy and group-preservation behavior.

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Quality Gates

• Tests added or updated for changed behavior
• Existing tests cover changed behavior — justification:
• Tests not applicable — justification:
• Docs updated for user-facing behavior changes
• Docs not applicable — justification:
• Sensitive paths changed (security, policy, credentials, preflight, onboarding, inference, runner, sandbox, or messaging)
• Sensitive-path review completed or maintainer-approved waiver recorded — reviewer/approval link/justification: Codex Desktop independently reviewed the current branch revision 7b70ce2cf7ec4635e2b5616a653fc10ae2eae2ba across authentication and authorization, input validation, command execution, filesystem and symlink handling, secrets, network exposure, cryptography, dependencies, resource safety, and privilege boundaries. No blocking finding remains. The wrapper now validates the complete GID list before any account mutation, keeps the fixed supervisor handoff, verifies resulting membership, and fails closed. The direct container fixture uses a digest-pinned base, disables networking, makes the root filesystem read-only, drops all capabilities, enables no-new-privileges, and bounds writable temporary storage. No credentials, dependencies, authentication, or cryptography change.
• Non-success, skipped, or missing CI check accepted by maintainer — check name, approval link, and follow-up issue:

Documentation Writer Review

• Documentation writer subagent reviewed the completed changes
• Result: docs-updated
• Evidence: Independent review at branch revision 7b70ce2cf7ec4635e2b5616a653fc10ae2eae2ba updated docs/reference/troubleshooting.mdx to state that complete count, format, range, and duplicate validation finishes before account changes. npm run docs passes with 0 errors and the 2 existing warnings; all 67 guarded documentation routes pass.
• Agent: Codex Desktop

DGX Station Hardware Evidence

• Tested on DGX Station
• Tested revision:
• Station profile/scenario:
• Result:
• Supporting evidence:

Verification

• PR description includes a Signed-off-by: line; GitHub verification is checked after each push
• npm run check:diff passed against current main
• Targeted behavior tests pass — 11/11 direct bootstrap integration tests and 15/15 adjacent Jetson CLI tests; prior branch validation remains 112/112 focused CLI tests and 19/19 focused integration tests
• CLI build and typecheck pass
• Vitest project membership validation passes
• Documentation build and generated-agent-variant checks pass
• ShellCheck, shfmt, Biome, repository checks, DCO-format hooks, and secret scan pass
• Applicable hardware gate passed — final Jetson end-to-end acceptance remains pending
• Quality Gates section completed with required justifications or waivers
• No secrets, API keys, or credentials committed
• Doc pages follow the style guide

Jetson Validation

The read-only diagnostic isolated both boundaries: the policy hid /opt/nvidia, and after that was exposed the replacement still failed with NvRmMemInitNvmap ... Permission denied and cuInit(0)=100. The failed replacement inspect showed Docker had supplied GIDs 44 and 993, while the sandbox account retained only GID 998.

At validated revision 7fad34abc, a disposable A/B proof ran against the Jetson sandbox image without modifying the OpenShell sandbox:

• Baseline: Docker supplied GIDs 44 and 993, then unchanged initgroups() rebuilt membership from the unchanged group database. /dev/nvmap read-write open failed and cuInit(0)=100.
• Proposed mechanism: the script recorded GIDs 44 and 993 in the sandbox account's group database before the same initgroups() call. The account then held GIDs 44, 993, and 998; /dev/nvmap read-write open succeeded; and cuInit(0)=0.

This proves the root cause and the mechanism implemented by the compatibility-path wrapper. Final nemoclaw onboard --resume acceptance is still required on Jetson for the current branch revision: the non-root sandbox user must read and write /dev/nvmap, retain the required supplementary groups, and report cuInit(0)=0. No trusted Jetson runner has been authoritatively confirmed online, so the restricted target was not dispatched.

---

Signed-off-by: San Dang sdang@nvidia.com

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 02e4a999-141f-46ae-8cbf-05377759a94b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

The PR adds persistent Jetson /dev/nvmap permissions, propagates Jetson device groups into OpenClaw sandboxes, grants read-only Jetson GPU library access, and validates non-root CUDA access.

Changes

Jetson GPU sandbox support

Layer / File(s)	Summary
Host nvmap setup and validation scripts/setup-jetson.sh, test/setup-jetson.test.ts, docs/reference/troubleshooting.mdx	JetPack 6 setup validates /dev/nvmap, applies group read-write access, installs a persistent 0660 udev rule, and handles missing or invalid devices. Tests and troubleshooting guidance cover verification and persistence.
CUDA access detection and recreation src/lib/onboard/docker-gpu-jetson-groups.ts, src/lib/onboard/docker-gpu-jetson-groups.test.ts, src/lib/onboard/docker-gpu-patch-recreate.ts, src/lib/onboard/docker-gpu-patch-types.ts	Jetson detection now requires group read-write access. Recreation options record whether Jetson device-group membership must be preserved.
Container device-group bootstrap scripts/jetson-device-group-bootstrap.sh, src/lib/onboard/docker-gpu-patch-clone.ts, src/lib/onboard/docker-gpu-patch-jetson.test.ts, Dockerfile, test/openclaw-final-image-layout.test.ts	The runtime image includes a root-only bootstrap script. Docker cloning validates group IDs, injects them into the container, preserves the supervisor command, and verifies sandbox-user membership before startup.
OpenClaw Jetson policy and flow wiring src/lib/onboard.ts, src/lib/onboard/sandbox-*, src/lib/onboard/initial-policy.*	OpenClaw Jetson detection propagates agent and platform data through sandbox creation. Jetson policies grant read-only access to /opt/nvidia/l4t-gpu-libs and enable device-group preservation.
End-to-end access validation test/e2e/live/jetson-nvmap-gpu.test.ts	Live tests record nvmap permissions and verify that the sandbox user can read and write /dev/nvmap.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Setup as scripts/setup-jetson.sh
  participant Onboard as Sandbox creation flow
  participant Docker as docker-gpu-patch-clone.ts
  participant Bootstrap as jetson-device-group-bootstrap.sh
  participant Sandbox as OpenClaw sandbox
  Setup->>Setup: configure persistent /dev/nvmap access
  Onboard->>Docker: pass OpenClaw Jetson settings
  Docker->>Bootstrap: pass device GIDs and supervisor command
  Bootstrap->>Sandbox: add and verify device-group membership
  Bootstrap->>Sandbox: start preserved supervisor
  Sandbox->>Sandbox: validate readable and writable /dev/nvmap

Loading

Possibly related PRs

• NVIDIA/NemoClaw#5613: Both changes update Jetson /dev/nvmap E2E validation.
• NVIDIA/NemoClaw#8040: Both changes modify the GPU sandbox creation and recreation flow.
• NVIDIA/NemoClaw#8128: Both changes modify Docker GPU clone handling.

Suggested labels: bug-fix, area: security, area: e2e

Suggested reviewers: cjagwani, apurvvkumaria, cv

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 15.38% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes address issue #7610 by configuring nvmap access, propagating Jetson groups, adding required library policy access, and validating non-root CUDA.
Out of Scope Changes check	✅ Passed	All code and test changes support the linked issue and PR objectives for non-root Jetson GPU access.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is concise and related to the Jetson GPU policy changes, but it does not cover the broader device permission and group-membership fixes.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/jetson-nvmap-nonroot

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-8099.docs.buildwithfern.com/nemoclaw

[coderabbitai]

🧹 Nitpick comments (1)

test/setup-jetson.test.ts (1)

368-415: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Cover failed post-mutation permission validation.

The successful test supplies rw for the second stat call.
A removal or inversion of the validation at configure_nvmap_group_access can still pass this suite.
Add a case where the device remains a character device but its group permissions remain read-only after chmod.
Assert the script fails with the group read-write verification error.

As per path instructions, “Prefer observable outcomes through the public boundary.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/setup-jetson.test.ts` around lines 368 - 415, Add a test in the
“setup-jetson JetPack 6 nvmap access” suite where the post-chmod stat result
remains a character device with read-only group permissions, while preserving
the initial valid character-device result. Assert setup exits with status 1 and
reports the group read-write verification error, and verify the failure is
observable through the existing spawnSetupJetson boundary.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@test/setup-jetson.test.ts`:
- Around line 368-415: Add a test in the “setup-jetson JetPack 6 nvmap access”
suite where the post-chmod stat result remains a character device with read-only
group permissions, while preserving the initial valid character-device result.
Assert setup exits with status 1 and reports the group read-write verification
error, and verify the failure is observable through the existing
spawnSetupJetson boundary.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 0e8dcf48-d76f-47dc-952a-b950c09fed29

📥 Commits

Reviewing files that changed from the base of the PR and between a931be4 and efb5fa7.

📒 Files selected for processing (9)

• docs/reference/troubleshooting.mdx
• scripts/setup-jetson.sh
• src/lib/onboard/docker-gpu-jetson-groups.test.ts
• src/lib/onboard/docker-gpu-jetson-groups.ts
• src/lib/onboard/docker-gpu-patch-recreate.ts
• src/lib/onboard/sandbox-gpu-direct-proof.test.ts
• src/lib/onboard/sandbox-gpu-preflight.ts
• test/e2e/live/jetson-nvmap-gpu.test.ts
• test/setup-jetson.test.ts

[github-code-quality]

Code Coverage Overview

Languages: TypeScript

TypeScript / code-coverage/plugin

The overall coverage in commit 8fde81f in the fix/jetson-nvmap-non... branch remains at 96%, unchanged from commit e99f42c in the main branch.

TypeScript / code-coverage/cli

The overall coverage in commit 8fde81f in the fix/jetson-nvmap-non... branch remains at 81%, unchanged from commit e3a824d in the main branch.

Show a code coverage summary of the most impacted files.

File	main e3a824d	fix/jetson-nvmap-non... 8fde81f	+/-
src/lib/onboard...oute-handoff.ts	95%	92%	-3%
src/lib/onboard...ind-contract.ts	98%	96%	-2%
src/lib/onboard...er-gpu-patch.ts	77%	76%	-1%
src/lib/messagi...flow-planner.ts	91%	91%	0%
src/lib/onboard...ndbox-create.ts	85%	86%	+1%
src/lib/onboard...-patch-clone.ts	84%	86%	+2%
src/lib/platform.ts	84%	89%	+5%
src/lib/onboard...flight-ports.ts	33%	67%	+34%
src/lib/onboard...m-standalone.ts	0%	70%	+70%
src/lib/onboard...openrm-proof.ts	0%	84%	+84%

---

_{Updated August 07, 2026 05:48 UTC}

[github-actions]

PR Review Advisor — Blocking findings reported

Advisor assessment: Blockers require maintainer review
Next action: Review the blockers below.
Findings: 1 blocker · 1 warning · 0 suggestions

Model lanes

• GPT-5.6 Terra (primary): Completed · high confidence · 1 blocker · 1 warning · 0 suggestions
• Nemotron 3 Ultra (second opinion): Completed · medium confidence · 2 blockers · 0 warnings · 0 suggestions
• Model comparison: normalized findings differ; normalized terminology decisions differ; normalized E2E selections differ; Nemotron reported 1 more blocker, 1 fewer warning, the same number of suggestions.

2 terminology differences from the second opinion

Advisory only. These are normalized differences from the primary terminology receipt.

• device-group bootstrap at scripts/jetson-device-group-bootstrap.sh:11: selected only by the second-opinion lane as define.
• OpenRM at ci/env-var-doc-allowlist.json:3: selected only by the second-opinion lane as define.

1 additional E2E selection from the second opinion

Advisory only. The primary lane did not select these E2E jobs or targets.

• hermes-gpu-startup: The completed second-opinion lane identified E2E coverage that the primary lane omitted.

Second-opinion terminology and E2E selections are advisory. Live E2E does not run automatically for pull requests.

3 semantic terminology decisions

Terminology decisions are advisory. They affect the assessment only when a separate finding identifies concrete semantic impact.

• established — compatibility recreation at docs/reference/troubleshooting.mdx:2774: Keep "compatibility recreation" when the legacy GPU container replacement must be distinguished from native injection.
• justified — Jetson device-group bootstrap at scripts/jetson-device-group-bootstrap.sh:11: Keep the full modifier where the Jetson-specific pre-supervisor membership operation is meant.
• define — OpenRM policy proof at scripts/prove-jetson-openrm-policy-boundary.sh:13: Define OpenRM and state that this is a temporary filesystem-policy A/B diagnostic at its first user-visible use.

E2E guidance

Advisory only. A maintainer can dispatch the default E2E suite against this exact revision.

Recommended E2E: cloud-onboard, full-e2e, managed-image-multiarch-startup, onboard-repair, onboard-resume, openshell-gateway-upgrade, ubuntu-repo-cloud-langchain-deepagents-code, ubuntu-repo-docker-post-reboot-recovery

1 optional E2E recommendation

• gpu-e2e

Blockers

PRA-2 Blocker — Contain the replacement when policy restoration fails

• Location: src/lib/onboard/docker-gpu-sandbox-create.ts:358
• Category: security
• Problem: A failed diagnostic baseline-policy restoration prevents the normal rollback path from running. The replacement container can remain live with the last candidate policy, which may add /sys visibility or GPU device grants, while the original baseline policy is unconfirmed.
• Impact: A failed diagnostic restoration can leave a live replacement with broader filesystem access than the baseline policy, violating the intended least-privilege sandbox boundary.
• Fix: On JetsonOpenRmPolicyRestorationError, run a fail-closed containment and rollback path that stops or removes the replacement, restores the pre-patch container, and confirms baseline policy before returning the error.
• Verification: Read the restoration-failure branch and confirm it invokes the same owned-container rollback/containment mechanism used for failed GPU proofs before it propagates the error.
• Test coverage: Extend the restoration-failure lifecycle test to verify the replacement is contained, the backup is restored, and no live sandbox retains candidate /sys or added-device policy entries.
• Evidence: src/lib/onboard/docker-gpu-sandbox-create.ts:358-365 rethrows policyRestorationFailure before rollbackAfterFailure. src/lib/onboard/docker-gpu-sandbox-create.ts:564-580 records JetsonOpenRmPolicyRestorationError as policyRestorationFailure after candidate-policy execution. src/lib/onboard/diagnostics/jetson-openrm-proof.ts:235-274 applies candidate policies that can add /sys and injected GPU device paths, then throws when baseline restoration fails. src/lib/onboard/docker-gpu-sandbox-create-lifecycle.test.ts:406-464 expects baseline restoration failure and asserts finalizeBackup is not called.

1 warning · 0 suggestions

Warnings

Warnings do not block.

PRA-1 Warning — Run the policy matrix from the standalone proof command

• Location: scripts/prove-jetson-openrm-policy-boundary.sh:13
• Category: correctness
• Problem: The standalone command states that it runs the Jetson OpenRM policy proof, but it does not enable the policy-matrix diagnostic. A reproduced cuInit(0)=801 result can therefore return after rollback without applying candidate policies or emitting the advertised matrix.
• Impact: Maintainers can collect a successful standalone boundary reproduction that lacks the policy evidence needed to distinguish missing device paths from sysfs access.
• Recommendation: Enable the diagnostic matrix explicitly in the standalone proof path, without widening the normal onboarding path.
• Verification: Inspect a standalone cuInit(0)=801 run and confirm that it applies candidate policies, prints matrix results, and restores the baseline policy before rollback.
• Test coverage: Extend the standalone proof test to reproduce cuInit(0)=801 and assert candidate policy application, matrix output, and baseline restoration through the standalone entry point.
• Evidence: scripts/prove-jetson-openrm-policy-boundary.sh:13-34 invokes runStandaloneJetsonOpenRmPolicyProof without setting NEMOCLAW_DIAGNOSE_JETSON_OPENRM_POLICY. src/lib/onboard/diagnostics/jetson-openrm-proof.ts:176-188 enables the matrix only when NEMOCLAW_DIAGNOSE_JETSON_OPENRM_POLICY equals "1" unless an explicit enabled option is supplied. src/lib/onboard/diagnostics/jetson-openrm-standalone.ts:92-122 accepts cuInit(0)=801, rolls back, and returns without itself enabling the matrix.

Workflow run details

This automated review informs maintainers. Warnings and suggestions do not require a response. A maintainer decides whether to merge.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/lib/onboard/docker-gpu-patch-recreate.ts (1)

266-281: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Preserve Jetson groups for startup-command recreation.

Line 266 excludes startup-command from Tegra group detection. A Jetson recreation using that supported mode never sets extraGroupGids or preserveJetsonDeviceGroupMembership. The clone builder then does not inject the bootstrap. After OpenShell calls initgroups(), the sandbox user can lose /dev/nvmap group access and CUDA can fail.

Remove the mode exclusion and add a startup-command recreation test.

Proposed fix

-    if (selection.mode.kind !== "startup-command" && options.backend === "jetson") {
+    if (options.backend === "jetson") {

As per path instructions, trace every in-scope entrypoint and lifecycle path.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/onboard/docker-gpu-patch-recreate.ts` around lines 266 - 281, Update
the Jetson Tegra group handling in the recreation flow to run for
startup-command mode as well by removing the selection.mode.kind exclusion from
the condition around detectTegraDeviceGroupGids. Preserve the existing
extraGroupGids and preserveJetsonDeviceGroupMembership assignments so the clone
builder injects the bootstrap, and add coverage for startup-command recreation.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/lib/onboard/docker-gpu-patch-recreate.ts`:
- Around line 266-281: Update the Jetson Tegra group handling in the recreation
flow to run for startup-command mode as well by removing the selection.mode.kind
exclusion from the condition around detectTegraDeviceGroupGids. Preserve the
existing extraGroupGids and preserveJetsonDeviceGroupMembership assignments so
the clone builder injects the bootstrap, and add coverage for startup-command
recreation.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: b94d4187-c252-4967-9c70-e3171ded73fd

📥 Commits

Reviewing files that changed from the base of the PR and between c378434 and 457d1f9.

📒 Files selected for processing (22)

• Dockerfile
• docs/reference/troubleshooting.mdx
• scripts/jetson-device-group-bootstrap.sh
• scripts/setup-jetson.sh
• src/lib/onboard.ts
• src/lib/onboard/docker-gpu-patch-clone.ts
• src/lib/onboard/docker-gpu-patch-jetson.test.ts
• src/lib/onboard/docker-gpu-patch-recreate.ts
• src/lib/onboard/docker-gpu-patch-types.ts
• src/lib/onboard/docker-gpu-sandbox-create.ts
• src/lib/onboard/initial-policy.test.ts
• src/lib/onboard/initial-policy.ts
• src/lib/onboard/sandbox-create-intent-types.ts
• src/lib/onboard/sandbox-create-intent.ts
• src/lib/onboard/sandbox-create-plan-materialization.ts
• src/lib/onboard/sandbox-create-plan.test.ts
• src/lib/onboard/sandbox-gpu-create-flow.ts
• src/lib/onboard/sandbox-gpu-create-run-attempt.ts
• src/lib/onboard/sandbox-gpu-create.ts
• test/e2e/live/jetson-nvmap-gpu.test.ts
• test/openclaw-final-image-layout.test.ts
• test/setup-jetson.test.ts

🚧 Files skipped from review as they are similar to previous changes (2)

• test/e2e/live/jetson-nvmap-gpu.test.ts
• scripts/setup-jetson.sh

[cjagwani]

Exact-head Jetson gate status for 67a85796caa655a3fdbebeb9da35fa9302fa6ed2:

• Selected run 30909030349 did not execute the Jetson validation. The jetson-nvmap-gpu job stopped at Guard Jetson runner dispatch.
• Therefore this is not passing or failing hardware evidence for [Jetson][Sandbox] Sandbox GPU passthrough proof fails for the non-root sandbox user on JetPack 6.2 IGX Orin — onboarding aborts #7610; it is an unavailable/unauthorized dispatch result.
• PR ci(e2e): omit Jetson from automatic PR plans #8230 removes Jetson from automatic PR planning so the general queue no longer stalls on this runner. It does not replace this PR's required exact-head Jetson validation.

Do not rerun or manually dispatch jetson-nvmap-gpu until an administrator authoritatively confirms that the exact trusted runner linux-arm64-gpu-jetson-orin-latest-1 is online. Once confirmed, this head still needs the live nvmap/group/CUDA proof before merge.

[apurvvkumaria]

Maintainer update for the current branch revision:

• Addressed all five outstanding automated review findings and replied on each thread. The three ShellCheck findings now use explicit fail-closed conditionals; the duplicate useless-conditional findings were removed by restoring the baseline policy unconditionally in finally.
• Fixed the PR-related CLI shard 5 failure by staging the Jetson bootstrap helper in the image-permission fixture before checking its 0500 mode.
• Merged current main normally and preserved the contributor history.
• Validation passes locally: 112 focused CLI tests, 19 focused integration tests, CLI build/typecheck, Vitest project membership, docs build and variant sync, and npm run check:diff.
• Nine-area security review passed with no blocking finding. Inputs remain bounded and locally derived; device discovery rejects symlinks and non-character devices; the root-owned wrapper accepts only the fixed OpenShell supervisor handoff and fails closed.
• Independent documentation review passed. The troubleshooting guidance accurately scopes this behavior to OpenClaw Jetson compatibility recreation and does not overstate hardware validation.

Remaining blocker: final end-to-end acceptance on trusted Jetson hardware. The non-root sandbox user must read and write /dev/nvmap, retain the required supplementary groups, and report cuInit(0)=0. No trusted Jetson runner has been authoritatively confirmed online, so I did not dispatch the restricted target. The PR remains draft pending that external evidence.

[apurvvkumaria]

Addressed the remaining bootstrap review feedback in revision f25c2b5.

• Split complete GID validation from account mutation. Inputs such as 44,invalid and 44,44 now fail before groupadd or usermod can change the sandbox account.
• Added direct execution coverage for the production wrapper in a container-isolated Linux fixture. The 11/11 cases cover valid existing and new groups, argument preservation, later invalid and duplicate values, the 16-group bound, range checks, the fixed supervisor target, non-root execution, a missing sandbox account, malformed group records, and failed membership verification.
• Added the compatibility-bridge removal condition and updated the Jetson troubleshooting documentation with the validate-before-mutate boundary.
• Completed an independent nine-category security review with no blocking finding in the intended patch.

Validation passed: all commit and push hooks; ShellCheck, shfmt, Biome, repository checks, and secret scan; 15/15 adjacent Jetson CLI tests; 11/11 direct bootstrap integration tests; test-title and project-membership checks; and the documentation build with 0 errors and the 2 existing warnings. GitHub reports the commit as Verified, and the commit includes DCO sign-off.

The PR remains draft only for the previously documented external acceptance blocker: current evidence from an affected Jetson that the non-root sandbox user retains the required device group, can read and write /dev/nvmap, and reports cuInit(0)=0, or an explicit maintainer waiver. Newly triggered GitHub Actions checks are queued during the ongoing service incident, so I have not forced reruns.

[apurvvkumaria]

Addressed PRA-1 on the current branch revision (7b70ce2cf).

• Baseline policy restoration and temporary-directory cleanup are now attempted independently.
• A structured restoration failure retains the candidate, restoration, and cleanup errors instead of losing the original diagnostic context.
• An unconfirmed baseline restoration is latched as a hard failure, so neither immediate nor later lifecycle rollback can proceed under the broader diagnostic policy.
• Regression coverage proves cleanup is attempted after restoration failure and that container rollback remains blocked.

Validation: focused Vitest 16/16 passed; CLI type-check passed; Biome, test-title validation, and git diff --check passed; normal commit and push hooks passed. Documentation review found no additional user-facing change. Security review found no new privilege, credential, egress, or command-execution exposure.