Saltar al contenido principal

​
Doctor

openclaw doctor es la herramienta de reparación + migración de OpenClaw. Corrige configuraciones/estado obsoletos, comprueba el estado y proporciona pasos de reparación accionables.

​
Inicio rápido

openclaw doctor

​
Sin interfaz / automatización

openclaw doctor --yes
Acepta los valores predeterminados sin solicitar confirmación (incluidos pasos de reparación de reinicio/servicio/sandbox cuando corresponda). 
openclaw doctor --repair
Aplica las reparaciones recomendadas sin solicitar confirmación (reparaciones + reinicios cuando sea seguro). 
openclaw doctor --repair --force
Aplica también reparaciones agresivas (sobrescribe configuraciones personalizadas del supervisor). 
openclaw doctor --non-interactive
Se ejecuta sin solicitudes y solo aplica migraciones seguras (normalización de configuración + movimientos de estado en disco). Omite acciones de reinicio/servicio/sandbox que requieren confirmación humana. Las migraciones de estado heredado se ejecutan automáticamente cuando se detectan. 
openclaw doctor --deep
Analiza servicios del sistema en busca de instalaciones adicionales del gateway (launchd/systemd/schtasks). Si quieres revisar los cambios antes de escribirlos, abre primero el archivo de configuración: 
cat ~/.openclaw/openclaw.json

​
Qué hace (resumen)

  • Actualización previa al vuelo opcional para instalaciones git (solo interactiva).
  • Comprobación de vigencia del protocolo de UI (reconstruye la Control UI cuando el esquema del protocolo es más reciente).
  • Comprobación de estado + solicitud de reinicio.
  • Resumen del estado de Skills (aptas/faltantes/bloqueadas) y estado de plugins.
  • Normalización de configuración para valores heredados.
  • Migración de configuración de Talk desde campos planos heredados talk.* a talk.provider + talk.providers.<provider>.
  • Comprobaciones de migración del navegador para configuraciones heredadas de extensiones de Chrome y preparación de Chrome MCP.
  • Advertencias de anulación del proveedor OpenCode (models.providers.opencode / models.providers.opencode-go).
  • Comprobación de requisitos previos de TLS OAuth para perfiles OAuth de OpenAI Codex.
  • Migración de estado heredado en disco (sesiones/directorio de agente/autenticación de WhatsApp).
  • Migración heredada de claves de contrato en manifiestos de plugins (speechProviders, realtimeTranscriptionProviders, realtimeVoiceProviders, mediaUnderstandingProviders, imageGenerationProviders, videoGenerationProviders, webFetchProviders, webSearchProviders → contracts).
  • Migración heredada del almacén cron (jobId, schedule.cron, campos de entrega/carga útil de nivel superior, provider de la carga útil, trabajos simples de respaldo de webhook con notify: true).
  • Inspección de archivos de bloqueo de sesión y limpieza de bloqueos obsoletos.
  • Comprobaciones de integridad y permisos del estado (sesiones, transcripciones, directorio de estado).
  • Comprobaciones de permisos del archivo de configuración (chmod 600) al ejecutarse localmente.
  • Estado de autenticación de modelos: comprueba vencimiento de OAuth, puede renovar tokens próximos a vencer e informa de estados de enfriamiento/deshabilitación de perfiles de autenticación.
  • Detección de directorio adicional del espacio de trabajo (~/openclaw).
  • Reparación de imagen de sandbox cuando el sandboxing está habilitado.
  • Migración heredada de servicios y detección de gateways adicionales.
  • Migración heredada del estado del canal Matrix (en modo --fix / --repair).
  • Comprobaciones del runtime del Gateway (servicio instalado pero no en ejecución; etiqueta launchd en caché).
  • Advertencias de estado de canales (sondeadas desde el gateway en ejecución).
  • Auditoría de configuración del supervisor (launchd/systemd/schtasks) con reparación opcional.
  • Comprobaciones de buenas prácticas del runtime del Gateway (Node frente a Bun, rutas de gestores de versiones).
  • Diagnóstico de colisión de puertos del Gateway (predeterminado 18789).
  • Advertencias de seguridad para políticas de MD abiertas.
  • Comprobaciones de autenticación del Gateway para modo de token local (ofrece generación de token cuando no existe ninguna fuente de token; no sobrescribe configuraciones de token SecretRef).
  • Comprobación de linger de systemd en Linux.
  • Comprobación del tamaño de archivos bootstrap del espacio de trabajo (advertencias de truncamiento/cerca del límite para archivos de contexto).
  • Comprobación de estado de autocompletado del shell e instalación/actualización automática.
  • Comprobación de preparación del proveedor de embeddings de búsqueda de memoria (modelo local, clave de API remota o binario QMD).
  • Comprobaciones de instalación desde código fuente (desajuste de workspace pnpm, recursos UI ausentes, binario tsx ausente).
  • Escribe configuración actualizada + metadatos del asistente.

​
Comportamiento detallado y fundamento

​
0) Actualización opcional (instalaciones git)

Si se trata de una copia de trabajo git y doctor se ejecuta de forma interactiva, ofrece actualizar (fetch/rebase/build) antes de ejecutar doctor.

​
1) Normalización de configuración

Si la configuración contiene formas heredadas de valores (por ejemplo messages.ackReaction sin una anulación específica del canal), doctor las normaliza al esquema actual. Eso incluye los campos planos heredados de Talk. La configuración pública actual de Talk es talk.provider + talk.providers.<provider>. Doctor reescribe las formas antiguas talk.voiceId / talk.voiceAliases / talk.modelId / talk.outputFormat / talk.apiKey en el mapa de proveedores.

​
2) Migraciones de claves de configuración heredadas

Cuando la configuración contiene claves obsoletas, otros comandos se niegan a ejecutarse y piden que ejecutes openclaw doctor. Doctor hará lo siguiente:
  • Explicar qué claves heredadas se encontraron.
  • Mostrar la migración aplicada.
  • Reescribir ~/.openclaw/openclaw.json con el esquema actualizado.
El Gateway también ejecuta automáticamente migraciones de doctor al arrancar cuando detecta un formato de configuración heredado, de modo que las configuraciones obsoletas se reparan sin intervención manual. Las migraciones del almacén de trabajos cron las gestiona openclaw doctor --fix. Migraciones actuales:
  • routing.allowFrom → channels.whatsapp.allowFrom
  • routing.groupChat.requireMention → channels.whatsapp/telegram/imessage.groups."*".requireMention
  • routing.groupChat.historyLimit → messages.groupChat.historyLimit
  • routing.groupChat.mentionPatterns → messages.groupChat.mentionPatterns
  • routing.queue → messages.queue
  • routing.bindings → bindings de nivel superior
  • routing.agents/routing.defaultAgentId → agents.list + agents.list[].default
  • talk.voiceId/talk.voiceAliases/talk.modelId/talk.outputFormat/talk.apiKey heredados → talk.provider + talk.providers.<provider>
  • routing.agentToAgent → tools.agentToAgent
  • routing.transcribeAudio → tools.media.audio.models
  • messages.tts.<provider> (openai/elevenlabs/microsoft/edge) → messages.tts.providers.<provider>
  • channels.discord.voice.tts.<provider> (openai/elevenlabs/microsoft/edge) → channels.discord.voice.tts.providers.<provider>
  • channels.discord.accounts.<id>.voice.tts.<provider> (openai/elevenlabs/microsoft/edge) → channels.discord.accounts.<id>.voice.tts.providers.<provider>
  • plugins.entries.voice-call.config.tts.<provider> (openai/elevenlabs/microsoft/edge) → plugins.entries.voice-call.config.tts.providers.<provider>
  • plugins.entries.voice-call.config.provider: "log" → "mock"
  • plugins.entries.voice-call.config.twilio.from → plugins.entries.voice-call.config.fromNumber
  • plugins.entries.voice-call.config.streaming.sttProvider → plugins.entries.voice-call.config.streaming.provider
  • plugins.entries.voice-call.config.streaming.openaiApiKey|sttModel|silenceDurationMs|vadThreshold → plugins.entries.voice-call.config.streaming.providers.openai.*
  • bindings[].match.accountID → bindings[].match.accountId
  • Para canales con accounts con nombre pero valores de canal de cuenta única persistentes en el nivel superior, mover esos valores de ámbito de cuenta a la cuenta promovida elegida para ese canal (accounts.default para la mayoría de los canales; Matrix puede conservar un destino con nombre/predeterminado coincidente existente)
  • identity → agents.list[].identity
  • agent.* → agents.defaults + tools.* (tools/elevated/exec/sandbox/subagents)
  • agent.model/allowedModels/modelAliases/modelFallbacks/imageModelFallbacks → agents.defaults.models + agents.defaults.model.primary/fallbacks + agents.defaults.imageModel.primary/fallbacks
  • browser.ssrfPolicy.allowPrivateNetwork → browser.ssrfPolicy.dangerouslyAllowPrivateNetwork
  • browser.profiles.*.driver: "extension" → "existing-session"
  • eliminar browser.relayBindHost (ajuste heredado del relay de la extensión)
Las advertencias de Doctor también incluyen orientación sobre la cuenta predeterminada para canales con varias cuentas:
  • Si se configuran dos o más entradas channels.<channel>.accounts sin channels.<channel>.defaultAccount o accounts.default, doctor advierte que el enrutamiento de respaldo puede elegir una cuenta inesperada.
  • Si channels.<channel>.defaultAccount se establece en un ID de cuenta desconocido, doctor advierte y enumera los IDs de cuenta configurados.

​
2b) Anulaciones del proveedor OpenCode

Si has añadido manualmente models.providers.opencode, opencode-zen o opencode-go, eso anula el catálogo OpenCode integrado de @mariozechner/pi-ai. Eso puede forzar modelos a la API equivocada o poner los costos a cero. Doctor advierte para que puedas eliminar la anulación y restaurar el enrutamiento por API + costos por modelo.

​
2c) Migración del navegador y preparación de Chrome MCP

Si tu configuración del navegador todavía apunta a la ruta eliminada de la extensión de Chrome, doctor la normaliza al modelo actual de conexión host-local de Chrome MCP:
  • browser.profiles.*.driver: "extension" pasa a ser "existing-session"
  • se elimina browser.relayBindHost
Doctor también audita la ruta host-local de Chrome MCP cuando usas defaultProfile: "user" o un perfil configurado existing-session:
  • comprueba si Google Chrome está instalado en el mismo host para perfiles predeterminados de conexión automática
  • comprueba la versión detectada de Chrome y advierte cuando es inferior a Chrome 144
  • recuerda habilitar la depuración remota en la página de inspección del navegador (por ejemplo chrome://inspect/#remote-debugging, brave://inspect/#remote-debugging, o edge://inspect/#remote-debugging)
Doctor no puede habilitar por ti la configuración del lado de Chrome. El Chrome MCP host-local sigue requiriendo:
  • un navegador basado en Chromium 144+ en el host del gateway/node
  • el navegador en ejecución local
  • depuración remota habilitada en ese navegador
  • aprobar la primera solicitud de consentimiento de conexión en el navegador
La preparación aquí solo se refiere a los requisitos previos para la conexión local. Existing-session mantiene los límites actuales de rutas de Chrome MCP; rutas avanzadas como responsebody, exportación a PDF, intercepción de descargas y acciones por lotes siguen requiriendo un navegador gestionado o un perfil CDP sin procesar. Esta comprobación no se aplica a Docker, sandbox, remote-browser ni a otros flujos sin interfaz. Esos siguen usando CDP sin procesar.

​
2d) Requisitos previos de TLS para OAuth

Cuando se configura un perfil OAuth de OpenAI Codex, doctor sondea el endpoint de autorización de OpenAI para verificar que la pila TLS local de Node/OpenSSL puede validar la cadena de certificados. Si el sondeo falla con un error de certificado (por ejemplo UNABLE_TO_GET_ISSUER_CERT_LOCALLY, certificado caducado o certificado autofirmado), doctor imprime orientación específica por plataforma. En macOS con un Node de Homebrew, la solución suele ser brew postinstall ca-certificates. Con --deep, el sondeo se ejecuta incluso si el gateway está en buen estado.

​
3) Migraciones de estado heredado (distribución en disco)

Doctor puede migrar distribuciones antiguas en disco a la estructura actual:
  • Almacén de sesiones + transcripciones:
    • de ~/.openclaw/sessions/ a ~/.openclaw/agents/<agentId>/sessions/
  • Directorio de agente:
    • de ~/.openclaw/agent/ a ~/.openclaw/agents/<agentId>/agent/
  • Estado de autenticación de WhatsApp (Baileys):
    • desde ~/.openclaw/credentials/*.json heredado (excepto oauth.json)
    • a ~/.openclaw/credentials/whatsapp/<accountId>/... (ID de cuenta predeterminado: default)
Estas migraciones son de mejor esfuerzo e idempotentes; doctor emitirá advertencias cuando deje carpetas heredadas como copias de seguridad. El Gateway/CLI también migra automáticamente las sesiones heredadas + el directorio del agente al iniciar, para que historial/autenticación/modelos terminen en la ruta por agente sin necesidad de ejecutar doctor manualmente. La autenticación de WhatsApp se migra intencionalmente solo mediante openclaw doctor. La normalización de Talk provider/provider-map ahora compara por igualdad estructural, así que las diferencias solo en el orden de claves ya no desencadenan cambios repetidos sin efecto con doctor --fix.

​
3a) Migraciones heredadas de manifiestos de plugins

Doctor analiza todos los manifiestos de plugins instalados en busca de claves de capacidades de nivel superior obsoletas (speechProviders, realtimeTranscriptionProviders, realtimeVoiceProviders, mediaUnderstandingProviders, imageGenerationProviders, videoGenerationProviders, webFetchProviders, webSearchProviders). Cuando las encuentra, ofrece moverlas al objeto contracts y reescribir el archivo del manifiesto en su sitio. Esta migración es idempotente; si la clave contracts ya tiene los mismos valores, la clave heredada se elimina sin duplicar los datos.

​
3b) Migraciones heredadas del almacén cron

Doctor también comprueba el almacén de trabajos cron (~/.openclaw/cron/jobs.json de forma predeterminada, o cron.store cuando se anula) en busca de formas antiguas de trabajos que el programador todavía acepta por compatibilidad. Las limpiezas cron actuales incluyen:
  • jobId → id
  • schedule.cron → schedule.expr
  • campos de carga útil de nivel superior (message, model, thinking, …) → payload
  • campos de entrega de nivel superior (deliver, channel, to, provider, …) → delivery
  • alias de entrega provider de la carga útil → delivery.channel explícito
  • trabajos simples heredados de respaldo de webhook con notify: true → delivery.mode="webhook" explícito con delivery.to=cron.webhook
Doctor solo migra automáticamente trabajos con notify: true cuando puede hacerlo sin cambiar el comportamiento. Si un trabajo combina el respaldo heredado de notificación con un modo de entrega no webhook existente, doctor advierte y deja ese trabajo para revisión manual.

​
3c) Limpieza de bloqueos de sesión

Doctor analiza cada directorio de sesiones de agente en busca de archivos de bloqueo de escritura obsoletos, archivos dejados atrás cuando una sesión salió de forma anómala. Para cada archivo de bloqueo encontrado informa: la ruta, PID, si el PID sigue vivo, antigüedad del bloqueo y si se considera obsoleto (PID muerto o más de 30 minutos). En modo --fix / --repair elimina automáticamente los archivos de bloqueo obsoletos; de lo contrario imprime una nota e indica que vuelvas a ejecutar con --fix.

​
4) Comprobaciones de integridad del estado (persistencia de sesión, enrutamiento y seguridad)

El directorio de estado es el tallo cerebral operativo. Si desaparece, pierdes sesiones, credenciales, registros y configuración (a menos que tengas copias de seguridad en otro lugar). Doctor comprueba:
  • Falta el directorio de estado: advierte sobre pérdida catastrófica de estado, solicita recrear el directorio y recuerda que no puede recuperar datos faltantes.
  • Permisos del directorio de estado: verifica que sea escribible; ofrece reparar permisos (y emite una pista chown cuando detecta una discrepancia de propietario/grupo).
  • Directorio de estado sincronizado en la nube en macOS: advierte cuando el estado se resuelve bajo iCloud Drive (~/Library/Mobile Documents/com~apple~CloudDocs/...) o ~/Library/CloudStorage/... porque las rutas respaldadas por sincronización pueden causar I/O más lento y condiciones de carrera de bloqueo/sincronización.
  • Directorio de estado en SD o eMMC en Linux: advierte cuando el estado se resuelve en un origen de montaje mmcblk*, porque el I/O aleatorio respaldado por SD o eMMC puede ser más lento y desgastarse más rápidamente con escrituras de sesiones y credenciales.
  • Faltan directorios de sesiones: sessions/ y el directorio del almacén de sesiones son necesarios para conservar el historial y evitar fallos ENOENT.
  • Desajuste de transcripción: advierte cuando entradas recientes de sesión tienen archivos de transcripción ausentes.
  • Sesión principal “1-line JSONL”: marca cuando la transcripción principal tiene solo una línea (el historial no se está acumulando).
  • Varios directorios de estado: advierte cuando existen varias carpetas ~/.openclaw en distintos directorios home o cuando OPENCLAW_STATE_DIR apunta a otro lugar (el historial puede dividirse entre instalaciones).
  • Recordatorio de modo remoto: si gateway.mode=remote, doctor recuerda que debes ejecutarlo en el host remoto (el estado vive allí).
  • Permisos del archivo de configuración: advierte si ~/.openclaw/openclaw.json es legible por grupo/mundo y ofrece restringirlo a 600.

​
5) Estado de autenticación de modelos (vencimiento de OAuth)

Doctor inspecciona los perfiles OAuth del almacén de autenticación, advierte cuando los tokens están próximos a vencer/vencidos y puede renovarlos cuando es seguro. Si el perfil OAuth/token de Anthropic está obsoleto, sugiere migrar a Claude CLI o a una clave de API de Anthropic. Las solicitudes de renovación solo aparecen al ejecutarse de forma interactiva (TTY); --non-interactive omite los intentos de renovación. Doctor también informa de perfiles de autenticación temporalmente inutilizables debido a:
  • enfriamientos breves (límites de tasa/tiempos de espera/fallos de autenticación)
  • deshabilitaciones más largas (fallos de facturación/crédito)

​
6) Validación del modelo de hooks

Si se establece hooks.gmail.model, doctor valida la referencia del modelo respecto al catálogo y la lista de permitidos, y advierte cuando no se resolverá o no está permitido.

​
7) Reparación de imagen de sandbox

Cuando el sandboxing está habilitado, doctor comprueba las imágenes de Docker y ofrece construir o cambiar a nombres heredados si falta la imagen actual.

​
7b) Dependencias de runtime de plugins integrados

Doctor verifica que las dependencias de runtime de plugins integrados (por ejemplo los paquetes de runtime del plugin de Discord) estén presentes en la raíz de instalación de OpenClaw. Si falta alguna, doctor informa de los paquetes y los instala en modo openclaw doctor --fix / openclaw doctor --repair.

​
8) Migraciones de servicios del Gateway y pistas de limpieza

Doctor detecta servicios heredados del gateway (launchd/systemd/schtasks) y ofrece eliminarlos e instalar el servicio de OpenClaw usando el puerto actual del gateway. También puede analizar servicios adicionales similares al gateway e imprimir pistas de limpieza. Los servicios del gateway OpenClaw con nombre de perfil se consideran de primera clase y no se marcan como “adicionales”.

​
8b) Migración de Matrix al arranque

Cuando una cuenta de canal Matrix tiene una migración heredada de estado pendiente o accionable, doctor (en modo --fix / --repair) crea una instantánea previa a la migración y luego ejecuta los pasos de migración de mejor esfuerzo: migración heredada del estado de Matrix y preparación heredada del estado cifrado. Ambos pasos no son fatales; los errores se registran y el arranque continúa. En modo de solo lectura (openclaw doctor sin --fix) esta comprobación se omite por completo.

​
9) Advertencias de seguridad

Doctor emite advertencias cuando un proveedor está abierto a MD sin una lista de permitidos, o cuando una política está configurada de forma peligrosa.

​
10) systemd linger (Linux)

Si se ejecuta como servicio de usuario systemd, doctor se asegura de que linger esté habilitado para que el gateway siga vivo después de cerrar la sesión.

​
11) Estado del espacio de trabajo (Skills, plugins y directorios heredados)

Doctor imprime un resumen del estado del espacio de trabajo para el agente predeterminado:
  • Estado de Skills: cuenta de Skills aptas, con requisitos faltantes y bloqueadas por lista de permitidos.
  • Directorios heredados del espacio de trabajo: advierte cuando existen ~/openclaw u otros directorios heredados del espacio de trabajo junto al espacio de trabajo actual.
  • Estado de plugins: cuenta de plugins cargados/deshabilitados/con errores; enumera los IDs de plugins de cualquier error; informa de capacidades de plugins empaquetados.
  • Advertencias de compatibilidad de plugins: marca plugins que tienen problemas de compatibilidad con el runtime actual.
  • Diagnósticos de plugins: muestra cualquier advertencia o error de carga emitido por el registro de plugins.

​
11b) Tamaño de archivos bootstrap

Doctor comprueba si los archivos bootstrap del espacio de trabajo (por ejemplo AGENTS.md, CLAUDE.md u otros archivos de contexto inyectados) están cerca o por encima del presupuesto de caracteres configurado. Informa por archivo del número bruto frente al número de caracteres inyectados, porcentaje de truncamiento, causa del truncamiento (max/file o max/total) y total de caracteres inyectados como fracción del presupuesto total. Cuando los archivos están truncados o cerca del límite, doctor imprime consejos para ajustar agents.defaults.bootstrapMaxChars y agents.defaults.bootstrapTotalMaxChars.

​
11c) Autocompletado del shell

Doctor comprueba si el autocompletado con tabulador está instalado para el shell actual (zsh, bash, fish o PowerShell):
  • Si el perfil del shell usa un patrón de autocompletado dinámico lento (source <(openclaw completion ...)), doctor lo actualiza a la variante más rápida de archivo en caché.
  • Si el autocompletado está configurado en el perfil pero falta el archivo de caché, doctor regenera automáticamente la caché.
  • Si no hay autocompletado configurado en absoluto, doctor solicita instalarlo (solo en modo interactivo; se omite con --non-interactive).
Ejecuta openclaw completion --write-state para regenerar manualmente la caché.

​
12) Comprobaciones de autenticación del Gateway (token local)

Doctor comprueba la preparación de autenticación por token del gateway local.
  • Si el modo de token necesita un token y no existe ninguna fuente de token, doctor ofrece generarlo.
  • Si gateway.auth.token está gestionado por SecretRef pero no disponible, doctor advierte y no lo sobrescribe con texto sin formato.
  • openclaw doctor --generate-gateway-token fuerza la generación solo cuando no hay configurado ningún token SecretRef.

​
12b) Reparaciones de solo lectura con reconocimiento de SecretRef

Algunos flujos de reparación necesitan inspeccionar credenciales configuradas sin debilitar el comportamiento fail-fast del runtime.
  • openclaw doctor --fix ahora usa el mismo modelo resumido de SecretRef de solo lectura que los comandos de la familia status para reparaciones de configuración específicas.
  • Ejemplo: la reparación de allowFrom / groupAllowFrom de Telegram con @username intenta usar credenciales del bot configuradas cuando están disponibles.
  • Si el token del bot de Telegram está configurado mediante SecretRef pero no está disponible en la ruta del comando actual, doctor informa de que la credencial está configurada pero no disponible y omite la resolución automática en lugar de fallar o informar incorrectamente que falta el token.

​
13) Comprobación del estado del Gateway + reinicio

Doctor ejecuta una comprobación de estado y ofrece reiniciar el gateway cuando parece que no está en buen estado.

​
13b) Preparación de búsqueda de memoria

Doctor comprueba si el proveedor de embeddings configurado para la búsqueda de memoria está listo para el agente predeterminado. El comportamiento depende del backend y del proveedor configurados:
  • Backend QMD: sondea si el binario qmd está disponible y puede iniciarse. Si no, imprime orientación de corrección, incluido el paquete npm y una opción manual de ruta binaria.
  • Proveedor local explícito: comprueba si existe un archivo de modelo local o una URL de modelo remoto/descargable reconocida. Si falta, sugiere cambiar a un proveedor remoto.
  • Proveedor remoto explícito (openai, voyage, etc.): verifica que exista una clave de API en el entorno o en el almacén de autenticación. Imprime pistas accionables si falta.
  • Proveedor automático: comprueba primero la disponibilidad del modelo local y luego prueba cada proveedor remoto en orden de selección automática.
Cuando hay disponible un resultado de sondeo del gateway (el gateway estaba en buen estado en el momento de la comprobación), doctor lo cruza con la configuración visible por la CLI y señala cualquier discrepancia. Usa openclaw memory status --deep para verificar en tiempo de ejecución la preparación de embeddings.

​
14) Advertencias de estado de canales

Si el gateway está en buen estado, doctor ejecuta un sondeo de estado de canales e informa de advertencias con correcciones sugeridas.

​
15) Auditoría + reparación de configuración del supervisor

Doctor comprueba la configuración instalada del supervisor (launchd/systemd/schtasks) en busca de valores predeterminados faltantes u obsoletos (por ejemplo, dependencias de systemd con network-online y retraso de reinicio). Cuando encuentra una discrepancia, recomienda una actualización y puede reescribir el archivo del servicio/tarea con los valores predeterminados actuales. Notas:
  • openclaw doctor solicita confirmación antes de reescribir la configuración del supervisor.
  • openclaw doctor --yes acepta las solicitudes de reparación predeterminadas.
  • openclaw doctor --repair aplica las correcciones recomendadas sin solicitudes.
  • openclaw doctor --repair --force sobrescribe configuraciones personalizadas del supervisor.
  • Si la autenticación por token requiere un token y gateway.auth.token está gestionado por SecretRef, la instalación/reparación del servicio de doctor valida el SecretRef pero no conserva valores de token en texto sin formato resueltos en los metadatos de entorno del servicio supervisor.
  • Si la autenticación por token requiere un token y el token SecretRef configurado no está resuelto, doctor bloquea la ruta de instalación/reparación con orientación accionable.
  • Si tanto gateway.auth.token como gateway.auth.password están configurados y gateway.auth.mode no está establecido, doctor bloquea la instalación/reparación hasta que el modo se establezca explícitamente.
  • Para unidades user-systemd de Linux, las comprobaciones de deriva de token de doctor ahora incluyen tanto las fuentes Environment= como EnvironmentFile= al comparar metadatos de autenticación del servicio.
  • Siempre puedes forzar una reescritura completa mediante openclaw gateway install --force.

​
16) Diagnósticos del runtime + puerto del Gateway

Doctor inspecciona el runtime del servicio (PID, último estado de salida) y advierte cuando el servicio está instalado pero no se está ejecutando realmente. También comprueba colisiones de puertos en el puerto del gateway (predeterminado 18789) e informa de causas probables (gateway ya en ejecución, túnel SSH).

​
17) Buenas prácticas del runtime del Gateway

Doctor advierte cuando el servicio del gateway se ejecuta con Bun o con una ruta Node gestionada por un gestor de versiones (nvm, fnm, volta, asdf, etc.). Los canales WhatsApp + Telegram requieren Node, y las rutas de gestores de versiones pueden romperse tras actualizaciones porque el servicio no carga la inicialización de tu shell. Doctor ofrece migrar a una instalación de Node del sistema cuando está disponible (Homebrew/apt/choco).

​
18) Escritura de configuración + metadatos del asistente

Doctor conserva cualquier cambio de configuración y marca metadatos del asistente para registrar la ejecución de doctor.

​
19) Consejos del espacio de trabajo (copia de seguridad + sistema de memoria)

Doctor sugiere un sistema de memoria del espacio de trabajo cuando falta e imprime un consejo de copia de seguridad si el espacio de trabajo aún no está bajo git. Consulta /concepts/agent-workspace para una guía completa de la estructura del espacio de trabajo y copia de seguridad con git (se recomienda GitHub o GitLab privado).