Summary

When connecting from inside a NemoClaw sandbox to a service running on the host, the Docker bridge path (host.docker.internal resolving to 172.17.0.1) works reliably — but this isn't documented anywhere. We spent real debugging time trying the proxy endpoint path and hitting 403 before discovering the bridge works clean.

Recommendation: Add a section to the NemoClaw docs (sandbox networking or getting-started) showing how to reach host services from inside a sandbox using the Docker bridge.

Concrete example

Connecting to a host-side memory API on port 50001 from inside the sandbox:

# This works — direct over Docker bridge, bypasses the proxy
curl -s http://host.docker.internal:50001/health
# Returns: {"status": "ok", "entries": 437}

We verified a full round-trip (write + read) from inside the sparks-nemo sandbox to Mnemo Cortex running on the host at port 50001. Latency is ~86ms. Works for any HTTP service bound to the Docker bridge interface.

What to document

• host.docker.internal resolves to 172.17.0.1 inside the sandbox (Docker's standard host gateway)
• Traffic over this path goes direct to the Docker bridge, not through the openshell enforcement proxy
• No openshell policy set configuration is needed for this path
• The host needs a UFW rule allowing the Docker bridge subnet (e.g., 172.16.0.0/12) on the target port

Possible proxy bug?

Our original issue was that the proxy path returned HTTP 403 when trying to reach host.docker.internal:50001:

> GET http://host.docker.internal:50001/health HTTP/1.1
< HTTP/1.1 403 Forbidden

We had a network policy configured with openshell policy set allowing this endpoint. The proxy still blocked it. All built-in presets use port: 443 with tls: terminate — there's no example of a non-TLS internal endpoint in any preset or doc.

We're not blocked — the Docker bridge workaround is clean and we're using it in production. But we wanted to flag this for the maintainers:

• Is the proxy expected to support non-TLS host-port access? If yes, the 403 may be a policy enforcement bug worth a separate issue.
• If no (proxy is TLS-only by design), then the docs fix alone is the right outcome, and it would save future users the debugging time we spent.

Environment

• NemoClaw 0.1.0 (official installer)
• OpenClaw 2026.4.11
• OpenShell sandbox: sparks-nemo (Landlock + seccomp + netns)
• Host: Ubuntu, AMD Threadripper 3970X
• OpenShell cluster image: 0.0.10

Thank you for a great product. Happy to provide logs or repro steps if helpful.