AutoDevcloudflared ausente
O check-in remoto precisa do cloudflared. Sem ele, o AutoDev serve só na máquina local, e a execução não falha.
O que você vê #
O check-in remoto não recebe um endereço público. Quando o túnel não consegue iniciar, o AutoDev imprime isto e continua servindo na 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 mais para. O cloudflared é necessário só para o check-in pelo celular, e a execução não é afetada. autodev serve --tunnel imprime essa mensagem. Um servidor iniciado pelo painel escreve o mesmo texto no log de eventos como serve.tunnel_failed, e a linha de endereço do painel mostra Tunnel unavailable — loopback only.
Por quê #
O AutoDev expõe seu plano local por um quick tunnel do cloudflared, então precisa do comando cloudflared no seu PATH. Um binário ausente é o caso esperado na primeira vez, e o AutoDev passa a servir só localmente em vez de falhar.
Ausente não é o único motivo de um túnel falhar. A mesma linha Tunnel unavailable traz uma destas mensagens:
| Mensagem | O que significa |
|---|---|
cloudflared did not announce a tunnel URL within 60s | O túnel iniciou e não imprimiu seu endereço em 60 segundos. |
cloudflared exited with code N before announcing a URL | O processo terminou antes de imprimir um endereço. |
cloudflared failed: ... | Iniciá-lo gerou um erro diferente de arquivo ausente. |
Correção #
Instale o cloudflared e inicie o servidor de novo:
winget install --id Cloudflare.cloudflared
autodev serve --tunnel
O instalador do Windows é um MSI que exige elevação. O AutoDev também lê a variável de ambiente AUTODEV_TUNNEL_BIN: quando definida, ela indica o binário a executar em vez de procurar no PATH, então um executável portátil em uma pasta sua funciona.
Ligando o acesso remoto trata do lado do painel, e Todos os comandos da CLI descreve serve e suas flags.