Description

On a DGX Spark (Express Install: managed vLLM serving nvidia/Qwen3.6-35B-A3B-NVFP4, OpenClaw v2026.6.10, OpenShell 0.0.85 docker), I'm trying to point OpenClaw built-in memory search (agents.defaults.memorySearch) at a local Ollama embedder.

Setup: Ollama runs in its OWN docker container on the same host (not inside the NemoClaw sandbox, and not the managed vLLM). It serves qwen3-embedding:4b and is published on host port 11434. The NemoClaw sandbox reaches it as a host service via host.openshell.internal:11434 — the same host-gateway mechanism the managed vLLM uses.

Reachability is confirmed working: from inside the sandbox,
curl http://host.openshell.internal:11434/api/tags
returns the model. The local-inference policy preset already allows port 11434 for egress.

The blocker is purely at config-write time. Setting the provider:
nemoclaw config set --key models.providers.ollama-mem
--value '{"api":"ollama","baseUrl":"http://host.openshell.internal:11434","apiKey":"x","models":[{"id":"qwen3-embedding:4b","name":"Q"}]}'
--config-accept-new-path
fails with:
URL validation failed for http://host.openshell.internal:11434/:
URL points to private/internal address "host.openshell.internal".
This could expose internal services to the sandbox.

Adding request.allowPrivateNetwork: true to the provider object does not help — the rejection is at NemoClaw's config-set SSRF layer, before OpenClaw schema validation. config set --help shows no SSRF/private-network override flag.

Net: the exact hostname the sandbox is DESIGNED to reach host services on (host.openshell.internal, already egress-permitted by local-inference) is rejected by the config-set write validator. There's no documented path from "reachable via curl" to "configured as a memorySearch provider" on DGX Spark.

Affected Page

docs/reference/memory-config (https://docs.openclaw.ai/reference/memory-config), plus the DGX Spark NemoClaw playbook (build.nvidia.com/spark/nemoclaw) and NemoClaw local-inference docs — none cover pointing memorySearch at a separate host-side container via host.openshell.internal.

Issue Type

Missing documentation

Suggested Fix

Add a DGX Spark–specific, worked procedure for configuring a memorySearch embedding provider that targets a separate host-side container (e.g. Ollama in its own docker container) reachable via host.openshell.internal. Clarify:

1. The supported way to set a memorySearch provider whose baseUrl is host.openshell.internal:, given that config set applies a write-time SSRF check that rejects it — even though local-inference already permits that exact host:port for egress and curl to it succeeds from the sandbox.

2. Whether a config key or flag exists to allow host.openshell.internal past the config-set SSRF validator, and if so, its exact path. (Reference the known onboard-vs-config-set inconsistency where onboard accepts internal URLs that config set / inference set reject.)

3. If config set cannot express this, document the intended alternative — editing openclaw.json under shields down — including the exact ownership/permission/hash steps to keep the config integrity seal valid so shields up succeeds afterward.

4. A complete DGX Spark worked example: Ollama in a sidecar container published on host 11434, wired end-to-end as the memorySearch embedder, with reindex and verification via openclaw memory status --deep. This is a natural pairing on Spark (managed vLLM handles chat; a small Ollama container handles embeddings) and currently has no documented recipe.

Additionally — address memory in the onboarding flow itself, not just as post-hoc config:

5. Onboarding currently configures INFERENCE (provider/model) but not MEMORY embeddings. It silently leaves memorySearch.provider defaulted to "openai", which assumes an OpenAI API key that a local-only DGX Spark install never provides. As a result, memory search is non-functional out of the box with no indication at setup time. In my case this wasn't apparent until a warning surfaced at the END of the first day of use — by which point I assumed memory had been working all along.

   Suggested: during onboarding (at least on DGX Spark / local-inference installs), either (a) prompt for a memory embedding provider the same way inference is handled, offering a local option (Ollama sidecar or in-process llama.cpp) instead of defaulting to openai; or (b) if memory is left unconfigured, detect that memorySearch.provider=openai has no resolvable key on a local install and surface a clear warning at onboarding completion — not silently, and not a day later.