[Feature]: node run --context-path for reverse-proxied gateways #97678

Summary

Add --context-path flag to openclaw node run and openclaw node install so nodes can connect to gateways behind a reverse proxy with a path prefix.

Problem to solve

When an OpenClaw gateway is exposed through a reverse proxy (nginx, Caddy, Cloudflare Tunnel, etc.), the WebSocket endpoint often lives at a path like wss://gateway.example.com/openclaw-gw rather than at the root. Currently openclaw node run only accepts --host and --port, assembling the URL as ws://host:port with no path component. This makes it impossible for remote nodes to connect to gateways behind path-routed proxies.

Workarounds like host-header routing or dedicated ports add operational complexity and are not always possible in shared proxy environments.

Proposed solution

Add a --context-path option to openclaw node run and openclaw node install:

# Connect to gateway at wss://gateway.example.com:18789/openclaw-gw
openclaw node run --host gateway.example.com --port 18789 --tls --context-path /openclaw-gw

# Connect to gateway at ws://192.168.1.100:18789/gw
openclaw node run --host 192.168.1.100 --port 18789 --context-path /gw

Desired behavior:

• --context-path value is appended directly to the WebSocket URL: ${scheme}://${host}:${port}${contextPath}
• If context path is missing a leading /, one is prepended automatically (e.g. gws becomes /gws)
• If context path is not specified, no path is appended — URL stays ws://host:port (backward compatible)
• The value persists to node.json so subsequent node run without --context-path reuses the last value
• CLI flag takes precedence over the saved config value
• openclaw node install --context-path /gws includes it in the daemon's persisted CLI args so the background service reconnects correctly

Alternatives considered

• Host-header routing / dedicated port: works for some deployments but requires control over DNS and firewall, which is impractical in shared proxy environments.
• SSH tunnel to strip the path: adds another moving piece; harder to secure and monitor.
• Manually patching the WebSocket URL in the source: not a supported workflow.
• Environment variable (OPENCLAW_GATEWAY_CONTEXT_PATH): feasible but inconsistent with how --host and --port are exposed as CLI flags. CLI flags are preferred for daemon install arg persistence.

Impact

• Affected users/systems: Anyone running a node host that connects to a gateway behind a reverse proxy with a non-root path.
• Severity: Blocks node-to-gateway connectivity entirely in path-routed proxy setups.
• Frequency: Always for affected deployments.
• Consequence: Nodes cannot connect; users must either reconfigure their proxy or abandon remote node functionality.

Evidence/examples

Nginx reverse proxy example that would require this:

location /openclaw-gw/ {
    proxy_pass http://localhost:18789/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Cloudflare Tunnel with path-based routing to multiple gateway instances would also require a non-root WebSocket path.

Additional information

• Backward compatible: nodes without --context-path continue to connect at ws://host:port without a path.
• Only the leading / guard is applied; trailing slashes are preserved as-is so users have full control over the URL shape.
• The contextPath is not sent to the gateway server — it is purely a client-side connection parameter for WebSocket URL assembly.
• Related PR: The implementation is ready in branch fix/feishu-dmpolicy-docs... (can be updated per actual PR branch)