AutoDevFalta cloudflared
El check-in remoto necesita cloudflared. Sin él, AutoDev sirve solo en la máquina local, y la ejecución no falla.
Lo que ves #
El check-in remoto no recibe una dirección pública. Cuando el túnel no puede iniciarse, AutoDev imprime esto y sigue sirviendo en la máquina local:
Tunnel unavailable — serving on loopback only. cloudflared is not installed or not on PATH (...). Install it (winget install --id Cloudflare.cloudflared) and retry.
Nada más se detiene. cloudflared hace falta solo para el check-in desde el teléfono, y la ejecución no se ve afectada. autodev serve --tunnel imprime ese mensaje. Un servidor iniciado desde el panel escribe el mismo texto en el registro de eventos como serve.tunnel_failed, y la línea de dirección del panel muestra Tunnel unavailable — loopback only.
Por qué #
AutoDev expone su plano local mediante un quick tunnel de cloudflared, así que necesita el comando cloudflared en tu PATH. Un binario ausente es el caso esperado la primera vez, y AutoDev pasa a servir solo en local en lugar de fallar.
Que falte no es la única razón por la que un túnel falla. La misma línea Tunnel unavailable lleva uno de estos mensajes:
| Mensaje | Qué significa |
|---|---|
cloudflared did not announce a tunnel URL within 60s | El túnel se inició y no imprimió su dirección en 60 segundos. |
cloudflared exited with code N before announcing a URL | El proceso terminó antes de imprimir una dirección. |
cloudflared failed: ... | Iniciarlo produjo un error distinto de archivo ausente. |
Solución #
Instala cloudflared y vuelve a iniciar el servidor:
winget install --id Cloudflare.cloudflared
autodev serve --tunnel
El instalador de Windows es un MSI que requiere elevación. AutoDev también lee la variable de entorno AUTODEV_TUNNEL_BIN: cuando está definida, indica el binario que ejecutar en lugar de buscar en el PATH, así que un ejecutable portátil en una carpeta tuya funciona.
Activar el acceso remoto trata del lado del panel, y Todos los comandos de la CLI describe serve y sus flags.