Description
The OpenShell sandbox egress proxy at 10.200.0.1:3128 denies all HTTPS CONNECT requests to api.telegram.org (and potentially other endpoints) because it cannot resolve the calling binary's identity. The proxy logs show binary=- for every attempt, regardless of which binary (curl, node) initiates the connection.
Environment
- OpenShell: bundled with openshell-cluster Docker container
- NemoClaw: v0.1.0 (tip of main, commit 3328359)
- OpenClaw: 2026.4.2 (da64a97)
- Platform: macOS (Docker Desktop), k3s inside container
- Sandbox: noel-assistant pod
Steps to Reproduce
- Apply the telegram policy preset via
nemoclaw <sandbox> policy-add telegram
- Verify policy is loaded with telegram endpoint and binaries including
/usr/local/bin/node
- From inside the sandbox pod:
export HTTP_PROXY=http://10.200.0.1:3128
export NODE_EXTRA_CA_CERTS=/tmp/openclaw/openshell-sandbox-ca.crt
curl -s https://api.telegram.org/botTOKEN/getMe
- Also tested with Node.js CONNECT tunnel — same result
Expected Behavior
The proxy should identify the calling binary, match it against the policy's binaries allowlist, and allow the CONNECT tunnel to api.telegram.org:443.
Actual Behavior
Every request is denied:
CONNECT src_addr=10.200.0.1 src_port=37982 proxy_addr=10.200.0.1:3128
dst_host=api.telegram.org dst_port=443
binary=- binary_pid=- ancestors=- cmdline=-
action="deny" engine="opa" policy="-"
reason=failed to resolve peer binary: No ESTABLISHED TCP connection found for port 37982 in /proc/42/net/tcp{,6}
Key fields:
binary=- — proxy cannot identify which binary is connecting- The reason indicates the proxy scans
/proc/42/net/tcp{,6} but the pod's connections are in a different PID/network namespace
What We Tried
- Policy with specific binaries (
/usr/local/bin/node, /usr/local/bin/openclaw) — denied, binary=-
- Policy with wildcard binary (
path: '*') — denied, binary=-
- Policy with
access: full instead of restrictive REST rules — denied, binary=-
- Full container restart to reload proxy — denied, same error
- Testing from both curl and Node.js — both denied with identical log pattern
None worked because the proxy fails at the TCP connection lookup step before it ever reaches binary matching.
Root Cause Analysis
The proxy resolves calling binaries by scanning /proc/<pid>/net/tcp{,6}. However, the pod's network connections are in a different PID/network namespace than the proxy process. The proxy never finds the TCP connection in its own namespace, so it reports binary=- and denies by default.
Impact
- Cannot enable the stock OpenClaw Telegram channel plugin inside the sandbox
- Affects any sandbox-side integration requiring outbound HTTPS where binary resolution fails
- Dashboard visibility lost — Telegram conversations through an external bridge don't appear in the OpenClaw dashboard
Workaround
Using an external bridge on the Mac host (outside the sandbox) to handle Telegram API calls, bypassing the proxy entirely.
Related Issues
Description
The OpenShell sandbox egress proxy at
10.200.0.1:3128denies all HTTPS CONNECT requests toapi.telegram.org(and potentially other endpoints) because it cannot resolve the calling binary's identity. The proxy logs showbinary=-for every attempt, regardless of which binary (curl, node) initiates the connection.Environment
Steps to Reproduce
nemoclaw <sandbox> policy-add telegram/usr/local/bin/nodeExpected Behavior
The proxy should identify the calling binary, match it against the policy's binaries allowlist, and allow the CONNECT tunnel to
api.telegram.org:443.Actual Behavior
Every request is denied:
Key fields:
binary=-— proxy cannot identify which binary is connecting/proc/42/net/tcp{,6}but the pod's connections are in a different PID/network namespaceWhat We Tried
/usr/local/bin/node,/usr/local/bin/openclaw) — denied,binary=-path: '*') — denied,binary=-access: fullinstead of restrictive REST rules — denied,binary=-None worked because the proxy fails at the TCP connection lookup step before it ever reaches binary matching.
Root Cause Analysis
The proxy resolves calling binaries by scanning
/proc/<pid>/net/tcp{,6}. However, the pod's network connections are in a different PID/network namespace than the proxy process. The proxy never finds the TCP connection in its own namespace, so it reportsbinary=-and denies by default.Impact
Workaround
Using an external bridge on the Mac host (outside the sandbox) to handle Telegram API calls, bypassing the proxy entirely.
Related Issues
nodein policy binaries #391 — Telegram proxy blocks due to missingnodein policy binaries (policy fix, different root cause)