fix(installer): recover sandboxes before onboarding - #6132
Conversation
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds prepared-backup recovery for pre-existing sandboxes during upgrades. It validates recovery manifests and managed-image evidence, threads recovery through rebuild and upgrade flows, moves installer recovery before onboarding, and updates docs and tests for the new behavior. ChangesPrepared Backup Recovery
Estimated code review effort: 4 (Complex) | ~60 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Code Coverage OverviewLanguages: TypeScript TypeScript / code-coverage/pluginThe overall coverage in the Show a code coverage summary of the most covered files.
TypeScript / code-coverage/cliThe overall coverage in the Show a code coverage summary of the most covered files.
Updated |
|
🌿 Preview your docs: https://nvidia-preview-pr-6132.docs.buildwithfern.com/nemoclaw |
PR Review Advisor — Changes requestedMerge posture: Do not merge yet Action checklist
Findings index
Review findings by urgency: 0 required fixes, 3 items to resolve/justify, 0 in-scope improvements
|
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
E2E Advisor RecommendationRequired E2E: Dispatch hint: Full advisor summaryE2E Recommendation AdvisorBase: Required E2E
Optional E2E
New E2E recommendations
Dispatch hint
|
E2E Target RecommendationRequired E2E targets: Dispatch required E2E targets:
Full E2E target advisor summaryE2E Target AdvisorBase: Required E2E targets
Optional E2E targets
Relevant changed files
|
PR Review Advisor (Nemotron Ultra) — Changes requestedMerge posture: Do not merge yet Action checklist
Findings index
🚨 Required before mergeAddress these before merging unless a maintainer explicitly overrides the advisor with rationale.
|
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (3)
src/lib/actions/upgrade-sandboxes.ts (2)
82-123: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueClassification logic reads well; consider a discriminant field over duck-typing.
isPreparedBackupRecoverydistinguishes the union via"manifest" in candidate. Works today, but aPreparedBackupRecovery/RejectedBackupRecoveryshape without a shared narrowing property (e.g. an explicitstatus: "prepared" | "rejected") is fragile if a future field addition accidentally introducesmanifeston the rejected variant.♻️ Optional refactor: explicit discriminant
type PreparedBackupRecovery = { + status: "prepared"; sandbox: registry.SandboxEntry; manifest: sandboxState.RebuildManifest; }; type RejectedBackupRecovery = { + status: "rejected"; sandbox: registry.SandboxEntry; reason: string; }; ... function isPreparedBackupRecovery( candidate: PreparedBackupRecovery | RejectedBackupRecovery, ): candidate is PreparedBackupRecovery { - return "manifest" in candidate; + return candidate.status === "prepared"; }🤖 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/actions/upgrade-sandboxes.ts` around lines 82 - 123, The backup recovery union in prepareBackupRecovery/isPreparedBackupRecovery relies on duck-typing via the manifest property, which is fragile. Add an explicit discriminant field to PreparedBackupRecovery and RejectedBackupRecovery (for example, a status or kind literal), set it in prepareBackupRecovery for each return path, and update isPreparedBackupRecovery to narrow on that discriminant instead of checking "manifest" in candidate. Keep the existing recovery/reason fields unchanged so callers can continue to use the same data.
264-294: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winFailure/success messaging doesn't distinguish recovery from ordinary rebuild.
Line 276 correctly picks
Recover/Rebuildfor the confirmation prompt, but the catch-block error (line 291,Failed to rebuild '${sandbox.name}') and the check-only summary line (line 242,to rebuild them) always say "rebuild" even for prepared-recovery items. Since this is the installer's operator-facing status for a data-recovery path (per PR objective of surfacing recovery failures clearly), reusing the same verb distinction used at line 276 would make failures easier to triage.♻️ Suggested fix
} catch (err) { const errorMessage = err instanceof Error ? err.message : String(err); - console.error(` ${YW}⚠${R} Failed to rebuild '${sandbox.name}': ${errorMessage}`); + console.error( + ` ${YW}⚠${R} Failed to ${manifest ? "recover" : "rebuild"} '${sandbox.name}': ${errorMessage}`, + ); failed++; }🤖 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/actions/upgrade-sandboxes.ts` around lines 264 - 294, The recovery workflow still logs and summarizes all outcomes as “rebuild,” even for prepared recovery items. Update the operator-facing messages in upgrade-sandboxes.ts to reuse the same verb selection already used in the askPrompt branch (Recover vs Rebuild), including the catch block around rebuildSandbox and the check-only summary text, so recovery failures and summaries are clearly distinguished from ordinary rebuilds.test/install-preexisting-sandbox-recovery.test.ts (1)
43-63: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
ensure_supported_runtime(andcommand_exists) are left unstubbed in an otherwise fully-mockedmain()harness.Since
_CLI_PATHis set,command_existsis unreachable, butensure_supported_runtimeruns for real right afterinstall_nodejs(stubbed). It likely passes harmlessly in CI, but it weakens the isolation of this harness and could make the test environment-dependent.🤖 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/install-preexisting-sandbox-recovery.test.ts` around lines 43 - 63, The fully mocked main() harness still leaves ensure_supported_runtime (and indirectly command_exists) unstubbed, so the test is not fully isolated. Add a no-op stub for ensure_supported_runtime in this test harness alongside the other mocked helpers, and only keep command_exists real if it is truly unreachable through _CLI_PATH; otherwise stub it too. Use the existing shell helper names in the harness to place the stubs consistently with install_nodejs, verify_nemoclaw, and run_onboard.
🤖 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.
Inline comments:
In `@scripts/install.sh`:
- Around line 2747-2754: The recover_preexisting_sandboxes_before_onboard
failure path is exiting too early and bypassing the install finalizer. In
scripts/install.sh, update the error handling around
recover_preexisting_sandboxes_before_onboard in the onboarding flow so it
records the failure but does not abort before finalize_install() runs; keep the
existing run_onboard/error and ONBOARD_RAN logic intact so print_done() can emit
the _UPGRADE_SANDBOXES_FAILED recovery guidance with the affected sandbox and
backup details.
In `@src/lib/actions/upgrade-sandboxes-recovery.test.ts`:
- Line 12: The test cleanup logic in upgrade-sandboxes-recovery.test.ts adds a
new conditional branch around restoring
NEMOCLAW_RESTORE_LATEST_BACKUP_ON_RECREATE in afterEach, which triggers the
conditional scan. Replace the manual save/restore pattern around
originalRecoverySignal with Vitest’s environment helpers in the test setup,
using vi.stubEnv for the variable and vi.unstubAllEnvs in cleanup so the
original value is restored automatically. Keep the change localized to the
test’s beforeEach/afterEach flow and remove the explicit if branch tied to
originalRecoverySignal.
In `@test/install-preexisting-sandbox-recovery.test.ts`:
- Line 63: The failing-recovery test uses a no-op finalize_install stub, which
lets the test pass without proving the recovery path actually reaches
completion. Update the finalize_install stub in the
install-preexisting-sandbox-recovery test to record a call-log entry (matching
the other stubs), then assert that entry is present so the test verifies
finalize_install is invoked after recovery. Use the existing finalize_install,
calls, and result assertions in the test to locate the change.
In `@test/snapshot-recovery-validation.test.ts`:
- Around line 47-54: The teardown in afterAll is using a manual conditional to
restore HOME, which the test guardrail wants avoided. Update the
snapshot-recovery-validation test to use Vitest’s vi.stubEnv for setting HOME
and vi.unstubAllEnvs for cleanup, and keep the existing TMP_HOME removal in the
same teardown path. Use the afterAll block and the ORIGINAL_HOME /
process.env.HOME handling as the place to switch to env stubbing.
---
Nitpick comments:
In `@src/lib/actions/upgrade-sandboxes.ts`:
- Around line 82-123: The backup recovery union in
prepareBackupRecovery/isPreparedBackupRecovery relies on duck-typing via the
manifest property, which is fragile. Add an explicit discriminant field to
PreparedBackupRecovery and RejectedBackupRecovery (for example, a status or kind
literal), set it in prepareBackupRecovery for each return path, and update
isPreparedBackupRecovery to narrow on that discriminant instead of checking
"manifest" in candidate. Keep the existing recovery/reason fields unchanged so
callers can continue to use the same data.
- Around line 264-294: The recovery workflow still logs and summarizes all
outcomes as “rebuild,” even for prepared recovery items. Update the
operator-facing messages in upgrade-sandboxes.ts to reuse the same verb
selection already used in the askPrompt branch (Recover vs Rebuild), including
the catch block around rebuildSandbox and the check-only summary text, so
recovery failures and summaries are clearly distinguished from ordinary
rebuilds.
In `@test/install-preexisting-sandbox-recovery.test.ts`:
- Around line 43-63: The fully mocked main() harness still leaves
ensure_supported_runtime (and indirectly command_exists) unstubbed, so the test
is not fully isolated. Add a no-op stub for ensure_supported_runtime in this
test harness alongside the other mocked helpers, and only keep command_exists
real if it is truly unreachable through _CLI_PATH; otherwise stub it too. Use
the existing shell helper names in the harness to place the stubs consistently
with install_nodejs, verify_nemoclaw, and run_onboard.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 0b167b90-14ef-4b1a-bc93-11e0afaae9d3
📒 Files selected for processing (10)
docs/get-started/quickstart.mdxdocs/manage-sandboxes/lifecycle.mdxscripts/install.shsrc/lib/actions/sandbox/rebuild-flow.test.tssrc/lib/actions/sandbox/rebuild.tssrc/lib/actions/upgrade-sandboxes-recovery.test.tssrc/lib/actions/upgrade-sandboxes.tssrc/lib/state/sandbox.tstest/install-preexisting-sandbox-recovery.test.tstest/snapshot-recovery-validation.test.ts
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/lib/actions/upgrade-sandboxes-recovery.test.ts (1)
168-183: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winTest doesn't actually exercise the "different gateway" scenario it claims.
The test title says the sandbox is "registered on a different gateway," but
liveOutput: "No sandboxes found."makes the sandbox simply absent from the live listing entirely — indistinguishable from any other "not observed live" case. ThegatewayNamesoption only feedsregistry.listSandboxes, which isn't consulted by thenonReadyLiveNamesgating logic under test (perupgrade-sandboxes.tsContext snippet 2, eligibility is derived purely from parsed live entries, not registrygatewayName). This passes without exercising cross-gateway matching at all — a scenario that matters for the underlying bug (#6114).To actually test gateway-based exclusion, the live output should show the sandbox as
Ready/present on a different gateway's listing than the one being checked, or the harness needs to support per-gateway live output.As per path instructions: "Flag ... conditionals that make a test pass without exercising its claim."
🤖 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/actions/upgrade-sandboxes-recovery.test.ts` around lines 168 - 183, The test in upgrade-sandboxes-recovery.test.ts is claiming a cross-gateway Ready sandbox case but currently only proves the sandbox is missing from live output. Update the harness setup in createRecoveryHarness/upgradeSandboxes test so the sandbox appears in live entries on a different gateway (not just in registry.listSandboxes via gatewayNames), and assert the recovery logic still skips it; this ensures the nonReadyLiveNames gating in upgradeSandboxes.ts is actually exercised.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 `@src/lib/actions/upgrade-sandboxes-recovery.test.ts`:
- Around line 168-183: The test in upgrade-sandboxes-recovery.test.ts is
claiming a cross-gateway Ready sandbox case but currently only proves the
sandbox is missing from live output. Update the harness setup in
createRecoveryHarness/upgradeSandboxes test so the sandbox appears in live
entries on a different gateway (not just in registry.listSandboxes via
gatewayNames), and assert the recovery logic still skips it; this ensures the
nonReadyLiveNames gating in upgradeSandboxes.ts is actually exercised.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 86d02ad6-c96b-426c-a1c6-75599a71eda4
📒 Files selected for processing (2)
src/lib/actions/upgrade-sandboxes-recovery.test.tssrc/lib/actions/upgrade-sandboxes.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/lib/actions/upgrade-sandboxes.ts
Vitest E2E Target Results — ✅ All requested jobs passedRun: 28536356354
|
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
Vitest E2E Target Results — ✅ All requested jobs passedRun: 28537782550
|
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
|
Safety correction at
Focused verification is 31/31 green, with typecheck, Biome, source-shape, test-size, docs, and diff checks passing. The PR body no longer says |
Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
## Summary - Add the `v0.0.72` release-note section with links to the deeper docs pages for installer recovery, command diagnostics, inference, policy, and sandbox repair changes. - Document the custom preset `allowed_ips` guard for user-authored policy files. ## Related Issue None. ## Source summary - #6132 -> `docs/about/release-notes.mdx`: Summarizes installer and upgrade recovery before generic onboarding, with links to quickstart and lifecycle docs. - #6087 -> `docs/network-policy/customize-network-policy.mdx`: Documents that user-authored custom presets reject `allowed_ips` for ordinary endpoints; also summarized in release notes. - #5975 -> `docs/about/release-notes.mdx`: Summarizes safer curl-based inference probes that keep API keys out of process arguments. - #6044 -> `docs/about/release-notes.mdx`: Summarizes compact `channels status` configuration reporting. - #6096 -> `docs/about/release-notes.mdx`: Summarizes OpenClaw EC2 metadata discovery disablement and links to security guidance. - #5980 and #5991 -> `docs/about/release-notes.mdx`: Summarizes `exec` multiline argument rejection and recovery guidance. - #6023 -> `docs/about/release-notes.mdx`: Summarizes registered-provider diagnostics for `inference set` failures. - #6074 -> `docs/about/release-notes.mdx`: Summarizes the refreshed NVIDIA Endpoints featured-model selection behavior. - #5969 -> `docs/about/release-notes.mdx`: Summarizes `credentials add` provider credential registration. - #6060 -> `docs/about/release-notes.mdx`: Summarizes mutable OpenClaw config permission restoration after `exec`. - #6134 -> `docs/about/release-notes.mdx`: Summarizes restored Tavily access for managed Python workflows. - #6089 -> `docs/about/release-notes.mdx`: Summarizes Hermes runtime version-scheme comparison during upgrade checks. - #6131 -> `docs/about/release-notes.mdx`: Summarizes OpenClaw gateway watchdog recovery behavior. - #5976 and #5990 -> `docs/about/release-notes.mdx`: Summarizes prompt stdin EOF cancellation behavior during onboarding. - #5540 -> `docs/about/release-notes.mdx`: Summarizes clarified host-level and per-sandbox status command scope. - #5978 and #6018 -> `docs/about/release-notes.mdx`: Summarizes policy-denial log breadcrumbs in connect shells. ## Testing - `npm run docs:sync-agent-variants` - `npm run docs` - Commit hooks passed during `git commit`, including commitlint and gitleaks. - Pre-push hook passed during `git push`, including TypeScript CLI and package/tag version sync. ## Checklist - [x] Documentation updated. - [x] `npm run docs` completed with 0 errors and 1 existing Fern warning. - [x] No source code or generated build artifacts committed. Signed-off-by: Miyoung Choi <miyoungc@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added release notes for v0.0.72 covering improved installer recovery, clearer CLI diagnostics, safer inference setup and provider switching, better credential handling, stronger policy boundaries, and more robust runtime repair behavior. * Updated network policy guidance to clarify when `allowed_ips` can be used, including a specific exception for the sandbox-to-host bridge endpoint. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- markdownlint-disable MD041 --> ## Summary This change runs validated prepared-backup recovery before the installer starts generic onboarding. It reuses the existing installer recovery signal and rebuild machinery, fails closed on identity or managed-image evidence mismatches, and stops onboarding if any recovery fails. Focused verification passes. However, v0.0.55 recorded no trustworthy per-sandbox managed/custom image provenance, so this PR now rejects those ambiguous entries and does not by itself resolve NVIDIA#6114. ## Related Issue Related to NVIDIA#6114 ## Changes - Run `upgrade-sandboxes --auto` for pre-existing sandboxes before generic onboarding. - Under `NEMOCLAW_RESTORE_LATEST_BACKUP_ON_RECREATE=1`, include registered non-Ready sandboxes only when their latest backup validates against the sandbox and agent identity. - Require an explicitly observed, known non-Ready live phase so an absent registry entry—such as a Ready sandbox on another gateway—is never selected for prepared recovery. - Isolate backup-assessment failures per sandbox, attempt every later eligible recovery, and return aggregate nonzero when any eligible recovery is blocked or fails. - Require a non-empty NemoClaw-managed image fingerprint and reject pre-fingerprint, missing, mismatched, or custom-image recovery inputs before deletion; matching agent versions are explicitly not accepted as provenance. - Revalidate the registry entry and latest manifest immediately before the destructive phase. - Reuse the validated manifest in the existing rebuild path instead of creating a second unreachable backup. - Preserve the existing registry rollback and state-restore behavior when recreation fails. - Attempt every eligible recovery and return nonzero before onboarding if any recovery fails. - Route recovery failure through the installer completion summary so preserved-backup guidance is shown before the nonzero exit. - Add focused rebuild, manifest-validation, upgrade classification, installer-ordering, and rollback coverage. - Document the installer's pre-onboarding recovery behavior. - Local validation passed for CLI build/typecheck, focused CLI and integration tests, shell checks, Biome, project membership, source-shape, and test-size checks. The Fern docs check completed with 0 errors and 2 warnings. - Live v0.0.55 upgrade acceptance is blocked by missing trustworthy legacy image provenance: safely recovering raw v0.0.55 managed images while rejecting custom images requires a separate design. No v0.0.55 recovery success is claimed here. ## Type of Change - [ ] Code change (feature, bug fix, or refactor) - [x] Code change with doc updates - [ ] Doc only (prose changes, no code sample modifications) - [ ] Doc only (includes code sample changes) ## Quality Gates <!-- Check all that apply. For any "covered by existing tests", "not applicable", or waiver entry, add a brief justification on the same line or in the Changes section. --> - [x] Tests added or updated for changed behavior - [ ] Existing tests cover changed behavior — justification: - [ ] Tests not applicable — justification: - [x] Docs updated for user-facing behavior changes - [ ] Docs not applicable — justification: - [x] Sensitive paths changed (security, policy, credentials, preflight, onboarding, inference, runner, sandbox, or messaging) - [x] Sensitive-path review completed or maintainer-approved waiver recorded — reviewer/approval link/justification: Independent review through `35ab003bbba4159cb630b9e04566261ce5401c8b` confirmed the fingerprint-only rule blocks the probed-custom-image deletion path and also confirmed raw v0.0.55 recovery remains unresolved. - [ ] Non-success, skipped, or missing CI check accepted by maintainer — check name, approval link, and follow-up issue: ## Verification <!-- Check each item you ran and confirmed. Leave unchecked items you skipped. Doc-only changes do not require npm test unless you ran it. --> - [x] PR description includes the DCO sign-off declaration and every commit appears as `Verified` in GitHub - [ ] Git hooks passed during commit and push, or `npx prek run --from-ref main --to-ref HEAD` passes - [x] Targeted tests pass for changed behavior - [ ] Full `npm test` passes (broad runtime changes only) - [x] Quality Gates section completed with required justifications or waivers - [x] No secrets, API keys, or credentials committed - [ ] `npm run docs` builds without warnings (doc changes only) - [ ] Doc pages follow the [style guide](https://github.com/NVIDIA/NemoClaw/blob/main/docs/CONTRIBUTING.md) (doc changes only) - [ ] New doc pages include SPDX header and frontmatter (new pages only) --- <!-- DCO sign-off is required in this PR description, and every commit must appear as Verified in GitHub. Run: git config user.name && git config user.email --> Signed-off-by: Aaron Erickson <aerickson@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Installer/upgrade workflows now recover pre-existing non-Ready sandboxes before starting generic onboarding, including prepared recovery from the latest validated pre-upgrade backup when eligible and evidenced. * **Bug Fixes** * Recovery is fail-closed: if recovery can’t be completed for any eligible sandbox, the process stops and does not proceed with generic onboarding. * Added stronger identity, manifest, and managed-image evidence checks to prevent unsafe recreate/recovery. * Upgrade output now clearly distinguishes “prepared” vs “rejected” recovery candidates. * **Documentation** * Updated quickstart and lifecycle upgrade guides to match the recovery-first flow. * **Tests** * Expanded coverage for recovery ordering and prepared-backup recovery validation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: Aaron Erickson <aerickson@nvidia.com>
## Summary - Add the `v0.0.72` release-note section with links to the deeper docs pages for installer recovery, command diagnostics, inference, policy, and sandbox repair changes. - Document the custom preset `allowed_ips` guard for user-authored policy files. ## Related Issue None. ## Source summary - NVIDIA#6132 -> `docs/about/release-notes.mdx`: Summarizes installer and upgrade recovery before generic onboarding, with links to quickstart and lifecycle docs. - NVIDIA#6087 -> `docs/network-policy/customize-network-policy.mdx`: Documents that user-authored custom presets reject `allowed_ips` for ordinary endpoints; also summarized in release notes. - NVIDIA#5975 -> `docs/about/release-notes.mdx`: Summarizes safer curl-based inference probes that keep API keys out of process arguments. - NVIDIA#6044 -> `docs/about/release-notes.mdx`: Summarizes compact `channels status` configuration reporting. - NVIDIA#6096 -> `docs/about/release-notes.mdx`: Summarizes OpenClaw EC2 metadata discovery disablement and links to security guidance. - NVIDIA#5980 and NVIDIA#5991 -> `docs/about/release-notes.mdx`: Summarizes `exec` multiline argument rejection and recovery guidance. - NVIDIA#6023 -> `docs/about/release-notes.mdx`: Summarizes registered-provider diagnostics for `inference set` failures. - NVIDIA#6074 -> `docs/about/release-notes.mdx`: Summarizes the refreshed NVIDIA Endpoints featured-model selection behavior. - NVIDIA#5969 -> `docs/about/release-notes.mdx`: Summarizes `credentials add` provider credential registration. - NVIDIA#6060 -> `docs/about/release-notes.mdx`: Summarizes mutable OpenClaw config permission restoration after `exec`. - NVIDIA#6134 -> `docs/about/release-notes.mdx`: Summarizes restored Tavily access for managed Python workflows. - NVIDIA#6089 -> `docs/about/release-notes.mdx`: Summarizes Hermes runtime version-scheme comparison during upgrade checks. - NVIDIA#6131 -> `docs/about/release-notes.mdx`: Summarizes OpenClaw gateway watchdog recovery behavior. - NVIDIA#5976 and NVIDIA#5990 -> `docs/about/release-notes.mdx`: Summarizes prompt stdin EOF cancellation behavior during onboarding. - NVIDIA#5540 -> `docs/about/release-notes.mdx`: Summarizes clarified host-level and per-sandbox status command scope. - NVIDIA#5978 and NVIDIA#6018 -> `docs/about/release-notes.mdx`: Summarizes policy-denial log breadcrumbs in connect shells. ## Testing - `npm run docs:sync-agent-variants` - `npm run docs` - Commit hooks passed during `git commit`, including commitlint and gitleaks. - Pre-push hook passed during `git push`, including TypeScript CLI and package/tag version sync. ## Checklist - [x] Documentation updated. - [x] `npm run docs` completed with 0 errors and 1 existing Fern warning. - [x] No source code or generated build artifacts committed. Signed-off-by: Miyoung Choi <miyoungc@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added release notes for v0.0.72 covering improved installer recovery, clearer CLI diagnostics, safer inference setup and provider switching, better credential handling, stronger policy boundaries, and more robust runtime repair behavior. * Updated network policy guidance to clarify when `allowed_ips` can be used, including a specific exception for the sandbox-to-host bridge endpoint. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Summary
This change runs validated prepared-backup recovery before the installer starts generic onboarding.
It reuses the existing installer recovery signal and rebuild machinery, fails closed on identity or managed-image evidence mismatches, and stops onboarding if any recovery fails.
Focused verification passes. However, v0.0.55 recorded no trustworthy per-sandbox managed/custom image provenance, so this PR now rejects those ambiguous entries and does not by itself resolve #6114.
Related Issue
Related to #6114
Changes
upgrade-sandboxes --autofor pre-existing sandboxes before generic onboarding.NEMOCLAW_RESTORE_LATEST_BACKUP_ON_RECREATE=1, include registered non-Ready sandboxes only when their latest backup validates against the sandbox and agent identity.Type of Change
Quality Gates
35ab003bbba4159cb630b9e04566261ce5401c8bconfirmed the fingerprint-only rule blocks the probed-custom-image deletion path and also confirmed raw v0.0.55 recovery remains unresolved.Verification
Verifiedin GitHubnpx prek run --from-ref main --to-ref HEADpassesnpm testpasses (broad runtime changes only)npm run docsbuilds without warnings (doc changes only)Signed-off-by: Aaron Erickson aerickson@nvidia.com
Summary by CodeRabbit