NemoClaw-managed sandboxes are Kubernetes Sandbox custom resources (agents.x-k8s.io/v1alpha1). Their pod template includes a hostAliases array for injecting /etc/hosts entries into the sandbox container. When an operator needs to reach a LAN-only hostname, for example a self-hosted SearXNG at searxng.local, the supported NemoClaw and OpenShell CLIs offer no surface for editing this list. The only working path is:

docker exec openshell-cluster-nemoclaw kubectl -n openshell patch sandbox my-assistant \
  --type=json \
  -p='[{"op":"add","path":"/spec/podTemplate/spec/hostAliases/-",
        "value":{"ip":"192.168.1.105","hostnames":["searxng.local"]}}]'

This goes through three layers the docs discourage operators from touching: (1) docker exec into the k3s container, (2) kubectl against the in-container API server, (3) JSON patch on the Sandbox CR.

Environment

• NemoClaw v0.0.17, OpenShell v0.0.26
• Sandbox: my-assistant on DietPi2 (x86_64, 64GB, MicroK8s)
• Use case: allow the built-in web_search tool to reach a LAN-only searxng.local:8080 instance

Expected behaviour

A first-class CLI for host aliases:

nemoclaw my-assistant hosts-add searxng.local 192.168.1.105
nemoclaw my-assistant hosts-list
nemoclaw my-assistant hosts-remove searxng.local

Validation: well-formed IP, well-formed hostname, no duplicate hostnames, optional --dry-run showing the diff.

Actual behaviour

No hosts-add / hosts-list / hosts-remove in either nemoclaw or openshell. Operators must drop to docker exec + kubectl patch.

Impact

• Infrastructure-as-Code of NemoClaw sandboxes has no supported path for deployments that need LAN-only hostnames.
• Operators must understand the Sandbox CR structure (spec.podTemplate.spec.hostAliases) to produce a valid patch; a mistake in the JSON path returns a generic "request is invalid" error from the API server.
• Conflicts with the project's own docs, which discourage kubectl on NemoClaw-managed sandboxes.

Suggested fix

Add nemoclaw <name> hosts-add <host> <ip>, hosts-list, hosts-remove <host>, with --dry-run. Same shape as the policy-add family.

Companion issue

Same pattern, different axis: #2039 (nemoclaw policy-add has no custom-preset surface). Where #2039 documents the policy-side gap (custom egress targets cannot be added via policy-add), this issue documents the DNS-side gap (custom host aliases cannot be added at all through the supported CLI).

Notes

Discovered on 2026-04-17 while rewiring SearXNG egress on the my-assistant sandbox after a clean rebuild. Filed together with #2039 (custom presets) to make the pattern visible across both issues.