NVIDIA / NVIDIA/NemoClaw

[All Platforms][Policy&Network] only one managed MCP server can be registered per sandbox; every later mcp add fails to activate its generated policy

Open
#11,895 3 comments 0 reactions 1 assignee Claimed by @deepujain View on GitHub
needs: triage NV QA UAT
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 1h
Merged PRs (30d)
715

Description

> [!NOTE]
> **Re-verified reopening of #11798** — closed via #11863 ("fix(policy): allow full
> activation wait"), whose merge commit is confirmed an ancestor of `v0.0.126`
> (`compare` against the tag reports `behind_by: 0`). Re-verification on `v0.0.126`
> today still reproduces the original symptom, unchanged and deterministically. The
> evidence from that run is below.

## Description

A sandbox can hold only one managed MCP server. The first `nemoclaw {sandbox} mcp add`
succeeds, but a subsequent add of a differently-named server with a distinct credential
key fails while activating its generated policy, and the server is not registered. The
failure is deterministic and repeats on retry.

This makes the documented multi-server workflow unusable: `mcp add` advertises no
per-sandbox limit of one, and the product separately documents a maximum of 64 managed
MCP servers per sandbox, which cannot be approached because the second registration
already fails.

**Platform scope:** re-verified on DGX Spark (Ubuntu 24.04, aarch64). The original report
also covered Ubuntu 22.04 x86_64, so it is not platform-specific.
**Regression:** the fix for this issue shipped and is present in the tested build, but the
behaviour is unchanged.
**OpenShell issue:** No — the failing command is NemoClaw's own `mcp add`. The gateway
stays up and answers, and the first server's policy activates normally through the same
path.

## Environment

```text
Device: NVIDIA DGX Spark
OS: Ubuntu 24.04.4 LTS
Architecture: aarch64
OpenShell CLI: openshell 0.0.116
NemoClaw: nemoclaw v0.0.126
```

## Steps to Reproduce

```bash
# 1. Onboard a fresh OpenClaw sandbox and confirm it reaches Ready.
nemoclaw onboard --fresh --name {sandbox} --non-interactive --yes

# 2. Export two distinct host credential variables.
export AAA_TOK=... BBB_TOK=...

# 3. Register the first server.
nemoclaw {sandbox} mcp add alpha --url {mcp url} --env AAA_TOK --no-probe

# 4. Register a second server, different name and different credential key.
nemoclaw {sandbox} mcp add beta --url {mcp url} --env BBB_TOK --no-probe

# 5. List the registered servers.
nemoclaw {sandbox} mcp list

# 6. Repeat step 4 after a short wait, to show the failure is not transient.
nemoclaw {sandbox} mcp add beta --url {mcp url} --env BBB_TOK --no-probe
```

## Expected Result

Both servers register. `mcp list` shows alpha and beta, each with its own policy,
provider and credential key.

## Actual Result

```text
onboard exit 0, phase Ready
mcp add alpha exit 0
Applied preset: mcp-bridge-alpha
MCP server 'alpha' added to sandbox '{sandbox}'.
mcp add beta exit 1
Could not confirm the policy update for sandbox '{sandbox}':
OpenShell did not confirm the policy submission. The current live
policy differs from the requested document; the update remains
unconfirmed.
Failed to activate generated MCP policy 'mcp-bridge-beta'.
mcp list exit 0, shows only:
alpha policy provider env: AAA_TOK
mcp add beta (retry) exit 1, byte-identical output
```

The second server never appears in `mcp list`, and the retry after a wait produces the
same two messages, so the failure is deterministic rather than a timing artifact — which
is the part the "allow full activation wait" change would have been expected to address.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.