Can't connect discord or tg to neemoclaw

[maunakeasky]

Description

macOS Apple Silicon (M4)
Telegram and Discord both fail with "Network request failed"
Policy presets are added but proxy returns 403

• Uses proxy env variable no_proxy == '127.0.0.1,localhost,::1'
• Uses proxy env variable https_proxy == 'http://10.200.0.1:3128'
• Trying 10.200.0.1:3128...
• Connected to 10.200.0.1 (10.200.0.1) port 3128 (#0)
• allocate connect buffer
• Establish HTTP proxy tunnel to discord.com:443

CONNECT discord.com:443 HTTP/1.1
Host: discord.com:443
User-Agent: curl/7.88.1
Proxy-Connection: Keep-Alive

< HTTP/1.1 403 Forbidden
<

• CONNECT tunnel failed, response 403
• Closing connection 0
  curl: (56) CONNECT tunnel failed, response 403

This was from inside the sandbox. The same thing is happening for Telegram — the proxy at 10.200.0.1:3128 is blocking all outbound connections with a 403 even though the policies were added. Include this in your GitHub issue along with the Telegram log errors showing the repeated "Network request failed" messages.

Reproduction Steps

Here's what to include in your GitHub issue:
Steps to reproduce:

Install NemoClaw on macOS (Apple Silicon M4, 24GB unified memory)

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

Complete nemoclaw onboard — select NVIDIA Cloud API with Nemotron 3 Super 120B, accept suggested presets (pypi, npm)
Add Telegram policy:

nemoclaw my-assistant policy-add telegram

Connect to sandbox and configure Telegram channel via openclaw onboard, entering a valid BotFather bot token
Start gateway — Telegram fails with repeated "Network request for 'deleteWebhook' failed!" every 30 seconds
Test network from inside sandbox:

curl -v https://api.telegram.org 2>&1
Result: OpenShell proxy at 10.200.0.1:3128 returns HTTP 403 Forbidden on CONNECT tunnel
Expected: Policy preset should allow outbound HTTPS to Telegram API endpoints
Actual: Proxy blocks all outbound HTTPS with 403 despite policy being applied and confirmed via nemoclaw my-assistant policy-list
Same behavior with Discord — policy-add discord also does not update proxy allowlist
Environment:

macOS, Apple Silicon M4, 24GB unified memory
Docker Desktop (Apple Silicon)
openshell 0.0.11
OpenClaw 2026.3.11
NemoClaw installed via nvidia.com/nemoclaw.sh
Opus 4.6

Environment

Here's the environment section for your GitHub issue:
Environment:

OS: macOS (Apple Silicon M4, 24GB unified memory)
Node.js: v22.22.1
npm: 10.9.4
Docker: Docker Desktop for Mac (Apple Silicon)
OpenShell CLI: 0.0.11
OpenClaw: 2026.3.11
NemoClaw: 0.1.0 (installed via curl -fsSL https://nvidia.com/nemoclaw.sh | bash)
Sandbox image: openshell/sandbox-fr
Inference: NVIDIA Cloud API — nvidia/nemotron-3-super-120b-a12b
Sandbox name: my-assistant (default from onboard wizard)
Shell: zsh
Docker version 29.2.1, build a5c7197

Logs

Checklist

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

[Bilguunzayaa]

Same issue here on Windows 11 / WSL2 (Ubuntu). Docker Desktop 29.2.1, openshell 0.0.11, OpenClaw 2026.3.11. Policy presets (discord, telegram) show as applied via nemoclaw moon policy-list and openshell policy get shows version 5 loaded, but proxy still returns 403 on all outbound HTTPS including npm/pypi

[eddie-schick]

Root cause identified: OPA binary allowlist not populated by preset policies

I'm seeing the same behavior on an NVIDIA DGX Spark (DGX OS 7.4.0, ARM/Grace Blackwell). After deep investigation on the host side, I found the specific mechanism causing the 403s.

The proxy's OPA engine checks two things for every HTTPS CONNECT request:

1. Endpoint match -- does any policy allow the target host? (e.g., api.telegram.org:443)
2. Binary match -- is the calling binary listed in that policy's binaries field?

Preset policies (telegram, discord, slack, outlook, jira, etc.) correctly configure the endpoint allowlist but do not populate the binaries field. The OPA engine treats an empty binaries list as "no binary is allowed," so every request is denied regardless of endpoint match.

Environment: DGX Spark, DGX OS 7.4.0 (Ubuntu-based, kernel 6.17.0), NemoClaw 0.1.0, OpenClaw sandbox

[cortexj]

Cross-Platform Verification, Complete Diagnostic, and Working Workaround

Confirming @eddie-schick's root cause on a third platform. Eddie identified the OPA binary allowlist gap on DGX Spark (ARM/Grace Blackwell). @Bilguunzayaa reported the same on WSL2. I independently reproduced and resolved it on x86_64 Linux (Pop!_OS, RTX 4090, OpenShell 0.0.13) — Telegram and Discord both return 200 Connection Established after applying the fix below.

This is the same defect family documented in #272, #391, #396, #585, #676, and #685. The communication preset templates ship without binaries entries. The upstream fix is tracked in PRs #273, #317, #645, and #677 — none merged as of this writing. The workaround below works immediately on current releases.

---

Root Cause (confirmed via OPA deny logs)

openshell logs my-assistant --since 1m

[openshell_sandbox::proxy] CONNECT action=deny
  binary=/usr/bin/curl dst_host=api.telegram.org dst_port=443 engine=opa
  reason=
    binary '/usr/bin/curl' not allowed in policy 'telegram';
    binary '/usr/bin/curl' not allowed in policy 'telegram_bot'

The proxy matched api.telegram.org:443 to the telegram policy block (endpoint match ✅), but denied the request because the preset has no binaries field — so no executable is authorized to use the endpoint.

Verified with openshell policy get my-assistant --full: every working preset (claude_code, github, nvidia, npm_registry) includes binaries. Every broken preset (telegram, telegram_bot, discord) omits it entirely.

Workaround (immediate, no sandbox recreation)

Step 1 — Pull the currently loaded policy:

openshell policy get <sandbox-name> --full > policy.yaml

Step 2 — Strip the metadata header (first 7 lines) to get pure YAML:

tail -n +8 policy.yaml > fix-policy.yaml

Step 3 — Add a binaries block to each affected preset (telegram, telegram_bot, discord, etc.). Insert this above the endpoints: line in each affected section:

    binaries:
      - path: /usr/local/bin/openclaw
      - path: /usr/local/bin/node
      - path: /usr/bin/node
      - path: /usr/bin/curl

Step 4 — Push and wait for the Rego engine to reload:

openshell policy set <sandbox-name> --policy fix-policy.yaml --wait

Step 5 — Verify from inside the sandbox:

nemoclaw <sandbox-name> connect
curl -sv https://api.telegram.org 2>&1 | head -20

Expected: HTTP/1.1 200 Connection Established. Hot-reload takes effect in under 5 seconds. No sandbox destruction, no re-onboard, no gateway restart.

Verification Results

Preset	Before Fix	After Fix	Policy Version
telegram	❌ 403 Forbidden	✅ 200 Connection Established	v5 (hash: be5d259f4524)
telegram_bot	❌ 403 Forbidden	✅ 200 Connection Established	v5
discord	❌ 403 Forbidden	✅ 200 Connection Established	v7 (hash: d59389360561)

Ref: Policy Schema — binaries field · Policy hot-reload workflow

---

Luis Jordi Sereix Co-Founder & Technical Lead — AI Agent Security & Infrastructure ClawBastion™ · clawbastion.com 2J Tech Ventures LLC · Dallas-Fort Worth, TX

## Cross-Platform Verification, Complete Diagnostic, and Working Workaround

Confirming @eddie-schick's root cause on a third platform. Eddie identified the OPA binary allowlist gap on DGX Spark (ARM/Grace Blackwell). @Bilguunzayaa reported the same on WSL2. I independently reproduced and resolved it on x86_64 Linux (Pop!_OS, RTX 4090, OpenShell 0.0.13) — Telegram and Discord both return 200 Connection Established after applying the fix below.

This is the same defect family documented in #272, #391, #396, #585, #676, and #685. The communication preset templates ship without binaries entries. The upstream fix is tracked in PRs #273, #317, #645, and #677 — none merged as of this writing. The workaround below works immediately on current releases.

---

Root Cause (confirmed via OPA deny logs)

openshell logs my-assistant --since 1m

[openshell_sandbox::proxy] CONNECT action=deny
  binary=/usr/bin/curl dst_host=api.telegram.org dst_port=443 engine=opa
  reason=
    binary '/usr/bin/curl' not allowed in policy 'telegram';
    binary '/usr/bin/curl' not allowed in policy 'telegram_bot'

The proxy matched api.telegram.org:443 to the telegram policy block (endpoint match ✅), but denied the request because the preset has no binaries field — so no executable is authorized to use the endpoint.

Verified with openshell policy get my-assistant --full: every working preset (claude_code, github, nvidia, npm_registry) includes binaries. Every broken preset (telegram, telegram_bot, discord) omits it entirely.

Workaround (immediate, no sandbox recreation)

Step 1 — Pull the currently loaded policy:

openshell policy get <sandbox-name> --full > policy.yaml

Step 2 — Strip the metadata header (first 7 lines) to get pure YAML:

tail -n +8 policy.yaml > fix-policy.yaml

Step 3 — Add a binaries block to each affected preset (telegram, telegram_bot, discord, etc.). Insert this above the endpoints: line in each affected section:

    binaries:
      - path: /usr/local/bin/openclaw
      - path: /usr/local/bin/node
      - path: /usr/bin/node
      - path: /usr/bin/curl

Step 4 — Push and wait for the Rego engine to reload:

openshell policy set <sandbox-name> --policy fix-policy.yaml --wait

Step 5 — Verify from inside the sandbox:

nemoclaw <sandbox-name> connect
curl -sv https://api.telegram.org 2>&1 | head -20

Expected: HTTP/1.1 200 Connection Established. Hot-reload takes effect in under 5 seconds. No sandbox destruction, no re-onboard, no gateway restart.

Verification Results

Preset	Before Fix	After Fix	Policy Version
telegram	❌ 403 Forbidden	✅ 200 Connection Established	v5 (hash: be5d259f4524)
telegram_bot	❌ 403 Forbidden	✅ 200 Connection Established	v5
discord	❌ 403 Forbidden	✅ 200 Connection Established	v7 (hash: d59389360561)

Environment

OS	Pop!_OS 22.04 LTS (x86_64, kernel 6.x)
GPU	NVIDIA RTX 4090 Laptop (16GB VRAM), CUDA 12.8
OpenShell	v0.0.13, fresh nemoclaw onboard
Sandbox	my-assistant, Nemotron 3 Super 120B via NVIDIA Cloud API

Related Issues

Issue	Platform	Same Root Cause?
#272	All	✅ Security report: all presets lack binaries (priority: high)
#391	Ubuntu	✅ Telegram 403, missing /usr/local/bin/node
#396	macOS	✅ Gemini fails — openclaw runs as node via shebang
#585	Linux/Ubuntu	✅ Discord fetch failed despite preset applied
#676	All	✅ Comprehensive: all presets + default policies missing binaries
#685	WSL2	✅ Discord 403 on CONNECT tunnels despite valid policy
#314	DGX Spark	⚠️ Possibly related (inference.local, different path)
#385	DGX Spark	⚠️ Possibly related (L7 POST blocking, different layer)

Ref: Policy Schema — binaries field · [Policy hot-reload workflow](https://docs.nvidia.com/openshell/latest/sandboxes/policies.html)

---

Luis Jordi Sereix
Co-Founder & Technical Lead — AI Agent Security & Infrastructure
ClawBastion™ · Dallas-Fort Worth, TX
[clawbastion.com]

[eddie-schick]

Confirmed working on DGX Spark (ARM/Grace Blackwell, OpenShell 0.0.11). Applied the binaries workaround to the telegram preset, pushed policy v12, got 200 Connection Established immediately. Thanks @cortexj for the detailed write-up — this unblocked Telegram for us after being stuck since March 20.

[dknos]

Confirmed on WSL2 — and found an additional binaries gap for Python-based tools.

The workaround from @cortexj works. Confirmed on WSL2 (Ubuntu, Docker Desktop, OpenShell 0.0.11) for Telegram and Discord after adding node/curl to the binaries list.

Additional issue we hit: Python scripts (image generation, API calls via python3) were also 403ing despite endpoint policies being applied. The sandbox Python binary lives at a non-standard path that isn't covered by the typical /usr/bin/python3 entry.

We had to add these paths to every policy block that Python scripts call through:

    binaries:
      - path: /sandbox/.venv/bin/python3
      - path: /sandbox/.venv/bin/python
      - path: /sandbox/.uv/python/cpython-3.13.12-linux-aarch64-gnu/bin/python3.13

The exact .uv path varies by Python version and arch — you can find yours with:

nemoclaw <sandbox> connect
which python3
ls /sandbox/.uv/python/

Without these entries, python3 script.py that makes HTTPS requests to allowed endpoints still gets 403 at the proxy layer, even though the endpoint is in the allowlist. Same root cause as the node/curl gap.