Como dirijo um agente de codificação em nuvem do meu telefone pelo navegador
tl;dr: Coloquei o Google’s Identity-Aware Proxy na frente de um serviço Cloud Run executando um agente de codificação em um terminal web. Agora, abro uma URL no meu telefone, faço login com minha conta do Google e estou falando com o agente.
Fonte: github.com/ykdojo/antigravity-cloud-run
Este é um aprimoramento do meu configuração de ambientes de desenvolvimento containerizados: o agente roda com --dangerously-skip-permissions dentro de um contêiner no Cloud Run, acessível através de um terminal web. A parte que faltava era usá-lo longe do meu laptop.
Esta configuração específica foi feita para Antigravity CLI, mas deve funcionar com quase qualquer outro agente de codificação baseado em CLI.
Dois caminhos para acessar uma sessão pelo telefone, e por que escolhi o IAP
Minhas sessões já se conectam à minha rede Tailscale, então a rota óbvia era o aplicativo Tailscale no telefone. Funciona, mas há um problema: o tráfego de tailnet bypassa completamente o front-end do Cloud Run, então o autoscaler pensa que o serviço está ocioso e reclama a instância após cerca de 15 minutos, em uso. A única solução é fixar a instância com min-instances=1, o que custa dinheiro ao redor do relógio, independentemente de eu estar usando ou não.
O IAP inverte isso. O Identity-Aware Proxy é a porta de entrada gerenciada de login do Google Cloud: você coloca-o na frente de um serviço, e apenas as contas do Google que você permitir passam. Você abre a URL regular run.app do serviço, faz login e está no terminal. A WebSocket do terminal é uma solicitação real de ingresso, então abrir a guia acorda a instância, mantém-a viva enquanto você estiver conectado e permite que ela escala para zero quando você fechar a guia.
Se você quiser que a instância nunca morra, implemente com min-instances=1 e ela nunca escala para zero.
A pilha, camada por camada
- IAP decide quem tem acesso. Apenas as contas Google que você permitiu podem acessá-la.
- ttyd transforma o navegador em um terminal. O agente é uma TUI e o navegador fala HTTP/WebSocket; ttyd conecta os dois.
- tmux mantém a sessão ativa quando a conexão cai, e você pode se conectar à mesma sessão de múltiplos dispositivos.
- agy faz o trabalho.
Configurando
Habilitar IAP no serviço em si são três comandos:
gcloud run services update SERVICE --region REGION --iap
gcloud run services add-iam-policy-binding SERVICE --region REGION \
--member serviceAccount:service-PROJECT_NUMBER@gcp-sa-iap.iam.gserviceaccount.com \
--role roles/run.invoker
gcloud beta iap web add-iam-policy-binding --resource-type=cloud-run \
--service SERVICE --region REGION \
--member user:YOU@gmail.com --role roles/iap.httpsResourceAccessorSe seu projeto vive em uma organização Google Cloud, você pode estar pronto. O meu não está, então precisei fazer um longo desvio. Se precisar passar pelo mesmo processo, aqui está o que passei.
O desvio 502: sem organização, sem OAuth client automático
Depois de habilitar IAP, cada solicitação retornou um 502 com este corpo:
Google Account OAuth client ID(s)/secret(s) vazio.A razão: o OAuth client gerenciado pelo Google do IAP apenas autentica usuários dentro da sua organização. Um projeto pessoal não tem nenhuma organização, então não há cliente algum, por isso diz “vazio”. Usuários externos precisam de um OAuth client personalizado fornecido ao IAP. Quatro etapas, principalmente cliques no console:
- Marcação (console, Google Auth Platform → Overview → Get started): nome do aplicativo, e-mail de suporte, público-alvo Externo, concordar com a política de dados do usuário da API.
2. Usuários de teste (Página do público-alvo): enquanto a tela de consentimento está em Testando, apenas os usuários listados podem fazer login. Adicione cada conta que você concedeu o papel acessor. O modo de testes também expira logins após cerca de 7 dias; publicar o aplicativo remove isso se a reautenticação semanal incomodá-lo.
3. Cliente OAuth personalizado (Página de clientes): tipo Aplicativo Web. Adicione este URI de redirecionamento autorizado, com o ID do novo cliente substituído: https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect. Observe que o Google agora mostra a senha apenas no momento da criação, então pegue-a nesse momento.
4. Passe o cliente para IAP, no nível do projeto, então todos os serviços IAP no projeto herdam ele:
# iap_settings.yaml
access_settings:
oauth_settings:
client_id: CLIENT_ID
client_secret: CLIENT_SECRETgcloud iap settings set iap_settings.yaml --project PROJECT
Apague o yaml depois. O IAP armazena a senha como um hash.
A mudança entra em vigor em segundos: o 502 some, e a URL do serviço redireciona para uma página de login Google. No telefone: abra a URL do serviço, escolha sua conta Google, e o terminal carrega.
O que IAP quebra
Uma coisa para de funcionar: gcloud run services proxy, que é como meu painel incorpora terminais cloud localmente no meu laptop. O IAP rejeita os tokens do proxy, e em um projeto sem organização não há uma maneira limpa de contornar isso.
Então é uma escolha por sessão, e eu fiz isso um sinal: meu script de deploy aceita -i para trazer uma sessão com IAP, e o painel mostra essas sessões como um link "abrir no navegador" em vez de um terminal incorporado. O padrão é sem IAP.
Aqui está uma sessão phone com IAP ao lado de uma sessão sem IAP. A sessão do IAP abre em uma guia do navegador; a outra conecta através do proxy local e é incorporada no painel:
É uma caixa de seleção ao criar uma sessão também, desativada por padrão:
Limitações
A funcionalidade básica funciona: posso abrir uma sessão do meu telefone, digitar uma tarefa e assistir a execução. Algumas arestas ásperas que espero resolver mais tarde.
A rolagem não é boa. É um terminal em uma guia do navegador, então rolar de volta pela saída em uma tela sensível ao toque é mais complicado do que deveria ser.
O tamanho da fonte é outro problema. Não consigo configurar corretamente no celular. Funciona em todos os outros navegadores que tentei, então ainda não sei o que é diferente lá.