NemoClaw v0.0.122 respeta tu contexto Docker
NemoClaw deja de asumir el daemon Docker por defecto al preparar inferencia local en tu homelab.
El problema no era Docker, era la suposición
En un homelab es normal tener más de una forma de llegar a Docker. Puede haber contextos separados, una configuración en un directorio distinto al habitual o un daemon rootless que no escucha en el socket clásico. Si una herramienta ignora ese contexto y pregunta al daemon por defecto, el diagnóstico puede ser correcto para una máquina que no es la que realmente vas a usar.
Eso es justo lo que corrige NemoClaw v0.0.122 en sus comprobaciones de preparación del host. Antes de montar un agente con inferencia local, NemoClaw utiliza el mismo entorno que empleará después para ejecutar Docker. En la práctica, respeta el contexto seleccionado y el directorio indicado mediante DOCKER_CONFIG cuando DOCKER_HOST no está definido.
Una mejora pequeña que evita diagnósticos falsos
Para quien mantiene aplicaciones Laravel en Docker, esto tiene bastante sentido. El agente no necesita descubrir un Docker teórico: necesita validar el motor, los sockets y las restricciones del entorno donde convivirá con tus contenedores. Si el chequeo y la ejecución posterior toman caminos distintos, cualquier resultado positivo deja de ser especialmente útil.
La comprobación se realiza con nemoclaw host probe, que inspecciona el equipo antes del onboarding. También admite salida JSON, útil si quiero guardar la evidencia en un script de provisioning o en una comprobación de mi infraestructura. La documentación deja claro además que este comando es de solo lectura: observar el host no debe modificar contenedores, imágenes, servicios ni configuración.
export DOCKER_CONTEXT=homelab
export DOCKER_CONFIG="$HOME/.docker"
unset DOCKER_HOST
nemoclaw host probe --jsonEste ejemplo no crea un contexto ni cambia Docker. Simplemente deja explícito qué configuración debe heredar NemoClaw al revisar el host. Es una separación sencilla, pero ayuda a que el agente no acabe evaluando un daemon diferente al que uso para Laravel, colas, workers o servicios internos.
El socket rootless entra en la ecuación
Hay otro detalle importante para quien evita ejecutar Docker como root. Si DOCKER_HOST no está configurado y la autoridad Docker seleccionada no es alcanzable, NemoClaw puede probar un conjunto limitado de sockets Unix locales. En Linux, ese conjunto incluye el socket rootless ubicado en /run/user/<UID>/docker.sock.
No se trata de elegir cualquier socket que responda. NemoClaw exige evidencia válida de la versión del servidor antes de aceptar un endpoint alternativo. Cuando selecciona ese socket de reserva, elimina el contexto Docker inaccesible para que los comandos posteriores utilicen el DOCKER_HOST elegido.
Para un homelab, el valor no está en que el proceso sea automático sin más. Está en que el flujo de preparación y el flujo de ejecución compartan la misma autoridad Docker. Eso permite revisar una configuración concreta, reproducir el resultado y detectar antes las diferencias entre una sesión SSH, una terminal local y un servicio automatizado.
Endpoints explícitos con límites claros
La actualización también pone límites a DOCKER_HOST. La comprobación rechaza endpoints explícitos que no sean sockets Unix locales absolutos y compatibles. Un endpoint TCP, SSH, una ruta Unix relativa o una ruta considerada insegura no se sustituye silenciosamente por el socket Docker por defecto.
Me parece una decisión razonable para un agente que puede participar en tareas de código y operaciones. Un endpoint remoto introducido por una variable de entorno puede convertir un diagnóstico local en una conexión a otro host. Rechazar esa situación es preferible a continuar con una suposición que quizá oculte una configuración equivocada.
La letra pequeña
Esto no convierte automáticamente una instalación Docker en una configuración segura. El acceso al socket Docker sigue siendo una capacidad sensible, especialmente si el usuario o el proceso que ejecuta el agente puede controlar contenedores, volúmenes o imágenes. Rootless reduce parte de la superficie, pero no reemplaza la revisión de permisos, secretos, redes y volúmenes montados.
Tampoco vale cualquier runtime que aparezca como alternativa. Si NemoClaw encuentra sockets alcanzables de Docker y Podman con identidades distintas, no establece un DOCKER_HOST automáticamente y comunica un conflicto de autoridad. Un endpoint Podman detectado sigue siendo Podman y no satisface por sí mismo el requisito del runtime Docker estándar.
Finalmente, un resultado favorable de host probe no garantiza que cada operación posterior vaya a funcionar. La propia documentación distingue la compatibilidad de almacenamiento de Docker de operaciones como construir imágenes o adjuntar un gateway. Conviene tratar el probe como una precondición verificable, no como un sustituto de probar el flujo completo en el homelab.
Fuente: notas de la versión de NemoClaw v0.0.122 · Documentación oficial: System Readiness