[Brev Launchable] Brev launchable installs stale NemoClaw v0.0.71 — missing gateway device-pairing fixes, OpenClaw dashboard stalls with "device is not approved yet" (chat 2-3 min)

[hulynn]

Description

The Brev NemoClaw/OpenClaw launchable installs NemoClaw v0.0.71 (OpenShell 0.0.71) out of the box. v0.0.71 predates the gateway device-pairing / scope-approval fixes, so as soon as a user opens the OpenClaw dashboard TUI its WebSocket to the gateway (port 18789) is rejected with 1008 pairing required: device is not approved yet and enters a ~3s reconnect loop. The dashboard never holds a stable session, so chat replies take 2-3 minutes. Upgrading the launchable to a build that contains the pairing fixes (v0.0.76+) is expected to resolve it; the launchable image needs to be refreshed off the stale v0.0.71.

Platform scope: Reproduced on the Brev launchable (NemoClaw v0.0.71) only. The underlying device-pairing defect is already fixed on v0.0.76 (verified on other platforms), so this bug is specifically that the Brev launchable still installs the older v0.0.71 that lacks those fixes.

Regression: No — packaging/version-lag issue. The underlying pairing defect is fixed in v0.0.76 (#6291, #6113), but the Brev launchable still installs v0.0.71 which predates those fixes.

Environment

Device:        Brev launchable (NemoClaw/OpenClaw instance)
OS:            Ubuntu 22.04.5 LTS
Architecture:  x86_64
Node.js:       v22.23.1
npm:           10.9.8
Docker:        29.1.3
OpenShell CLI: 0.0.71
NemoClaw:      v0.0.71
OpenClaw:      Not captured (dashboard TUI running; version not retrieved)

Steps to Reproduce

1. Launch the Brev NemoClaw/OpenClaw launchable (it installs NemoClaw v0.0.71 / OpenShell 0.0.71).
2. Confirm the version: nemoclaw --version (→ v0.0.71).
3. Open the OpenClaw dashboard TUI and start a chat in the Main Session.
4. Send a few messages and watch reply latency; tail the gateway log (nemoclaw {sandbox} logs, or the gateway-persistent.log).

Expected Result

The Brev launchable should install a NemoClaw build that contains the gateway device-pairing fixes (v0.0.76+), so the dashboard WebSocket connects on first open, no "device is not approved yet" loop appears, and chat replies return promptly.

Actual Result

On the v0.0.71 launchable the dashboard TUI is very slow (chat replies take 2-3 minutes). The gateway log shows the dashboard WebSocket to port 18789 in a ~3s reconnect loop, rejected as an unapproved device:

[ws] closed before connect conn=... peer={sandbox-ip}:60226->{sandbox-ip}:18789 ... code=1008 reason=connect failed
[ws] closed before connect conn=... peer={sandbox-ip}:33892->{sandbox-ip}:18789 ... code=1008 reason=connect failed
[ws] closed before connect conn=... peer={sandbox-ip}:55142->{sandbox-ip}:18789 ... code=1008 reason=pairing required: device is not approved yet (requestId: {id}...)
[sandbox] [WARN ] [openshell_supervisor_process::ssh] data on unknown channel ChannelId(1374)
[sandbox] [WARN ] [openshell_supervisor_process::ssh] channel_eof on unknown channel ChannelId(1374)

The "device is not approved yet" rejection is the same gateway pairing / scope-approval failure family fixed in v0.0.76 (agent path: #6291 / #4504; gateway auto-pair: #6113), here on the dashboard TUI WebSocket path because the launchable ships the pre-fix v0.0.71.

Logs

[ws] closed before connect conn={id} peer={sandbox-ip}:60226->{sandbox-ip}:18789 remote={sandbox-ip} host={sandbox-ip}:18789 code=1008 reason=connect failed
[ws] closed before connect conn={id} peer={sandbox-ip}:33892->{sandbox-ip}:18789 remote={sandbox-ip} host={sandbox-ip}:18789 code=1008 reason=connect failed
[ws] closed before connect conn={id} peer={sandbox-ip}:55142->{sandbox-ip}:18789 remote={sandbox-ip} host={sandbox-ip}:18789 code=1008 reason=pairing required: device is not approved yet (requestId: {id})
[ws] closed before connect conn={id} peer={sandbox-ip}:55156->{sandbox-ip}:18789 code=1008 reason=connect failed
[sandbox] [WARN ] [openshell_supervisor_process::ssh] data on unknown channel ChannelId(1374)
[sandbox] [WARN ] [openshell_supervisor_process::ssh] channel_eof on unknown channel ChannelId(1374)
(loop repeats every ~3s)

[Hokonoken]

Confirmed your diagnosis and traced where the version pin actually lives — the good news is the repo side is already current, so this is a Brev-launchable config bump rather than a code change.

The pairing fixes are in v0.0.76 (verified)

• fix(openclaw): restore local CLI pairing path #6291 → first tag v0.0.75
• [All Platforms][Agent&Skills] gateway auto-pair fails — agent tools rejected with 'device is not approved yet' #6113 → first tag v0.0.76

So any NemoClaw build ≥ v0.0.76 carries the dashboard/gateway auto-pair fixes; v0.0.71 predates both, which matches the 1008 pairing required: device is not approved yet loop you captured.

Where v0.0.71 comes from

The launchable runs scripts/brev-launchable-ci-cpu.sh. On current main, that script already defaults to fresh versions:

• NEMOCLAW_REF="${NEMOCLAW_REF:-main}" (line 45) — clones NemoClaw at main
• OPENSHELL_VERSION default v0.0.72 (stable|auto branch)

So a launchable pointed at a current ref would install NemoClaw main (has #6291/#6113) + OpenShell 0.0.72 — not v0.0.71. Your instance getting v0.0.71 for both means the Brev launchable is configured to fetch/run this startup script at the v0.0.71 git ref (the one-liner is curl -fsSL .../NemoClaw/<ref>/scripts/brev-launchable-ci-cpu.sh | bash, and the older script defaulted its versions to v0.0.71), rather than at main / a v0.0.76+ tag.

The fix

This is a packaging/ops change on the Brev launchable definition itself (the <ref> it curls the startup script from, plus any pinned NEMOCLAW_REF/OPENSHELL_VERSION it passes), owned by whoever manages the NVIDIA Brev launchable — the repo code doesn't need to change. Bumping that ref to main or a v0.0.76+ tag installs the pairing-fixed build and clears the dashboard WebSocket loop.

Worth double-checking whether the launchable also pins OpenShell explicitly; if it does, set it to a release that pairs with the NemoClaw build (0.0.72+ is current per #6020).

[jyaunches]

Closing as fixed elsewhere. The underlying gateway pairing fixes are already present in v0.0.76+; the remaining action is the Brev launchable configuration/ref update rather than a NemoClaw code issue tracked here.

[cv]

July 10 SWQA reconciliation: the NemoClaw-side diagnosis is complete, but the remaining Brev launchable ref/config update and a QA retest are not linked here.

Keeping the code issue closed, but please attach the external launchable change/tracker and validation result before treating this blocker as operationally shipped. Until then, the v0.0.80 status should distinguish “no NemoClaw code change needed” from “launchable update verified.”

[Hokonoken]

Thanks for the update, i will Keep this advice.
I will do.