[DGX Station][All platforms] Port 8080 conflict can stall onboarding and lacks warning contrast

[sandl99]

Agent Diagnostic

• Loaded the NemoClaw maintainer policy and triage skills.
• Reviewed the manual DGX Station VDR 5 retest from VDR 5 checklist: DGX Station & DGX Spark golden path #6743.
• Searched open and closed issues and pull requests for the exact output, the confirmation-to-hang sequence, and related port-conflict reports. No exact duplicate was found.
• Inspected v0.0.81 source. OpenShell gateway inspection still runs before the gateway-port availability check, and the eventual conflict block is printed with unstyled console.error calls rather than the shared terminal severity renderer.

Description

An occupied OpenShell gateway port exposes two problems in the nemoclaw onboard preflight path:

1. The failure heading and explanation render as plain white text instead of using the existing warning/error visual style:

     !! Port 8080 is not available.
        OpenShell gateway needs this port.
   

2. In the interactive path, after the user explicitly accepts Continue with onboarding? [y/N], onboarding can print the OpenShell version and then stop making progress indefinitely while port 8080 remains owned by an unrelated listener:

     Continue with onboarding? [y/N]: y
     ✓ openshell CLI: openshell 0.0.72
     <no further output>
   

Current source ordering is consistent with the stall: OpenShell installation/version reporting and getGatewayReuseSnapshot() occur before checkPortAvailable() evaluates the required gateway port. The snapshot invokes openshell status and openshell gateway info without a per-call timeout. A foreign listener that accepts a connection but does not speak the OpenShell protocol can therefore block gateway inspection before the intended port-conflict diagnostic is reached. The exact blocked OpenShell call still needs instrumentation.

Related VDR tracker: #6743.

Reproduction Steps

1. Identify the current listener on port 8080:

   lsof -nP -iTCP:8080 -sTCP:LISTEN

2. If an existing OpenShell gateway owns the port, stop it using the PID shown:

   kill <PID>

3. Start an unrelated process that accepts connections on port 8080 but sends no protocol response:

   python3 -c 'import socket,time;s=socket.socket();s.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1);s.bind(("127.0.0.1",8080));s.listen();time.sleep(86400)' &
   HOLDER_PID=$!

4. Confirm the port is occupied:

   lsof -nP -iTCP:8080 -sTCP:LISTEN

5. Run onboarding:

   nemoclaw onboard

6. If Continue with onboarding? [y/N] appears, enter y.

7. Observe that onboarding can stop after the OpenShell CLI version line instead of promptly reporting the port conflict. In runs that reach the conflict diagnostic, observe that the !! Port 8080... block has no warning color.

8. Clean up the temporary listener:

   kill "$HOLDER_PID"

Installer-path variant:

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Expected Behavior

• The port-conflict heading and explanation use the shared warning/error terminal style, including warning color on a color-capable terminal and clean output with NO_COLOR or redirected stderr.
• Onboarding detects an unrelated listener before issuing OpenShell gateway commands that can block on that port, or those commands have a bounded timeout.
• The command exits nonzero promptly, identifies the conflicting process/PID when available, and shows the NEMOCLAW_GATEWAY_PORT=<port> alternative.
• Direct onboarding and the supported installer path do not hang.

Actual Behavior

• The port-conflict heading and service explanation render as plain white text.
• With the silent Python listener holding port 8080, onboarding can hang after ✓ openshell CLI: openshell 0.0.72 and never reach the intended remediation output.

Environment

• Context: DGX Station VDR 5 manual retest
• OpenShell: 0.0.72
• NemoClaw: the VDR tracker names v0.0.67 as its validation target; the exact nemoclaw --version output was not captured in the supplied transcript
• Current-source check: the relevant ordering and unstyled output are also present in tag v0.0.81
• OS, Node.js, and Docker versions: not captured

Debug Output

  !! Port 8080 is not available.
     OpenShell gateway needs this port.

  Continue with onboarding? [y/N]: y
  ✓ openshell CLI: openshell 0.0.72
  <no further output>

Logs

No debug archive was collected. The deterministic listener command and lsof checks above reproduce the precondition without credentials.

Detection Gap and Acceptance Criteria

Earlier preflight presentation work in #6004 introduced shared severity renderers, but the port-conflict block remained on raw console.error. Existing port-conflict checks cover friendly failure text and forbidden side effects, while reuse tests focus on healthy or stale NemoClaw-owned gateways; they did not catch this interactive foreign-listener sequence or the terminal-style regression.

• Add a regression test with a silent foreign listener on the configured gateway port and assert a bounded, nonzero failure rather than a hang.
• Assert that OpenShell gateway inspection cannot run indefinitely before the required-port check.
• Assert the port-conflict heading uses the shared warning/error presentation on a color-capable TTY and emits no raw ANSI escapes with NO_COLOR or redirected stderr.
• Preserve the current PID/remediation and alternate-port guidance.
• Preserve healthy NemoClaw-owned gateway reuse.

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate