#3136·NemoClaw

[NemoClaw][MacOS] macOS: host.docker.internal does not resolve inside k3s pods

Author: zNeillCreated May 6, 2026Updated Sep 18, 2026
Labelsplatform: macosNV QAplatform: containerplatform: k3s
## Description

Description

When using NemoClaw on macOS with Docker Desktop, configuring an Ollama provider with `--base-url http://host.docker.internal:11434` fails because the sandbox resolves `host.docker.internal` to `192.168.5.2` (OpenShell's internal gateway IP), not the actual macOS host. The Docker Desktop gateway IP (`192.168.65.254`) is also unreachable from the sandbox due to network isolation. However, `host.docker.internal` resolves correctly at the Docker container level (outside k3s).

Environment

OS: macOS (Darwin 25.3.0)

Docker Desktop: with k3s

NemoClaw: v0.0.35

OpenShell Cluster: v0.0.36

Ollama: running on host (bound to 0.0.0.0), model qwen2.5:7b

Steps to Reproduce

1. Ensure Ollama is running on macOS host, bound to 0.0.0.0:11434. 2. Create an OpenShell provider with `host.docker.internal`: openshell provider create --name ollama-hdi --type generic --credential DUMMY=dummy --config base_url=http://host.docker.internal:11434 3. SSH into the sandbox: ssh openshell-cdf (via openshell ssh-proxy) 4. Attempt to reach Ollama from inside the sandbox: curl http://host.docker.internal:11434/api/tags 5. Sandbox proxy intercepts the request (403 Forbidden). Bypass proxy: no_proxy=host.docker.internal curl http://host.docker.internal:11434/api/tags 6. Connection refused — resolves to 192.168.5.2:11434 which has no Ollama listening. 7. Try Docker Desktop gateway IP as fallback: no_proxy=192.168.65.254 curl http://192.168.65.254:11434/api/tags 8. Also connection refused — sandbox network cannot reach Docker Desktop gateway.

Logs

# DNS resolution inside sandbox
$ getent hosts host.docker.internal
192.168.5.2     host.docker.internal host.openshell.internal

# Direct access (bypassing proxy) — connection refused
$ no_proxy=host.docker.internal curl -v http://host.docker.internal:11434/api/tags
* Trying 192.168.5.2:11434...
* connect to 192.168.5.2 port 11434 failed: Connection refused

# Docker Desktop gateway IP — also refused
$ no_proxy=192.168.65.254 curl -v http://192.168.65.254:11434/api/tags
* Trying 192.168.65.254:11434...
* connect to 192.168.65.254 port 11434 failed: Connection refused

# But from Docker container level (outside k3s) — WORKS
$ docker exec openshell-cluster-nemoclaw wget -qO- http://host.docker.internal:11434/api/tags
{"models":[{"name":"qwen2.5:7b",...}]}

Analysis

host.docker.internal inside the k3s sandbox resolves to 192.168.5.2, which is OpenShell's internal gateway — not the Docker Desktop host mapping. The sandbox's k3s network is fully isolated from Docker Desktop's host networking layer:

- Docker container level: host.docker.internal -> macOS host (works)
- k3s sandbox level: host.docker.internal -> 192.168.5.2 (OpenShell gateway, no port forwarding)

The proxy inside the sandbox (http_proxy=http://10.200.0.1:3128) also blocks direct access with 403 unless bypassed via no_proxy, but even bypassing it does not help since the resolved IP is wrong.

The issue requires OpenShell to either:
1. Forward host.docker.internal traffic from k3s pods to the actual Docker Desktop host mapping, or
2. Provide a dedicated mechanism for sandbox pods to access host services.

Expected Behavior

Inference requests from sandbox to host.docker.internal:11434 should reach the macOS host Ollama service and return valid responses. ## Bug Details | Field | Value | |-------|-------| | Priority | Unprioritized | | Action | Dev - Open - To fix | | Disposition | Open issue | | Module | Machine Learning - NemoClaw | | Keyword | NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL, NemoClaw_Inference | --- [NVB#6152097]