CLI sidecar fails to connect: gateway auto-pairing race (upstream)

[jwm4]

Summary

The CLI sidecar in OpenShift deployments fails to start with gateway timeout after 10000ms. The gateway closes the websocket connection (code=4008) before device auto-pairing completes — the same root cause as #119, but affecting the CLI channel rather than the browser.

The browser recovers because it retries and succeeds after the device is approved from the first (failed) attempt. The CLI sidecar does not appear to retry the same way, so it fails permanently.

Observed Behavior

[openclaw] Failed to start CLI: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/node/.openclaw/openclaw.json
Bind: loopback

Gateway logs show the CLI's local loopback connection closing before connect:

[ws] closed before connect conn=350ee0dc... peer=127.0.0.1:54530->127.0.0.1:18789 remote=127.0.0.1 code=1005 reason=n/a

Meanwhile the browser websocket retries and connects successfully ~3s later.

Relationship to #119

Issue #119 documented the same auto-pairing race for browser connections. The fix in b77a588 improved the installer's device approval logic (two-step list-then-approve-by-ID) but did not address the gateway's underlying behavior of closing websockets before auto-approval completes. The browser case was masked by retry behavior, but the CLI sidecar is still affected.

Root Cause

This is likely an upstream OpenClaw gateway issue: the gateway should either complete auto-approval before closing the websocket, or the CLI sidecar should have retry/backoff logic. The installer does not control either of these code paths.

If this isn't picked up upstream soon, we may need a temporary installer-side workaround (e.g., a wrapper script that retries the CLI connection, or a readiness gate).

Environment

• OpenShift (ROSA) with OAuth proxy sidecar
• Namespace: bmurdock-ak1-openclaw
• Branch: bugfix/issue-71-tighten-openclaw-file-permissions (PR fix(security): tighten file permissions on config and state directory #126), but unrelated to permission changes
• Gateway started successfully in 5.2s; webchat UI connected and functioned normally

This issue was filed by Claude Code under the supervision of Bill Murdock.

[jwm4]

Upstream Issue

This is the same root cause as openclaw/openclaw#35763 — loopback connections that should be auto-approved for device pairing are rejected. That issue has been open since March 5 and is marked stale, so we likely need an installer-side workaround.

Workaround Options

Option A: Re-add dangerouslyDisableDeviceAuth: true to openclaw.json (proposed)

The gateway supports this flag — it was intentionally removed in b9abb46 (#119) to use the device pairing flow instead. Since the upstream auto-approval is broken, we can re-add it to the generated openclaw.json for K8s/OpenShift deployments. One-line change in the config generator, easy to revert once upstream fixes openclaw/openclaw#35763.

Security impact is minimal: K8s/OpenShift pods are already behind OAuth proxy + token auth, and loopback connections should have been auto-approved anyway — we're just skipping the broken code path.

Option B: postStart lifecycle hook

Add a Kubernetes lifecycle hook on the gateway container that waits for the gateway to be ready, then approves any pending device pairings:

lifecycle:
  postStart:
    exec:
      command: ["sh", "-c", "sleep 15 && node dist/index.js devices approve --all 2>/dev/null || true"]

Keeps device auth enabled but works around the race. Downside: postStart hooks aren't reliable for timing-sensitive retries — if the sleep is too short it misses the window, too long and the container may not reach Ready in time.

Option C: Pairing-approval sidecar

Add a small sidecar container (same OpenClaw image) that continuously polls for pending device pairings and approves them. Most robust, but adds pod complexity and resource overhead for what should be a temporary workaround.

---

Recommendation: Option A. It's the smallest change, lowest risk, and easiest to revert. The upstream bug is that loopback auto-approval is broken — disabling device auth for in-pod connections just skips the broken path.

This comment was posted by Claude Code under the supervision of Bill Murdock.