Description
On Ubuntu 24.04 (DGX Spark, aarch64) with nemoclaw v0.0.52, exporting standard HTTP_PROXY / HTTPS_PROXY / NO_PROXY env vars in the shell before running nemoclaw onboard has no effect — the onboard process makes outbound HTTPS connections to NVIDIA / OpenAI endpoints directly, bypassing the proxy. Verified by running a tinyproxy on 127.0.0.1:8888 and observing that the proxy logged zero CONNECT requests during the ~3-minute onboard window. In a real corporate environment without direct egress to the public internet, this would cause onboard to fail with network timeouts even though the user has correctly configured their proxy. Separately, HTTP_PROXY / HTTPS_PROXY / NO_PROXY are not propagated into the sandbox container at all (docker exec env | grep proxy returns empty), so any in-sandbox tool (pip, npm, ollama client, model SDK calls) would also bypass the proxy if direct egress did exist. DevTest case 639398 (folder 1179566 \DevTest\NemoClaw\NemoClaw Test\v0.0.52\manual\cli) is what surfaced this.
Environment
Device: DGX Spark 10.173.104.110
OS: Ubuntu 24.04 LTS
Architecture: aarch64
Node.js: v22.22.3
npm: 10.9.8
Docker: present
OpenShell CLI: 0.0.44 (docker)
NemoClaw: v0.0.52
OpenClaw: 2026.5.22 (a374c3a)
Proxy under test: tinyproxy 1.11.1 on 127.0.0.1:8888
- ConnectPort 443 + 11434 allowed
- Accept-list = 127.0.0.1 only
- Verified working independently: `curl -x http://127.0.0.1:8888 https://api.openai.com/` produced a CONNECT log entry.
Steps to Reproduce
- Install tinyproxy on the host:
sudo apt-get install -y tinyproxy
Configure to listen on 127.0.0.1:8888 with ConnectPort 443 and ConnectPort 11434. Start:
sudo systemctl restart tinyproxy
- Confirm proxy works in isolation:
curl -fsS --max-time 10 -x http://127.0.0.1:8888 https://api.openai.com/ -o /dev/null -w '%{http_code}\n'
Tinyproxy log gains a CONNECT api.openai.com:443 entry.
- With proxy still running, onboard a new sandbox via:
HTTP_PROXY=http://127.0.0.1:8888 HTTPS_PROXY=http://127.0.0.1:8888 \
NO_PROXY='localhost,127.0.0.1,host.openshell.internal,host.docker.internal' \
NEMOCLAW_NON_INTERACTIVE=1 NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 \
NEMOCLAW_PROVIDER=build NVIDIA_API_KEY=<key> NEMOCLAW_PROVIDER_KEY=<key> \
nemoclaw onboard --non-interactive --yes --no-gpu --name proxy-test
- After onboard reaches "OpenClaw is ready", inspect
/var/log/tinyproxy/tinyproxy.log for CONNECT entries to integrate.api.nvidia.com:443 (the endpoint NVIDIA-prod onboarding hits).
- Run
docker exec openshell-proxy-test-<uuid> env | grep -i proxy to check whether proxy env vars made it into the sandbox container.
Expected Result
After the onboard completes:
- tinyproxy log should contain CONNECT entries for
integrate.api.nvidia.com:443 (or whichever endpoint the onboard called) — proving the proxy was used.
- The sandbox container should have
HTTP_PROXY / HTTPS_PROXY / NO_PROXY set, so in-sandbox tools can reach the corporate internet via the user's proxy.
This is what every other Node.js-based CLI does by default via libcurl / undici's EnvHttpProxyAgent.
Actual Result
- Onboard reached "OpenClaw is ready" / "Deployment verified" without errors.
- tinyproxy log between the start and end of the onboard window:
[07:32:11 ... CONNECT count over next 7 minutes = 0]. The proxy logged exactly two CONNECT entries during the entire test — both from the standalone curl -x validation in step 2 above (timestamps 07:32:07 and 07:32:09). The onboard itself produced zero CONNECT entries.
docker exec openshell-proxy-test-3bcc5def env | grep -i proxy returned empty — no HTTP_PROXY, no HTTPS_PROXY, no NO_PROXY inside the sandbox process environment.
Conclusion: nemoclaw onboard on Linux ignores HTTP_PROXY / HTTPS_PROXY entirely (silently bypassing the user's configured proxy and relying on direct egress) and does not propagate proxy env vars into the sandbox container.
Logs
tinyproxy log excerpt around the onboard window (note no CONNECT entries between 07:32:11 and 07:39:08):
NOTICE May 27 07:32:05 [609356]: Initializing tinyproxy ...
INFO May 27 07:32:05 [609356]: Adding Port [443] to the list allowed by CONNECT
INFO May 27 07:32:05 [609356]: Adding Port [11434] to the list allowed by CONNECT
INFO May 27 07:32:05 [609356]: Starting main loop. Accepting connections.
CONNECT May 27 07:32:07 [609356]: Request: CONNECT api.openai.com:443 HTTP/1.1 ← standalone curl test
CONNECT May 27 07:32:09 [609356]: Request: CONNECT integrate.api.nvidia.com:443 HTTP/1.1 ← standalone curl test
INFO May 27 07:32:11 [609356]: Closed connection between local client (fd:5) and remote client (fd:6)
← nemoclaw onboard ran during this window
NOTICE May 27 07:39:08 [609356]: Shutting down.
$ docker exec openshell-proxy-test-3bcc5def-e633-4a2c-b563-87c86cdfbcf3 env | grep -i -E 'http_proxy|https_proxy|no_proxy'
(no output — proxy env vars not propagated into sandbox)
NVB#6228791
Description
On Ubuntu 24.04 (DGX Spark, aarch64) with nemoclaw v0.0.52, exporting standard
HTTP_PROXY/HTTPS_PROXY/NO_PROXYenv vars in the shell before runningnemoclaw onboardhas no effect — the onboard process makes outbound HTTPS connections to NVIDIA / OpenAI endpoints directly, bypassing the proxy. Verified by running a tinyproxy on127.0.0.1:8888and observing that the proxy logged zero CONNECT requests during the ~3-minute onboard window. In a real corporate environment without direct egress to the public internet, this would cause onboard to fail with network timeouts even though the user has correctly configured their proxy. Separately,HTTP_PROXY/HTTPS_PROXY/NO_PROXYare not propagated into the sandbox container at all (docker exec env | grep proxyreturns empty), so any in-sandbox tool (pip, npm, ollama client, model SDK calls) would also bypass the proxy if direct egress did exist. DevTest case 639398 (folder 1179566\DevTest\NemoClaw\NemoClaw Test\v0.0.52\manual\cli) is what surfaced this.Environment
Steps to Reproduce
127.0.0.1:8888withConnectPort 443andConnectPort 11434. Start:curl -fsS --max-time 10 -x http://127.0.0.1:8888 https://api.openai.com/ -o /dev/null -w '%{http_code}\n'CONNECT api.openai.com:443entry./var/log/tinyproxy/tinyproxy.logfor CONNECT entries tointegrate.api.nvidia.com:443(the endpoint NVIDIA-prod onboarding hits).docker exec openshell-proxy-test-<uuid> env | grep -i proxyto check whether proxy env vars made it into the sandbox container.Expected Result
After the onboard completes:
integrate.api.nvidia.com:443(or whichever endpoint the onboard called) — proving the proxy was used.HTTP_PROXY/HTTPS_PROXY/NO_PROXYset, so in-sandbox tools can reach the corporate internet via the user's proxy.This is what every other Node.js-based CLI does by default via libcurl / undici's
EnvHttpProxyAgent.Actual Result
[07:32:11 ... CONNECT count over next 7 minutes = 0]. The proxy logged exactly two CONNECT entries during the entire test — both from the standalonecurl -xvalidation in step 2 above (timestamps 07:32:07 and 07:32:09). The onboard itself produced zero CONNECT entries.docker exec openshell-proxy-test-3bcc5def env | grep -i proxyreturned empty — noHTTP_PROXY, noHTTPS_PROXY, noNO_PROXYinside the sandbox process environment.Conclusion:
nemoclaw onboardon Linux ignoresHTTP_PROXY/HTTPS_PROXYentirely (silently bypassing the user's configured proxy and relying on direct egress) and does not propagate proxy env vars into the sandbox container.Logs
NVB#6228791