[NemoClaw][All platforms] Discord channel fails with 400 — Node.js EnvHttpProxyAgent uses forward proxy instead of CONNECT tunnel

[zNeill]

Description

Summary

Discord WebSocket gateway connection fails with 400 Bad Request inside the NemoClaw sandbox. The OpenShell proxy correctly supports WebSocket upgrades via CONNECT tunnels (#652), but Node.js's built-in EnvHttpProxyAgent (activated by the HTTPS_PROXY environment variable in the sandbox) sends HTTPS requests using forward proxy mode (GET https://gateway.discord.gg/...) instead of issuing a CONNECT tunnel request. The OpenShell proxy correctly rejects this with 400: Use CONNECT for HTTPS URLs.

Root cause

1. Sandbox sets HTTPS_PROXY=http://10.200.0.1:3128 for all processes
2. Node.js https.get() picks up HTTPS_PROXY and uses EnvHttpProxyAgent
3. EnvHttpProxyAgent sends a forward proxy request (not CONNECT)
4. OpenShell proxy rejects HTTPS forward proxy requests with 400
5. Discord gateway never establishes a WebSocket connection

The proxy's WebSocket upgrade support is working correctly — the issue is on the client side.

Evidence

[discord] failed to deploy native commands: Error (status=403, body={"detail":"PUT ... not permitted by policy","error":"policy_denied"}) [discord] gateway error: Error: getaddrinfo EAI_AGAIN gateway.discord.gg [discord] gateway error: AggregateError [discord] gateway: WebSocket connection closed with code 1006

Manual test from inside sandbox:$ node -e "require('https').get('https://gateway.discord.gg/?v=10&encoding=json', ...)"
STATUS: 400

(Node.js used forward proxy path due to HTTPS_PROXY)

Suggested fix

One or more of:

1. Pre-install ws + https-proxy-agent in the sandbox base image so OpenClaw's Discord client can use a CONNECT-aware WebSocket library
2. Document that WebSocket-based channels require a CONNECT-capable proxy agent and how to configure it in the sandbox
3. OpenClaw upstream: ensure Discord client uses CONNECT tunnel when HTTPS_PROXY is set (e.g. configure discord.js / grammy with an explicit proxy agent)

Environment

• NemoClaw v0.0.7
• OpenShell 0.0.23
• OpenClaw 2026.3.11
• Node.js 22.22.1

Bug Details

Field	Value
Priority	Unprioritized
Action	Dev - Open - To fix
Disposition	Open issue
Module	Machine Learning - NemoClaw
Keyword	NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL

---

[NVB# 6056219]

[NVB#6056219]

[kjw3]

Working plan update: this issue is currently one of the leading explanations for the native Discord regression after the bridge removal.

Important finding from the NemoClaw side: the merged migration validated provider attachment, baked config, REST reachability, and placeholder token rewriting, but it did not validate a real gateway.discord.gg WebSocket session. That left a gap where native Discord could look healthy at merge time while still failing at the gateway path.

Current execution plan:

• add explicit native Discord gateway validation to NemoClaw E2E
• supersede PR fix(presets): add missing binaries to communication presets #1084 with a minimal preset binary fix where justified
• improve diagnostics so REST success and gateway success are reported separately
• keep the native OpenShell/OpenClaw path as the target architecture; no default bridge rollback

Working branch: fix/discord-native-remediation