Description

After a fresh nemoclaw onboard, running openclaw agent (or nemoclaw sandbox exec <name> -- openclaw agent ...) emits a gateway scope-upgrade error and silently falls back to embedded mode:

gateway connect failed: GatewayClientRequestError: scope upgrade pending approval
EMBEDDED FALLBACK: Gateway agent failed; running embedded agent:
  GatewayTransportError: gateway closed (1008): pairing required:
  device is asking for more scopes than currently approved

The agent falls back to embedded mode and continues to work (exit 0), so the failure is silent to users who only check the exit code. The gateway scope upgrade is never surfaced as an action item.

Reproduces on two freshly-onboarded sandboxes (my-assistant and alpha) on the same host. NVB#6041401 tracked an identical "Pairing required" symptom at v0.0.3, which was closed as Bug-Fixed. This appears to be a regression in v0.0.53 under the same root cause: a new scope is added to the agent's request set but not pre-approved during onboard.

Environment

Device:        KVM VM (10.57.211.27, x86_64)
OS:            Ubuntu 24.04.4 LTS (kernel 6.17.0-23)
Docker:        29.5.2
OpenShell CLI: 0.0.44 (docker)
NemoClaw:      v0.0.53-9-gea10007
OpenClaw:      2026.5.22
Sandboxes:     my-assistant (kimi-k2.6), alpha (nemotron-3-super-120b-a12b)

Steps to Reproduce

1. Fresh onboard:

   NEMOCLAW_NON_INTERACTIVE=1 NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 \
   NVIDIA_API_KEY=<key> nemoclaw onboard --fresh --name my-assistant

2. Confirm sandbox is Ready:

   nemoclaw my-assistant status | grep Phase

3. Run an agent prompt:

   nemoclaw sandbox exec my-assistant --timeout 60 -- \
     openclaw agent --agent main -m "What is 2+2?" --session-id test-$(date +%s)

4. Observe stdout — specifically the gateway connect lines before the answer.

Expected Result

Per the onboard contract (and per NVB#6041401 fix): after a fresh onboard the gateway should have pre-approved the embedded agent's device and scope set. openclaw agent should connect via the gateway directly — no fallback, no scope-upgrade message. Exit 0 with the model response only.

Actual Result

gateway connect failed: GatewayClientRequestError: scope upgrade pending approval
  (requestId: c8906eb6-ca20-401c-9a15-2e9d0593561c)
EMBEDDED FALLBACK: Gateway agent failed; running embedded agent:
  GatewayTransportError: gateway closed (1008): pairing required: device is
  asking for more scopes than currently approved (requestId: c8906eb6-...)
Gateway target: ws://127.0.0.1:18789
...
4   ← model answer via embedded fallback

Exit code 0 (agent succeeds via fallback). The scope-upgrade requestId is printed but no UI is shown to approve it. The same requestId appears across multiple separate invocations — the approval is never automatically resolved.

Reproduced on both my-assistant and alpha sandboxes.

Suggested Fix

The onboard sequence should pre-approve the agent's scope set before the sandbox is handed off as Ready. If a scope upgrade is needed, the onboard wizard (or nemoclaw recover) should run the approval flow so that the first openclaw agent invocation connects via the gateway without fallback.

Alternatively, the embedded fallback should not be silent: if scope-upgrade is pending, surface it to the user with the requestId and instructions (openclaw devices approve <requestId>), rather than transparently falling back and giving the illusion of a gateway-connected session.

See also: NVB#6041401 (v0.0.3 fix) and the approval flow in openclaw devices list / openclaw devices approve.

NVB#6240506