Problem Statement
Currently, NemoClaw's sandbox permissions are highly secure by design, utilizing Landlock and OpenShell to isolate the agent. However, this strict isolation becomes a significant friction point for local development workflows.
When running NemoClaw (e.g., via WSL 2 on Windows), users cannot easily grant the agent access to existing project directories located on the host machine (such as /mnt/c/Users/path/to/project ). Without the ability to securely read/write to external local directories, the agent cannot easily act as a local co-pilot, analyze existing local logs, or generate code directly into a developer's active workspace.
Proposed Design
How should this work?
We need a declarative way to safely bind-mount host directories into the sandbox while dynamically updating the internal security policies to permit access.
System Behavior & Components Involved:
CLI Interface: Introduce a new flag to the existing sandbox management commands, or a specific policy command. For example: nemoclaw sandbox policy-add --mount /host/local/path:/sandbox/target/path .
Container Level (Docker): When the sandbox is started or updated, the NemoClaw orchestrator translates this configuration into a standard Docker bind mount (-v /host/local/path:/sandbox/target/path).
Security Level (OpenShell & Landlock): The OpenShell gateway must dynamically read these custom mount paths from the configuration and append them to the Landlock whitelist during the sandbox initialization. This ensures the agent can read/write to the mounted directory without triggering kernel-level Permission denied errors.
User-Facing Interface:
Users should be able to define these mounts either interactively during nemoclaw onboard or declaratively via the CLI (e.g., nemoclaw sandbox mount add <local_path> ).
Alternatives Considered
1. Manually copying files via docker cp
Why it was evaluated: Users can theoretically copy their project files into the sandbox's default volume, let the agent modify them, and copy them back out.
Why the proposed design is better: It completely breaks the seamless local development loop. Changes made by the agent aren't immediately reflected in the user's host IDE, leading to data duplication and sync headaches.
2. Disabling Landlock / OpenShell
Why it was evaluated: Running the agent with elevated privileges or --privileged docker flags to bypass restrictions.
Why the proposed design is better: It defeats the core value proposition of NemoClaw (secure, guardrailed AI execution). The proposed design maintains the secure sandbox while opening specifically allowed, trackable "wormholes" to the host.
Category
enhancement: feature
Checklist
Thanks a lot!
Problem Statement
Currently, NemoClaw's sandbox permissions are highly secure by design, utilizing Landlock and OpenShell to isolate the agent. However, this strict isolation becomes a significant friction point for local development workflows.
When running NemoClaw (e.g., via WSL 2 on Windows), users cannot easily grant the agent access to existing project directories located on the host machine (such as
/mnt/c/Users/path/to/project). Without the ability to securely read/write to external local directories, the agent cannot easily act as a local co-pilot, analyze existing local logs, or generate code directly into a developer's active workspace.Proposed Design
How should this work?
We need a declarative way to safely bind-mount host directories into the sandbox while dynamically updating the internal security policies to permit access.
System Behavior & Components Involved:
CLI Interface: Introduce a new flag to the existing sandbox management commands, or a specific policy command. For example:
nemoclaw sandbox policy-add --mount /host/local/path:/sandbox/target/path.Container Level (Docker): When the sandbox is started or updated, the NemoClaw orchestrator translates this configuration into a standard Docker bind mount (
-v /host/local/path:/sandbox/target/path).Security Level (OpenShell & Landlock): The OpenShell gateway must dynamically read these custom mount paths from the configuration and append them to the Landlock whitelist during the sandbox initialization. This ensures the agent can read/write to the mounted directory without triggering kernel-level
Permission deniederrors.User-Facing Interface:
Users should be able to define these mounts either interactively during
nemoclaw onboardor declaratively via the CLI (e.g.,nemoclaw sandbox mount add <local_path>).Alternatives Considered
1. Manually copying files via
docker cpWhy it was evaluated: Users can theoretically copy their project files into the sandbox's default volume, let the agent modify them, and copy them back out.
Why the proposed design is better: It completely breaks the seamless local development loop. Changes made by the agent aren't immediately reflected in the user's host IDE, leading to data duplication and sync headaches.
2. Disabling Landlock / OpenShell
Why it was evaluated: Running the agent with elevated privileges or
--privilegeddocker flags to bypass restrictions.Why the proposed design is better: It defeats the core value proposition of NemoClaw (secure, guardrailed AI execution). The proposed design maintains the secure sandbox while opening specifically allowed, trackable "wormholes" to the host.
Category
enhancement: feature
Checklist
Thanks a lot!