[All Platforms][Policy&Network] only one managed MCP server can be registered per sandbox; every later mcp add fails to activate its generated policy
- 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
Assessment
This issue has not been assessed yet.