Description

With NemoClaw onboarded in Restricted tier and the npm preset applied via nemoclaw policy-add, running openclaw plugins install @openclaw/microsoft-speech inside the sandbox fails with a fetch failed other side closed error, and the plugin does not appear in openclaw plugins list. This suggests the npm preset does not provide working egress for this registry-based plugin install, or the registry resolution path for OpenClaw plugins is not aligned with the preset.

Component area: Policy&Network / Agent&Skills (plugins / registry access).

Environment

Platforms verified: WSL2 (Ubuntu 22.04 in WSL2 on Windows), DGX Spark, Ubuntu 26.04
openshell:          0.0.39
nemoclaw:           v0.0.48
docker:             29.4.3
node:               v22.22.3
npm:                10.9.8
OpenClaw:           2026.4.24 (cbcfdf6)

Steps to Reproduce

Pre-condition:

• NemoClaw onboarded with Restricted tier (no presets applied initially).
• At least one sandbox is running (e.g., prachi-restricted).

On the host:

# 1. Confirm sandbox and presets
nemoclaw prachi-restricted policy-list

# 2. Apply npm preset
nemoclaw prachi-restricted policy-add
# In the interactive list, select "npm"
# Confirm application

# 3. Connect to the sandbox
nemoclaw prachi-restricted connect

Inside the sandbox shell:

# 4. Attempt to install the Microsoft speech plugin via OpenClaw's plugin manager
openclaw plugins install @openclaw/microsoft-speech 2>&1

# 5. List plugins
openclaw plugins list 2>&1

Expected Result

• npm preset is applied successfully to the sandbox's network policy.
• nemoclaw ... connect succeeds and drops into the sandbox shell.
• openclaw plugins install @openclaw/microsoft-speech succeeds:
  • The command resolves the plugin from the npm registry (or configured plugin registry).
  • No fetch/connection errors are printed.
• openclaw plugins list shows @openclaw/microsoft-speech in the plugin list as installed/loaded (with a non-stock source path), confirming that:
  • The sandbox can reach the registry through the npm preset.
  • The plugin manager correctly installs the plugin.

This test is explicitly meant to validate network policy/egress and registry access behavior for the npm preset via openclaw plugins install, not arbitrary npm CLI behavior.

Actual Result

Inside sandbox:

sandbox@16e7a8836031:~$ openclaw plugins install @openclaw/microsoft-speech 2>&1
...
Resolving clawhubopenclawmicrosoft-speech fetch failed other side closed

The install prints fetch failed other side closed while resolving clawhub/openclaw/microsoft-speech (or equivalent registry path), indicating that the plugin fetch did not succeed.

Immediately afterward:

sandbox@16e7a8836031:~$ openclaw plugins list 2>&1
...
Name        ID                  Format     Status     Source                Version
...
microsoft   microsoft-speech    openclaw   loaded     stockmicrosoft…       2026.4.24
...

The list shows only the stock microsoft speech plugin (stockmicrosoft/index.js), not an installed @openclaw/microsoft-speech plugin from the registry. There is no entry indicating a newly installed plugin from npm or a non-stock source root.

So:

• The npm preset was applied, but the plugin install still fails with a fetch error.
• The plugin is not present in the plugin list, so the install did not succeed.

The failure occurs even though other NemoClaw networking is healthy (NVIDIA Endpoints inference provider, etc.), so it appears specific to the plugin/registry path vs. general connectivity.

Logs

Plugin install output:

sandbox@16e7a8836031:~$ openclaw plugins install @openclaw/microsoft-speech 2>&1
...
UNDICI-EHPA Warning EnvHttpProxyAgent is experimental
...
Resolving clawhubopenclawmicrosoft-speech fetch failed other side closed

Plugin list output (after failed install):

sandbox@16e7a8836031:~$ openclaw plugins list 2>&1
...
Source roots:
  stock:  /usr/local/lib/node_modules/openclaw/dist/extensions
  global: /sandbox/.openclaw/extensions
...
microsoft   microsoft-speech    openclaw   loaded     stockmicrosoftindex.js   2026.4.24
...

No explicit NemoClaw CLI error outside the sandbox — failure is visible only in the plugin install output and the absence of the plugin in plugins list.

Policy list (confirms npm preset is applied):

local-lynnh@2u1g-b650-1386:~$ nemoclaw prachi-restricted policy-list

  Policy presets for sandbox 'prachi-restricted':

    ○ brave            — Brave Search API access
    ○ brew             — Homebrew (Linuxbrew) package manager access
    ○ discord          — Discord API, gateway, and CDN access
    ○ github           — GitHub.com and GitHub API access (git)
    ○ huggingface      — Hugging Face Hub, LFS, and Inference API access
    ○ jira             — Jira and Atlassian Cloud access
    ○ local-inference  — Local inference access (Ollama, vLLM) via host gateway
    ○ nous-audio       — Nous Portal managed audio generation and transcription gateway
    ○ nous-browser     — Nous Portal managed browser automation gateway
    ○ nous-code        — Nous Portal managed sandboxed code execution gateway
    ○ nous-image       — Nous Portal managed image generation gateway
    ○ nous-web         — Nous Portal managed web search and crawl gateway
    ● npm              — npm and Yarn registry access
    ○ outlook          — Microsoft Outlook and Graph API access
    ○ pypi             — Python Package Index (PyPI) access
    ○ slack            — Slack API, Socket Mode, and webhooks access
    ○ telegram         — Telegram Bot API access
    ○ wechat           — WeChat (personal) iLink API access (OpenClaw + Hermes)
    ○ whatsapp         — WhatsApp Web WebSocket and media access

network_policies excerpt (whatsapp section, included from policy dump for context — not directly relevant to this bug):

network_policies:
  whatsapp:
    name: whatsapp
    endpoints:
      # WhatsApp Web Noise-over-WebSocket. The /ws/chat upgrade requires
      # HTTP/1.1; OpenShell's proxy negotiates h2 ALPN by default when it
      # terminates TLS, and Meta's edge returns HTTP/2 405/400 because
      # there is no 101 Switching Protocols flow over h2. OpenShell
      # v0.0.15+ also auto-terminates TLS unconditionally on REST hosts,
      # which would break the Noise handshake even if h1 were negotiated.
      # Declaring the endpoint as a raw L4 CONNECT tunnel (`access: full,
      # tls: skip`) tells the proxy to pass the encrypted bytes through
      # unmodified, so Baileys negotiates h1 ALPN directly with Meta
      # inside TLS and the Noise frames survive untouched. Falls back to
      # numbered nodes (w1.web.whatsapp.com, w2.web.whatsapp.com, ...)
      # when the primary connection drops; the wildcard covers them with
      # the same shape.
      - host: web.whatsapp.com
        port: 443
        access: full
        tls: skip