DNS resolution fails inside sandbox for policy-allowed domains

[shuq-rgb]

Agent Diagnostic

• Investigated DNS resolution inside sandbox
• Ran cat /etc/resolv.conf → points to CoreDNS at 10.43.0.10
• Ran nslookup slack.com → connection refused to 10.43.0.10:53
• Ran curl https://slack.com → fails (can't resolve host)
• Verified CoreDNS pod is running via kubectl exec and responds correctly
• Concluded: sandboxed processes are blocked from reaching the internal DNS server at the network/firewall level

Description

Sandboxed processes cannot resolve any external domain names. The sandbox’s /etc/resolv.conf points to CoreDNS at 10.43.0.10, but the sandbox network rules block access to it on port 53. This means any tool or plugin that needs to connect to an external service (Slack, Telegram, etc.) fails even when policy.yaml allows the domain.

DNS resolution works fine from kubectl exec into the CoreDNS pod, so the server itself is healthy. The block is between the sandboxed process and the DNS server.

Reproduction Steps

1. openshell gateway start
2. openshell sandbox create -- bash
3. Inside sandbox: nslookup slack.com → connection refused
4. Inside sandbox: cat /etc/resolv.conf → shows 10.43.0.10
5. From host: kubectl exec into CoreDNS pod, nslookup slack.com works fine

Environment

• OS: macOS 15.x (Apple Silicon)
• Docker: Docker Desktop 4.x
• OpenShell: latest (installed via curl -fsSL .../install.sh | bash)

Logs

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., debug-openshell-cluster, debug-inference, openshell-cli)
• My agent could not resolve this — the diagnostic above explains why

[johntmyers]

This is currently working as designed. If you're connections are going through the CONNECT proxy, as intended, then the proxy should handle DNS. We know there are some tools that do their own DNS lookups and direct TCP connections but we're starting to see changes around this, for example: openclaw/openclaw#50650

That being said, this issue has been reported multiple times. I am closing it as a duplicate and currently wontfix.