NODES.md advertised dev's CDP on 9460, but the fleet-facing path is the
relay netvm-cdp-relay.py 10.201.36.2:9455 -> 127.0.0.1:9455, and
netvm-names.sh never pinned dev (hash default = 9455). The watchdog kept
relaunching dev's browser on 9460 while the relay sat orphaned on 9455.
- NODES.md: dev cdp_port 9460 -> 9455 (registry is the watchdog's source)
- bin/netvm-names.sh: pin def=9450, dev=9455 (was hash-default only)
Reported by 646 as xop-e09 partition; verified hop-by-hop before fix.
Session: sidechat/dev-cdp-partition
netvm-node-up.sh was starting the CDP relay with the hash-derived
CDP_PORT while cdp-relay-watchdog.sh pinned muse->9410, pip->9420,
646->9430, opm->9440. Since netvm-chrome.sh calls netvm-node-up.sh
on every browser relaunch, each restart spawned a wrong-port zombie
relay (9353, 10355, 10239...).
The pinning now lives in netvm_names() itself, making it the single
source of truth for all consumers (node-up, chrome, cdp, accounts,
watchdog). CDP_PORT_OVERRIDE still takes precedence for future nodes.
Session: sidechat/chromebox-ops
One command provisions a full client node: Warp identity (operator-
authorized 2026-10-03), netns + tunnel, chrome-box profile, NODES.md
registry entry with next-free 94x0 CDP port. Idempotent per stage.
netvm-names.sh gains CDP_PORT_OVERRIDE (backwards compatible) so the
CDP relay and the browser share the assigned port.
operator-main