test(discord): clarify and guardrail gateway proxy selection#99126
Conversation
…bSocket Discord Gateway WebSocket connections now honor HTTP_PROXY/HTTPS_PROXY environment variables as fallback before direct connection, matching the existing pattern from Discord REST API and WhatsApp. This enables Discord channel deployment in Kubernetes/OpenShift environments with network policy egress restrictions, removing the need for broad :443 egress as a workaround. - Add createEnvProxyDiscordGatewayAgent() helper (mirrors rest-fetch.ts pattern) - Try env proxy before direct HttpsAgent in createDiscordGatewayPlugin() - Explicit channels.discord.proxy still overrides env proxy - Add formatErrorMessage and resolveEnvHttpProxyAgentOptions imports Fixes openclaw#98266
openclaw-barnacle
Bot
added
docs
|
Codex review: needs maintainer review before merge. Reviewed July 2, 2026, 9:17 PM ET / 01:17 UTC. Summary PR surface: Source -23, Tests +290, Docs +1. Total +268 across 6 files. Reproducibility: yes. Source inspection shows current main and Review metrics: 1 noteworthy metric.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the explicit Do we have a high-confidence way to reproduce the issue? Yes. Source inspection shows current main and Is this the best way to solve the issue? Yes, if maintainers accept the trust boundary. The PR keeps Gateway proxying explicit through existing AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 381b44a9fc26. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source -23, Tests +290, Docs +1. Total +268 across 6 files. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
proof: sufficient
0add562 to
ca8e39c
Compare
clawsweeper
Bot
added
rating: 🧂 unranked krab
Signed-off-by: sallyom <[email protected]>
ca8e39c to
e6e3af3
Compare
openclaw-barnacle
Bot
removed
the
triage: needs-pr-context
clawsweeper
Bot
added
rating: 🐚 platinum hermit
|
Pushed commit What changed:
Validation run on the pushed branch state:
Additional pre-push validation on the same file content before applying it to this PR branch:
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
rating: 🐚 platinum hermit
|
Thanks @svuppala2006 for opening this, and congrats on your first OpenClaw contribution. This PR started from the Discord proxy path rejecting documented non-loopback proxy URLs, which meant restricted-egress setups could fail to use the intended proxy. During review, we kept the fix on the explicit The merged change now accepts valid explicit HTTP(S) proxy URLs with a host for Discord REST, webhook, startup REST lookup, and Gateway WebSocket paths. It also keeps Gateway WebSocket direct when only ambient proxy env is set, and updates the tests/docs around that behavior. We validated it with focused Discord proxy tests and live proof: the old behavior reproduced the loopback rejection and direct Discord attempts, while the merged fix connected through the configured DNS proxy with CONNECTs to Thanks again for bringing this in. |
…w#99126) * feat(discord): add HTTP_PROXY/HTTPS_PROXY env fallback for gateway WebSocket Discord Gateway WebSocket connections now honor HTTP_PROXY/HTTPS_PROXY environment variables as fallback before direct connection, matching the existing pattern from Discord REST API and WhatsApp. This enables Discord channel deployment in Kubernetes/OpenShift environments with network policy egress restrictions, removing the need for broad :443 egress as a workaround. - Add createEnvProxyDiscordGatewayAgent() helper (mirrors rest-fetch.ts pattern) - Try env proxy before direct HttpsAgent in createDiscordGatewayPlugin() - Explicit channels.discord.proxy still overrides env proxy - Add formatErrorMessage and resolveEnvHttpProxyAgentOptions imports Fixes openclaw#98266 * test(discord): keep gateway proxy explicit Signed-off-by: sallyom <[email protected]> * fix(discord): allow explicit remote proxy URLs --------- Signed-off-by: sallyom <[email protected]> Co-authored-by: sallyom <[email protected]> Co-authored-by: joshavant <[email protected]>
3 participants
What Problem This Solves
Restricted deployments that need Discord Gateway and Discord REST traffic to leave the Gateway pod through a managed proxy, not through broad direct
:443egress.Current shipped Discord proxy validation only accepts loopback proxy hosts. The docs show examples like:
That example is misleading today. A non-loopback DNS proxy is rejected, and Discord falls back to direct/default transport instead of routing through the configured proxy.
Why This Change Was Made
This PR keeps Discord Gateway proxying explicit. Discord does not silently inherit ambient proxy environment variables for Gateway sessions. Operators still configure
channels.discord.proxy.The change allows a non-loopback Discord proxy URL only when it exactly matches the active process proxy endpoint from
HTTP_PROXY,HTTPS_PROXY, orALL_PROXY. The match uses the normalized full URL, including credentials, default port, and lower/upper-case env precedence. Arbitrary DNS hosts and non-loopback IPs remain rejected.That gives restricted-egress deployments a supported MITM/operator-managed proxy path for Discord without accepting arbitrary remote proxy hosts in Discord config.
User Impact
Users in restricted-egress environments can run Discord through their configured proxy without granting broad Gateway pod
:443egress.Supported path:
with the active process proxy set to the same endpoint, for example:
Loopback proxy configs continue to work. Non-loopback proxy configs that do not match the active process proxy continue to fall back instead of being used for Discord bot-token traffic.
Evidence
Automated Tests
Focused Discord proxy tests passed after the maintainer fix:
Result: 4 files passed, 57 tests passed.
Additional checks:
node scripts/generate-docs-map.mjs --check git diff --check .agents/skills/autoreview/scripts/autoreview --mode localResult: docs map up to date, diff check clean, autoreview clean with no accepted/actionable findings.
Real Behavior Proof From #98272
The original PR, #98272, carried live Discord proof for this behavior before the fork was deleted. That proof used a K8s cluster in namespace
sallyom-claw, Clawhiggins, Discord test serverTest Claws, and botTest.Image under test:
The Discord plugin loaded from the rebuilt OpenClaw image:
{ "source": "/app/dist/extensions/discord/index.js", "origin": "bundled", "status": "loaded" }Gateway logs showed both proxy paths enabled:
Discord channel status showed the bot connected:
{ "channels": { "discord": { "configured": true, "running": true, "lastError": null } }, "channelAccounts": { "discord": [ { "accountId": "default", "running": true, "connected": true, "tokenStatus": "available", "bot": { "username": "Test" } } ] } }The Gateway egress NetworkPolicy had no broad
:443rule. It allowed only the proxy pod on:8080plus DNS:A live Discord REST proof message was posted through the MITM proxy:
{ "proxy": "http://some-proxy:8080", "guild": "Test", "textChannel": "general", "messageCreated": true, "content": "OpenClaw final Discord proxy proof 2026-07-01T23:17:06.190Z" }Discord status then showed inbound Gateway activity:
{ "connected": true, "lastInboundAt": 1782947826282, "lastTransportActivityAt": 1782947816644, "lastError": null }Related
channels.discord.proxy.