Configurando uma Máquina Remota para Programação com Agentes de IA

O conjunto mínimo de ferramentas para executar o Claude Code em uma máquina remota consiste em um VPS Linux ou uma máquina sempre ligada, Tailscale para uma rede mesh WireGuard privada que não requer encaminhamento de portas ou DNS dinâmico, tmux para sessões de terminal persistentes que sobrevivem a desconexões, e mosh ou SSH como camada de conexão — tudo gratuito, tudo combinável e tudo durável além das ferramentas de abstração do momento. Este guia percorre essa stack de ponta a ponta para o caso mais comum que os tutoriais existentes ignoram: um agente de programação em um VPS na nuvem ou em uma máquina reserva, protegido e controlado remotamente a partir de um laptop ou celular.

O problema que vale a pena resolver é a persistência. Quando você executa um agente de programação localmente e fecha o laptop, a sessão morre. Uma máquina remota mantém o agente ativo durante desconexões, oferece controle e custo previsível em comparação a uma plataforma gerenciada, e permite que você direcione o trabalho de qualquer lugar. O ponto crítico — pouco abordado em qualquer lugar — é que uma máquina executando um agente com acesso ao shell e chaves de API é uma superfície de ataque séria, por isso este guia prioriza a segurança em vez de adicioná-la como um passo final.

Por Que uma Máquina Remota, e DIY vs. as Alternativas

Uma máquina remota é vantajosa quando você precisa de um agente de programação que sobreviva a desconexões, execute sem supervisão e permaneça acessível a partir de qualquer dispositivo — sem pagar a taxa por usuário de uma plataforma ou aceitar suas restrições de sandbox. A contrapartida é operacional: você é responsável pela segurança, pelo tempo de atividade e pelas atualizações. Para desenvolvedores já familiarizados com SSH e Git, essa troca geralmente vale a pena.

Antes de construir qualquer coisa, decida qual das três abordagens se encaixa melhor. O cenário mudou no início de 2026, e o enquadramento mais antigo de “você precisa de tmux e SSH para usar o Claude Code remotamente” está agora incompleto.

A Anthropic lançou o Remote Control nativo como uma prévia de pesquisa e as Remote Sessions na nuvem no início de 2026 (CLI v2.1.x em meados de 2026). O Remote Control usa HTTPS somente de saída — sem portas de entrada — para permitir que você controle uma sessão pelo celular. É genuinamente útil, mas é de sessão única e encerra com o terminal que o iniciou. O Claude Code em si é executado como uma ferramenta CLI sem daemon em segundo plano para sessões interativas; a solicitação de funcionalidade aberta para um modo daemon headless confirma que fechar o terminal encerra a sessão. Para configurações sempre ativas, headless ou com múltiplos projetos, você constrói sobre primitivos duráveis e adiciona ferramentas de conveniência por cima.

A categoria de plataformas gerenciadas existe e é bem financiada, mas para um desenvolvedor que já vive em SSH e Git, uma máquina auto-hospedada oferece mais controle a um custo menor. Este guia cobre o caminho DIY.

Os Dois Padrões: tmux vs. systemd

Existem dois objetivos distintos que os leitores frequentemente confundem, e eles precisam de configurações diferentes. Executar um agente CLI de programação como o Claude Code em uma sessão à qual você se conecta e desconecta é o padrão tmux. Hospedar um agente como um serviço HTTP sempre ativo acessível via API é o padrão systemd. Escolher o errado é o erro estrutural mais comum em configurações de agentes remotos.

Use tmux quando quiser observar e controlar o agente — digitar prompts, aprovar ações, ler a saída. Use systemd quando o agente for um serviço que aceita requisições e executa sem um humano conectado. A maioria das pessoas que executa o Claude Code interativamente quer tmux. A maioria das pessoas que expõe um agente por trás de uma API quer systemd. Algumas configurações usam ambos.

Execute o Claude Code Remotamente: A Stack Gratuita Canônica

A stack gratuita canônica para executar o Claude Code remotamente é uma máquina Linux, Tailscale para a camada de rede privada, OpenSSH mais mosh para a conexão, e tmux para sessões persistentes. Esta seção é a sequência de configuração pronta para copiar e colar. Execute o hardening de segurança na próxima seção antes de tratar a máquina como produção.

Instalar o Tailscale

O Tailscale constrói uma rede mesh criptografada com WireGuard entre seus dispositivos: uma vez instalado, sua máquina remota recebe um endereço estável 100.x.x.x acessível a partir de qualquer dispositivo autenticado sem abrir portas no firewall, configurar DNS dinâmico ou mexer no roteador. O protocolo subjacente do Tailscale é o WireGuard, e o plano Personal gratuito cobre até 6 usuários com dispositivos ilimitados de propriedade do usuário conforme a reformulação de preços de abril de 2026 — verifique os limites atuais antes de depender deles.

Instale-o na máquina remota conforme a documentação oficial de instalação:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

O comando tailscale up exibe uma URL de autenticação. Abra-a, faça login e a máquina entra na sua tailnet. Execute tailscale ip -4 para obter o endereço 100.x.x.x. Instale o Tailscale no seu laptop e celular da mesma forma, autentique-os na mesma conta, e os três dispositivos podem agora se comunicar diretamente.

Uma ressalva que quebra configurações silenciosamente — que nós mesmos enfrentamos: não ative o servidor SSH integrado do Tailscale com tailscale up --ssh se você planeja usar o mosh. O Tailscale SSH executa o próprio servidor SSH do Tailscale, não o OpenSSH, e o mosh precisa executar o mosh-server sobre o OpenSSH real e analisar sua saída para inicializar uma sessão — o que o Tailscale SSH não suporta. Mantenha o OpenSSH instalado e em execução junto ao Tailscale para que o mosh possa se conectar.

Configurar SSH e mosh

O SSH fornece o shell; o mosh mantém a conexão utilizável em conexões móveis instáveis, sobrevivendo a mudanças de IP e roaming. O mosh requer que uma porta UDP no intervalo 60000–61000 seja acessível, conforme a documentação do mosh. Em uma rede mesh Tailscale, esse intervalo já é acessível entre dispositivos autenticados, portanto nenhuma configuração de roteador é necessária.

Instale o mosh tanto no servidor quanto no cliente:

sudo apt update && sudo apt install -y mosh tmux

Conecte-se a partir do seu laptop usando o endereço Tailscale:

mosh youruser@100.x.x.x

Se o mosh falhar ao conectar, use ssh youruser@100.x.x.x para confirmar que a máquina está acessível, depois verifique se o OpenSSH (não o Tailscale SSH) está respondendo.

Criar Sessões tmux Persistentes

O tmux é o que mantém o agente ativo após você se desconectar. Inicie uma sessão, execute o Claude Code dentro dela, desconecte-se e o agente continua trabalhando; reconecte-se mais tarde de qualquer dispositivo para verificar ou controlar o trabalho.

Nomeie as sessões tmux pelo projeto, não pela ferramenta. Use tmux new-session -s meuprojeto em vez de tmux new-session -s claude — quando você estiver executando três agentes em três repositórios, o tmux ls precisa indicar qual sessão é qual:

tmux new-session -s meuprojeto
# dentro da sessão:
cd ~/code/meuprojeto
claude
# desconecte com Ctrl-b e depois d

O flag -s nomeia a sessão. Reconecte-se de qualquer lugar com tmux attach -t meuprojeto, ou liste tudo que está em execução com tmux ls. Esse ciclo de desconexão e reconexão é todo o loop interativo do agente remoto: feche o laptop, reconecte-se pelo celular via mosh, leia o que o agente fez e dê a próxima instrução.

A Linha de Base de Segurança

Uma máquina remota executando um agente de programação é um alvo de alto valor: ela possui acesso ao shell, chaves de API e frequentemente credenciais de repositório. Vincular a porta do agente a 0.0.0.0 em um VPS público, mesmo que brevemente para um teste rápido, coloca os três em risco. Proteja a máquina antes de confiar a ela qualquer coisa. Esta seção não é opcional.

Somente Chaves SSH

Desative a autenticação por senha para que a única forma de acesso seja uma chave que você possui. Edite /etc/ssh/sshd_config e defina:

PasswordAuthentication no
PermitRootLogin no

A diretiva PasswordAuthentication no desativa o login por senha, e PermitRootLogin no bloqueia o SSH direto como root — ambas documentadas no manual do sshd_config. Um erro comum é editar o arquivo errado; essas diretivas pertencem ao /etc/ssh/sshd_config, não a uma configuração de cliente. Aplique com sudo systemctl restart ssh. Confirme que sua chave funciona em uma sessão separada antes de fechar a atual, para que um erro de digitação não te bloqueie.

Mantenha a Rede Privada Privada

A rede mesh do Tailscale já é autenticada, mas você pode restringir quais dispositivos acessam quais portas usando ACLs do Tailscale. Uma política de ACL restringe o tráfego entre dispositivos marcados — por exemplo, permitindo que apenas seu laptop e celular acessem a máquina do agente, e nada mais na tailnet. Para uma configuração de usuário único, o padrão “permitir tudo dentro da sua tailnet” é razoável; adicione ACLs quando outras pessoas ou dispositivos não confiáveis compartilharem a rede.

Nunca Vincule o Agente a 0.0.0.0

Ao testar um serviço vinculado localmente, use curl http://127.0.0.1:9000/health a partir do próprio servidor em vez de vincular temporariamente a 0.0.0.0. Em um VPS sem uma regra de firewall bloqueando a porta 9000, essa mudança de uma linha expõe seu agente à internet pública pelo tempo que o processo estiver em execução. Vincule a 127.0.0.1 e acesse o serviço através do Tailscale ou de um proxy reverso — nunca diretamente.

Mantenha os Segredos Fora do Arquivo de Unit

Nunca coloque chaves de API na linha Environment= de um arquivo de unit do systemd — elas aparecem na saída do systemctl show. Use EnvironmentFile=/etc/myagent/secrets.env para manter os valores fora do arquivo de unit e do systemctl show, conforme a documentação do systemd.exec. Restrinja as permissões do arquivo:

sudo mkdir -p /etc/myagent
sudo chmod 640 /etc/myagent/secrets.env
sudo chown root:myagent /etc/myagent/secrets.env

Seja preciso sobre o que isso oferece: EnvironmentFile= mantém os segredos fora do arquivo de unit e do systemctl show, mas uma vez carregados, os valores permanecem legíveis no ambiente do processo em execução e via D-Bus. Para proteção genuína de segredos, use o LoadCredential= do systemd, documentado no guia de credenciais do systemd, que passa credenciais por um diretório restrito em vez do ambiente do processo.

Mantendo um Agente de Serviço Ativo: O Unit do systemd

Para um agente que executa como um serviço HTTP sempre ativo em vez de uma sessão interativa, use um unit do systemd vinculado a 127.0.0.1 com Restart=always. Este é o padrão systemd: o serviço inicia na inicialização, reinicia após falhas, registra logs no journal e nunca toca diretamente em uma porta pública. EnvironmentFile= é uma diretiva central do systemd de longa data, disponível em todas as versões atuais do systemd, conforme a documentação do systemd.exec.

Crie /etc/systemd/system/my-agent.service:

[Unit]
Description=My Agent Service
After=network.target

[Service]
User=myagent
Group=myagent
WorkingDirectory=/home/myagent/app
EnvironmentFile=/etc/myagent/secrets.env
ExecStart=/home/myagent/app/venv/bin/uvicorn main:app --host 127.0.0.1 --port 9000
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Cada diretiva tem seu propósito. After=network.target aguarda a rede estar disponível. Executar com um User/Group dedicado limita o raio de impacto caso o agente seja comprometido. EnvironmentFile= carrega os segredos do arquivo com permissões restritas. ExecStart executa o servidor diretamente do virtualenv do projeto — sem scripts intermediários — vinculado a 127.0.0.1 para que a porta nunca seja publicamente acessível. Restart=always com RestartSec=5 reinicia o serviço cinco segundos após qualquer falha.

Ative e inicie-o:

sudo systemctl daemon-reload
sudo systemctl enable --now my-agent
sudo systemctl status my-agent

Para expor o serviço com segurança, coloque um proxy reverso na frente da porta vinculada ao localhost. Um proxy_pass do nginx para 127.0.0.1 mantém o upstream inacessível diretamente do exterior enquanto encerra o TLS na borda:

server {
    listen 443 ssl;
    server_name agent.example.com;

    ssl_certificate     /etc/letsencrypt/live/agent.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agent.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Provisione o certificado com o Certbot, que automatiza a emissão e renovação pelo Let’s Encrypt. Para uma configuração de usuário único, muitas vezes você não precisa de um hostname público — acessar o serviço via Tailscale em 100.x.x.x:9000 a partir de dispositivos autenticados evita completamente a exposição pública.

Acessando a Máquina pelo Celular

Você acessa um agente remoto pelo celular da mesma forma que acessa pelo laptop — via Tailscale, com um cliente de terminal ou um terminal no navegador. O cenário de ferramentas aqui está evoluindo rapidamente em meados de 2026; trate estas como melhorias opcionais, não como infraestrutura essencial.

As opções duráveis são um cliente SSH para celular (vários suportam conexões persistentes e autenticação por chave) mais tmux, ou mosh para conexões que sobrevivem a mudanças de rede. Por cima disso ficam as ferramentas de terminal no navegador. O ttyd expõe um terminal via web. O vibetunnel (licença MIT, primariamente para Mac com uma compilação npm Linux multiplataforma) faz proxy de um terminal para o navegador e foi construído para monitorar agentes Claude Code, com acesso remoto via Tailscale. Se você executar qualquer terminal no navegador, mantenha-o vinculado ao localhost e acesse-o via Tailscale — expor um terminal web publicamente é o mesmo erro do 0.0.0.0 em uma forma diferente.

O Remote Control nativo do Claude Code cobre o caso mais simples: HTTPS somente de saída, controle pelo celular, sem portas de entrada. É a forma mais rápida de interagir com uma única sessão ativa. A stack DIY permanece o que você usa quando o trabalho sobrevive a qualquer terminal.

O Fluxo de Trabalho Diário

O loop diário de reimplantação em uma máquina remota são três comandos: puxar o código, reiniciar o serviço e acompanhar os logs. Para um agente gerenciado pelo systemd, isso é:

cd ~/app && git pull origin main
source venv/bin/activate && pip install -r requirements.txt
sudo systemctl restart my-agent
journalctl -u my-agent -f

git pull busca o código mais recente, a instalação de dependências captura quaisquer novos requisitos, systemctl restart reinicia o serviço, e journalctl -u my-agent -f acompanha os logs do serviço em tempo real para que você possa confirmar uma inicialização limpa — journalctl lê o journal do systemd, documentado em freedesktop.org. Para um agente tmux interativo, o loop é ainda mais simples: reconecte-se com tmux attach -t meuprojeto, execute git pull e deixe o agente continuar.

Conclusão

Construa sobre os primitivos que sobrevivem às ferramentas de abstração: SSH e Tailscale para a rede, tmux para sessões que você controla, systemd para serviços que executam sem supervisão, e uma linha de base de segurança que mantém a porta do agente fora da internet pública. Escolha deliberadamente o padrão tmux ou o padrão systemd com base em se você está controlando um agente ou hospedando um, proteja a máquina antes de confiar a ela chaves de API, e então adicione o Remote Control nativo ou um terminal no navegador por cima como conveniência. Comece com uma máquina Linux nova e o comando de instalação do Tailscale acima — o restante é combinável a partir daí.

Perguntas Frequentes

Por que meu agente continua morrendo quando me desconecto do SSH?

Uma sessão SSH simples vincula o processo do agente ao seu terminal, então fechar a conexão envia um sinal de hangup que o encerra. Execute o agente dentro de uma sessão tmux: inicie-a com tmux new-session -s meuprojeto, lance o agente e depois desconecte com Ctrl-b seguido de d. O processo continua em execução no servidor, e você se reconecta mais tarde de qualquer dispositivo com tmux attach -t meuprojeto.

Quando devo usar o Remote Control nativo do Claude Code em vez de uma configuração DIY com tmux e SSH?

Use o Remote Control nativo quando você só precisa controlar uma única sessão ativa pelo celular ou navegador sem infraestrutura, já que ele usa HTTPS somente de saída e não abre portas de entrada. É de sessão única e encerra com o terminal que o iniciou, então para trabalho sempre ativo, headless ou com múltiplos projetos que deve sobreviver a desconexões, construa a stack DIY com SSH, Tailscale, tmux e systemd.

O mosh funciona em uma rede Tailscale?

Sim, o mosh funciona em uma rede mesh Tailscale porque o intervalo de portas UDP 60000 a 61000 que ele requer já é acessível entre dispositivos autenticados, portanto nenhuma configuração de roteador é necessária. O único ponto de falha é ativar o próprio servidor SSH do Tailscale com tailscale up --ssh, o que substitui o OpenSSH; o mosh precisa executar o mosh-server sobre o OpenSSH real para inicializar, então mantenha o OpenSSH instalado e em execução junto ao Tailscale.

Qual é a diferença entre usar EnvironmentFile e LoadCredential para segredos no systemd?

EnvironmentFile carrega valores de um arquivo externo para que fiquem fora do arquivo de unit e da saída do systemctl show, mas os valores permanecem legíveis no ambiente do processo em execução e via D-Bus. LoadCredential é mais robusto porque passa os segredos por um diretório restrito em vez do ambiente do processo, mantendo-os fora do alcance do ambiente do processo em execução. Use EnvironmentFile para configurações e LoadCredential para segredos genuínos.