NVIDIA / NVIDIA/NemoClaw

Add a persistent security-aware sandbox environment contract for skills

Open
#7,176 1 comment 0 reactions 0 assignees View on GitHub
area: cli area: sandbox area: security area: skills integration: dcode integration: hermes needs: design
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 1h
Merged PRs (30d)
715

Description

## Problem Statement

NemoClaw has no supported way to declare sandbox environment values that are available to an agent/skills, survive rebuild, preserve agent config sealing, and keep secrets behind the OpenShell provider boundary.

Confirmed on `main` at `4deebcf9cfd0d54c9b9b5fb1907d153a462818f3`:

- No sandbox environment command exists under `src/commands/sandbox/`.
- `sandbox config set` changes agent config, not process environment.
- `credentials add` registers an OpenShell provider but exposes no sandbox-scoped environment projection.
- `skill install` has no environment contract.
- `src/lib/onboard/sandbox-create-launch.ts` assembles runtime environment only from internal allowlists at create time.
- Rebuild preserves manifest `state_dirs`/`state_files`; `.bash_profile` is not durable.
- Hermes `.env` is generated/sealed, classified as user-managed only for rebuild warnings, and guarded by strict hashes and secret-boundary checks.
- Deep Agents also intentionally rejects raw credential-bearing environment state.

The current workaround, writing `/sandbox/.bash_profile`, is inconsistent for managed/non-login processes and is destroyed by rebuild. Direct `.env` edits can create hash drift and must not be recommended.

## Desired Behavior

Add sandbox-scoped declarative state, conceptually:

```bash
nemoclaw env set MY_REGION=us-west-2
nemoclaw env set API_TOKEN --from-provider my-service --credential-key API_TOKEN
nemoclaw env list
nemoclaw env unset MY_REGION
```

For non-secret values:

- persist desired state in the sandbox registry and create/rebuild intent;
- make values available to the managed agent and child skill processes;
- document whether `exec`/`connect` inherit them, preferably yes for diagnostic parity;
- report pending versus applied state and require explicit rebuild/restart rather than silently replacing a sandbox;
- reject credential-shaped keys/values and reserved runtime/code-execution variables.

For credentials, never accept raw `KEY=secret`. Store only provider identity, credential-key name, placeholder shape, and applied status. Attach the exact provider and project `openshell:resolve:env:` only where OpenShell can resolve it at egress. If a skill needs local raw-secret access, fail as unsupported rather than weakening the boundary.

## Constraints and Non-goals

- No arbitrary host-environment pass-through, plaintext secret storage, or local raw-secret access.
- No build ARG/ENV, image-layer, snapshot, `.bash_profile`, or arbitrary sealed `.env` persistence.
- Reserve `HOME`, `PATH`, shell hooks, loader variables, `NODE_OPTIONS`, Python path controls, proxy/TLS/runtime controls, `OPENSHELL_*`, and internal `NEMOCLAW_*`.
- Validate bounded names/values; reject controls/newlines/NUL and case collisions.
- Redact values from logs, support bundles, argv, and errors.
- Do not implicitly mutate PID 1 or replace managed MCP/messaging/inference credential flows.

## Implementation Idea

Add a versioned registry union for ordinary values and provider-placeholder references, carry it through the serializable create intent, materialize it in the startup envelope, and store an applied fingerprint. Rebuild/resume must reproduce it transactionally and fail before deletion if a required provider binding cannot be proven.

For Hermes, prefer an operator startup-environment layer inherited by the managed process instead of appending arbitrary values to sealed `.env`. Verify the exact agent/tool inheritance contract first.

Tests must cover CLI validation, benign value visibility/persistence across rebuild, provider identity/attachment/revision and rollback, secret absence from every persisted/rendered surface, Hermes hash integrity, crash consistency, unset behavior, and backward-compatible registry migration.

## Acceptance Criteria

- A benign value is visible to a Hermes skill and survives rebuild without manual profile/config edits.
- `unset` durably removes it.
- Plaintext credential injection is rejected with provider-backed guidance.
- Provider-backed entries persist only references/placeholders and do not expose raw values in the sandbox.
- Hermes restart/recover retains strict-hash and secret-boundary guarantees.
- `env list` reports names, kind, and applied/pending/drift status without values.
- Rebuild/resume are idempotent and fail before destructive replacement when bindings are unprovable.

## Category

Feature

No open duplicate was found; #4785 and #7003 are related but own different problems.

Contributor guide

Open the contributing guide

Research direction

Start with src/commands/sandbox/ and src/lib/onboard/sandbox-create-launch.ts, then trace the serializable create intent, startup environment assembly, registry persistence, and Hermes sealing checks. Verify the agent/tool inheritance contract before designing the CLI and state flow. Done means the listed acceptance tests pass without plaintext secrets, hash drift, or destructive rebuilds when bindings cannot be proven.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.