[laitingsheng]

Summary

/opt/nemoclaw/package.json ends up root:root 440 in the sandbox image when the host checkout (~/.nemoclaw/source/nemoclaw/) has restrictive modes, because stage{Legacy,Optimized}SandboxBuildContext only normalise the nemoclaw-blueprint/ subtree before docker build. USER sandbox then can't read it and openclaw plugins install /opt/nemoclaw fails with JsonFileReadError: Failed to read JSON file: /opt/nemoclaw/package.json. Mirror the existing blueprint normalisation onto the staged nemoclaw/ subtree, and add a defence-in-depth chmod -R a+rX /opt/nemoclaw to the in-image RUN that already normalises /opt/nemoclaw-blueprint/.

Related Issue

Fixes #4177

Changes

• src/lib/sandbox/build-context.ts — call normalizeReadModesForDockerCopy(stagedNemoclawDir) in both stageLegacySandboxBuildContext and stageOptimizedSandboxBuildContext, mirroring the existing blueprint handling.
• Dockerfile — extend chmod -R a+rX to cover /opt/nemoclaw as well as /opt/nemoclaw-blueprint/, so custom build-contexts that bypass the staging code still recover.
• test/sandbox-build-context.test.ts — new fixtures with restrictive (0o600 files, 0o700 dirs) nemoclaw/ modes, plus optimised + legacy staging assertions that the copy ends up world-readable.
• test/sandbox-provisioning.test.ts — extend the existing chmod regression test to also stage a restrictive /opt/nemoclaw/package.json and assert it ends up 444.

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)

Verification

• npx prek run --all-files passes
• npm test passes
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• make docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: Tinson Lai tinsonl@nvidia.com

Summary by CodeRabbit

• Bug Fixes

  • Corrected file permission configuration for runtime components in containerized environments to ensure proper accessibility.

• Tests

  • Added test coverage for file permission normalization in containerized builds.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request fixes a Docker build failure where the sandbox user cannot read plugin files in /opt/nemoclaw due to restrictive permissions. The fix normalizes read/execute permissions during build staging and in the runtime Docker image chmod command.

Changes

NemoClaw plugin permission normalization

Layer / File(s)	Summary
Build context permission normalization src/lib/sandbox/build-context.ts	Legacy and optimized staging paths both call normalizeReadModesForDockerCopy on the staged nemoclaw directory alongside the existing blueprint normalization.
Docker image permission command Dockerfile	The chmod -R a+rX command is updated to apply read/execute permissions recursively to both /opt/nemoclaw and /opt/nemoclaw-blueprint.
Build context permission tests test/sandbox-build-context.test.ts	Fixture setup creates restrictive initial nemoclaw permissions (0o600 files, 0o700 directories); a new expectStagedNemoclawModes helper asserts staged nemoclaw directories and files achieve world-readable modes; two new test cases validate optimized and legacy staging normalize permissions correctly.
Provisioning integration tests test/sandbox-provisioning.test.ts	Sandbox provisioning test setup adds nemoclawRoot with restrictive initial package.json permissions; Docker command extraction extends path rewrites to include /opt/nemoclaw → nemoclawRoot and blueprint root substitution; assertions verify resulting permission modes (755 for nemoclawRoot, 444 for pluginPackageJson) alongside existing blueprint checks.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Suggested labels

fix, Sandbox, Docker

Suggested reviewers

• ericksoa

Poem

🐰 Permissions fixed with careful care,
Nemoclaw files now readable—fair!
Docker builds succeed, no more despair,
Plugin install blooms in bright sandbox air. 🎪

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	All code changes directly address the linked issue #4177 objectives: normalizing read permissions for /opt/nemoclaw files to fix the JsonFileReadError caused by restrictive permissions during Docker build.
Out of Scope Changes check	✅ Passed	All changes are scoped to fixing the permissions issue: Dockerfile chmod extension, build-context normalization calls, and comprehensive test coverage for both legacy and optimized staging paths.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: normalizing nemoclaw plugin build context permissions across the Dockerfile, build-context staging logic, and related tests.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/4177-nemoclaw-build-context-perms

---

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

[github-actions]

PR Review Advisor

Findings: 0 needs attention, 2 worth checking, 0 nice ideas
Since last review: 1 prior item resolved, 2 still apply, 0 new items found

Review findings

🛠️ Needs attention

• None.

🔎 Worth checking

• Add runtime validation for sandbox plugin permissions (src/lib/sandbox/build-context.ts:50): The code now normalizes the staged `nemoclaw` subtree in both legacy and optimized build contexts, and the Dockerfile adds an in-image `chmod -R a+rX /opt/nemoclaw`. Unit tests and shell-slice provisioning tests cover the permission transformations, but the reported failure occurs during the actual sandbox image build when `openclaw plugins install /opt/nemoclaw` runs as the non-root sandbox user. The diff still does not include a focused runtime/integration validation of that Docker COPY/install path from a restrictive checkout.
  • Recommendation: Add or identify a targeted runtime validation that builds or otherwise exercises the sandbox build path from restrictive source modes and verifies the sandbox user can read `/opt/nemoclaw/package.json` and complete the plugin install step. Do not rely on external E2E pass/fail status in this review surface.
  • Evidence: `stageLegacySandboxBuildContext` calls `normalizeReadModesForDockerCopy(path.join(buildCtx, "nemoclaw"))` after removing `node_modules`, `stageOptimizedSandboxBuildContext` calls `normalizeReadModesForDockerCopy(stagedNemoclawDir)`, and `Dockerfile` line 64 changes the image layer to `RUN chmod -R a+rX /opt/nemoclaw /opt/nemoclaw-blueprint/`. Tests assert staged files become readable and the shell-slice chmod turns a restrictive package.json into mode `444`, but the trusted testDepth signal remains `runtime_validation_recommended` for Dockerfile and `src/lib/sandbox/build-context.ts`.
• Coordinate overlapping sandbox build-context and Dockerfile work (Dockerfile:64): The changed files still exist and the patch is against active sandbox/Dockerfile surfaces that overlap several open PRs. This is not a defect in the diff itself, but the affected code is security- and reliability-sensitive, and concurrent changes can reintroduce drift in assumptions about staged files, Docker COPY permissions, or provisioning tests.
  • Recommendation: Before landing, compare the final intended build-context and Dockerfile permission behavior against the overlapping PRs touching the same files, especially PRs feat(hermes): request network access through policy local #3750, feat(sandbox): install provider access tools #3747, feat(hermes): request network access through policy local #3748, feat(plugin): add provider-first access tools #3749, and fix(docker): align in-container healthcheck with delivery chain on OpenShell-managed runtimes #4180.
  • Evidence: Trusted drift evidence shows `Dockerfile`, `src/lib/sandbox/build-context.ts`, `test/sandbox-build-context.test.ts`, and `test/sandbox-provisioning.test.ts` still exist and are modified here. `openPrOverlaps` lists PR feat(hermes): request network access through policy local #3750 touching all four files; PRs feat(sandbox): install provider access tools #3747, feat(hermes): request network access through policy local #3748, and feat(plugin): add provider-first access tools #3749 touching `Dockerfile`, `src/lib/sandbox/build-context.ts`, and `test/sandbox-build-context.test.ts`; and PR fix(docker): align in-container healthcheck with delivery chain on OpenShell-managed runtimes #4180 touching `Dockerfile` and `test/sandbox-provisioning.test.ts`.

🌱 Nice ideas

• None.

Since last review details

Current findings:

• Add runtime validation for sandbox plugin permissions (src/lib/sandbox/build-context.ts:50): The code now normalizes the staged `nemoclaw` subtree in both legacy and optimized build contexts, and the Dockerfile adds an in-image `chmod -R a+rX /opt/nemoclaw`. Unit tests and shell-slice provisioning tests cover the permission transformations, but the reported failure occurs during the actual sandbox image build when `openclaw plugins install /opt/nemoclaw` runs as the non-root sandbox user. The diff still does not include a focused runtime/integration validation of that Docker COPY/install path from a restrictive checkout.
  • Recommendation: Add or identify a targeted runtime validation that builds or otherwise exercises the sandbox build path from restrictive source modes and verifies the sandbox user can read `/opt/nemoclaw/package.json` and complete the plugin install step. Do not rely on external E2E pass/fail status in this review surface.
  • Evidence: `stageLegacySandboxBuildContext` calls `normalizeReadModesForDockerCopy(path.join(buildCtx, "nemoclaw"))` after removing `node_modules`, `stageOptimizedSandboxBuildContext` calls `normalizeReadModesForDockerCopy(stagedNemoclawDir)`, and `Dockerfile` line 64 changes the image layer to `RUN chmod -R a+rX /opt/nemoclaw /opt/nemoclaw-blueprint/`. Tests assert staged files become readable and the shell-slice chmod turns a restrictive package.json into mode `444`, but the trusted testDepth signal remains `runtime_validation_recommended` for Dockerfile and `src/lib/sandbox/build-context.ts`.
• Coordinate overlapping sandbox build-context and Dockerfile work (Dockerfile:64): The changed files still exist and the patch is against active sandbox/Dockerfile surfaces that overlap several open PRs. This is not a defect in the diff itself, but the affected code is security- and reliability-sensitive, and concurrent changes can reintroduce drift in assumptions about staged files, Docker COPY permissions, or provisioning tests.
  • Recommendation: Before landing, compare the final intended build-context and Dockerfile permission behavior against the overlapping PRs touching the same files, especially PRs feat(hermes): request network access through policy local #3750, feat(sandbox): install provider access tools #3747, feat(hermes): request network access through policy local #3748, feat(plugin): add provider-first access tools #3749, and fix(docker): align in-container healthcheck with delivery chain on OpenShell-managed runtimes #4180.
  • Evidence: Trusted drift evidence shows `Dockerfile`, `src/lib/sandbox/build-context.ts`, `test/sandbox-build-context.test.ts`, and `test/sandbox-provisioning.test.ts` still exist and are modified here. `openPrOverlaps` lists PR feat(hermes): request network access through policy local #3750 touching all four files; PRs feat(sandbox): install provider access tools #3747, feat(hermes): request network access through policy local #3748, and feat(plugin): add provider-first access tools #3749 touching `Dockerfile`, `src/lib/sandbox/build-context.ts`, and `test/sandbox-build-context.test.ts`; and PR fix(docker): align in-container healthcheck with delivery chain on OpenShell-managed runtimes #4180 touching `Dockerfile` and `test/sandbox-provisioning.test.ts`.

Workflow run details

This is an automated advisory review. A human maintainer must make the final merge decision.

[github-actions]

E2E Advisor Recommendation

Required E2E: openclaw-onboard-security-posture-e2e, rebuild-openclaw-e2e
Optional E2E: cloud-onboard-e2e, sandbox-operations-e2e

Dispatch hint: openclaw-onboard-security-posture-e2e,rebuild-openclaw-e2e

Auto-dispatched E2E: openclaw-onboard-security-posture-e2e, rebuild-openclaw-e2e via nightly-e2e.yaml at 1a82566a56e16a277a4d98ae1fd1ceeb1e01c5ec — nightly run

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• openclaw-onboard-security-posture-e2e (high; timeout 60 minutes): Runs a full OpenClaw install/onboard/inference flow with non-root host/security posture assertions. This is the most relevant merge-blocking check for Dockerfile permission changes that must leave sandbox runtime files readable without weakening security boundaries.
• rebuild-openclaw-e2e (high; timeout 60 minutes): Exercises OpenClaw sandbox rebuild from an older image into the current image, covering the staged build context and Dockerfile path after an existing sandbox lifecycle transition.

Optional E2E

• cloud-onboard-e2e (high; timeout 45 minutes): Useful additional confidence for the public installer/onboarding path, sandbox health, Landlock read-only enforcement, API key leak checks, and inference.local after image permission changes.
• sandbox-operations-e2e (high; timeout 60 minutes): Adjacent lifecycle confidence for list/status/logs/exec/destroy and recovery behavior after changes to sandbox image build inputs, but less directly targeted than onboard and rebuild.

New E2E recommendations

• sandbox image file permissions (high): Existing E2E coverage appears indirect for the exact regression class: production OpenClaw image files under /opt/nemoclaw should be readable by the sandbox user after Docker COPY preserves restrictive source modes. A targeted image-level assertion would catch this cheaply before full onboard failures.
  • Suggested test: Add an OpenClaw production-image permission check analogous to the Hermes image check: build the production sandbox image and docker run --user sandbox test -r /opt/nemoclaw/package.json, /opt/nemoclaw/openclaw.plugin.json, and representative /opt/nemoclaw/dist files.

Dispatch hint

• Workflow: nightly-e2e.yaml
• jobs input: openclaw-onboard-security-posture-e2e,rebuild-openclaw-e2e

[github-actions]

E2E Scenario Advisor Recommendation

Required scenario E2E: None
Optional scenario E2E: None

Workflow run

Full scenario advisor summary

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. No scenario workflow, scenario metadata, scenario runtime, or validation-suite files changed.

Optional scenario E2E

• None.

Relevant changed files

• None.

[github-actions]

Selective E2E Results — ✅ All requested jobs passed

Run: 26395476445
Target ref: e7ef1f48f671fc6efbf1b971eb420fb7349f76a2
Workflow ref: main
Requested jobs: cloud-onboard-e2e,openclaw-onboard-security-posture-e2e
Summary: 0 passed, 0 failed, 0 skipped

Job	Result
cloud-onboard-e2e	⚠️ cancelled
openclaw-onboard-security-posture-e2e	⚠️ cancelled

[github-actions]

Selective E2E Results — ✅ All requested jobs passed

Run: 26395652774
Target ref: 1a82566a56e16a277a4d98ae1fd1ceeb1e01c5ec
Workflow ref: main
Requested jobs: openclaw-onboard-security-posture-e2e,rebuild-openclaw-e2e
Summary: 2 passed, 0 failed, 0 skipped

Job	Result
openclaw-onboard-security-posture-e2e	✅ success
rebuild-openclaw-e2e	✅ success