NemoClaw v0.0.122 respects your Docker contextNemoClaw v0.0.122 respects your Docker context

The issue was not Docker, but the assumption

A homelab often has more than one path to Docker. You may use separate contexts, keep Docker configuration outside the usual directory, or run a rootless daemon that does not use the classic socket. When a tool ignores that setup and checks the default daemon, it may validate a machine you are not actually going to use.

That is the practical change in NemoClaw v0.0.122 host-readiness checks. Before preparing an agent with local inference, NemoClaw runs Docker probes with the environment that later Docker commands will use. When DOCKER_HOST is not set, that includes the selected context and the directory configured through DOCKER_CONFIG.

A small change that prevents misleading checks

This matters when Docker is already hosting Laravel applications. An agent should not discover an imaginary Docker installation; it should validate the engine, sockets, and limits of the environment where it will live next to application containers. If readiness and later execution take different routes, a successful probe is not very meaningful.

The check is available through nemoclaw host probe, which inspects the machine before onboarding. It can also return JSON, which is useful when I want to retain the result in provisioning scripts or infrastructure checks. The documentation is explicit that this command is read-only: inspecting the host must not alter containers, images, services, or configuration.

export DOCKER_CONTEXT=homelab
export DOCKER_CONFIG="$HOME/.docker"
unset DOCKER_HOST
 
nemoclaw host probe --json

This does not create a Docker context or modify Docker. It only makes the configuration inherited by NemoClaw explicit during the readiness check. That distinction helps ensure the agent does not inspect a different daemon from the one I use for Laravel, queues, workers, and internal services.

Rootless sockets are part of the picture

There is another relevant detail for anyone running Docker without root. If DOCKER_HOST is unset and the selected Docker authority is unreachable, NemoClaw can probe a bounded set of local Unix sockets. On Linux, that set includes the rootless Docker socket at /run/user/<UID>/docker.sock.

It does not accept the first socket that happens to answer. NemoClaw requires valid server-version evidence before it accepts an alternative endpoint. If it chooses that fallback socket, it clears the unreachable Docker context so subsequent commands use the selected DOCKER_HOST.

For a homelab, the real benefit is not automation for its own sake. It is that preparation and execution use the same Docker authority. That makes the setup easier to review, reproduce, and troubleshoot across an SSH session, a local terminal, and an automated service.

Explicit endpoints now have clear boundaries

The update also draws a hard line around DOCKER_HOST. The readiness check rejects explicit endpoints unless they are supported absolute local Unix sockets. TCP and SSH endpoints, relative Unix socket paths, and unsafe paths are not silently replaced with the default Docker socket.

That is a sensible choice for an agent involved in code and operations work. A remote endpoint injected through an environment variable can turn a local check into a connection to another machine. Failing early is better than proceeding with an assumption that could hide a wrong target.

The fine print

This does not automatically make a Docker installation safe. Docker socket access remains powerful, especially when the account or process running the agent can control containers, volumes, or images. Rootless Docker can reduce some exposure, but it does not remove the need to review permissions, secrets, networks, and mounted volumes.

Not every alternative runtime is interchangeable either. If NemoClaw finds reachable Docker and Podman sockets with different identities, it does not automatically set DOCKER_HOST and reports an authority conflict instead. A detected Podman endpoint remains Podman and does not, by itself, meet the standard Docker runtime requirement.

Finally, a positive host probe result is not a guarantee that every later operation will succeed. The documentation separates Docker storage compatibility from later actions such as building images or attaching a gateway. Treat the probe as a verifiable precondition, not as a replacement for testing the complete homelab workflow.

Source: NemoClaw v0.0.122 release notes · Official documentation: System Readiness