Depois de um fim de semana, voltei à máquina Developer 01 e encontrei o trabalho com Docker e Ansible no ponto onde eu havia parado. Essa continuidade explica por que mantenho meu ambiente de desenvolvimento numa VPS e acesso os terminais pelo Herdr.
Fechar o notebook interrompe o acesso pelo cliente local. O processo continua na máquina remota enquanto o servidor e a sessão permanecem ativos. Essa distinção parece pequena até você confundir uma desconexão com uma execução terminada.
Direto ao ponto
O Herdr separa a interface usada no seu dispositivo do servidor que mantém os processos. Ao fechar o notebook, você perde a visualização naquele aparelho. A VPS continua executando o terminal e o agente conforme o estado deixado na máquina remota.
Uma sessão preservada pode conter um agente aguardando sua resposta. Reinicialização da VPS, processo encerrado e falta de recursos também interrompem o trabalho. Ao retornar, confira a máquina, o processo e a última saída antes de concluir que a tarefa ainda está avançando.
A conexão local e os processos remotos
No acesso remoto, seu notebook abre uma conexão SSH (Secure Shell) com a VPS. Um cliente como o Termius envia os comandos digitados na tela local, mas eles são executados no Linux remoto. Repositório, dependências e processos ficam no servidor.
O Herdr possui cliente e servidor: o cliente apresenta workspaces, abas e painéis, enquanto os terminais permanecem ativos na VPS depois que a interface fecha. Desconectar o aparelho não envia um sinal para encerrar cada processo aberto.
Você pode comprovar a separação com uma tarefa segura de teste. Inicie um comando que grave horário num arquivo por alguns minutos, desconecte o notebook e volte depois. O arquivo deve mostrar as gravações feitas durante a ausência.
Faça o ensaio num ambiente sem informação de cliente e sem tarefa destrutiva. O objetivo é observar a continuidade da sessão, não testar a recuperação de produção pela primeira vez.
Um agente aberto pode estar parado
A sessão permanecer visível não informa que o Codex ou o Claude continua processando. O agente pode ter concluído, encontrado uma falha ou apresentado uma pergunta. O terminal preserva esse estado para sua leitura.
Ao retornar, abra o workspace correto e leia as últimas linhas antes de enviar outro comando. Procure a saída do teste, a pergunta pendente ou a mensagem de erro. Iniciar outra execução sem essa leitura pode repetir trabalho e alterar os mesmos arquivos.
No meu uso, a continuidade vale porque posso retomar o raciocínio junto do histórico exibido no terminal. Ela não transforma uma tarefa longa em autonomia ilimitada. Ao retomar, compare os arquivos alterados, execute os testes correspondentes e confira o resultado.
O artigo da Promovaweb sobre Codex e Claude por projeto no Herdr detalha como identificar os terminais antes de responder a um agente.
Reiniciar a VPS muda o problema
A reinicialização da VPS encerra os processos do sistema, enquanto fechar o notebook interrompe o acesso local. Serviços configurados para iniciar no boot podem voltar, mas a restauração visual do workspace não prova que todos os comandos retomaram do mesmo ponto, como explica a documentação de restauração.
Depois de uma reinicialização, confira o horário de atividade do servidor, os processos esperados e os logs de cada serviço. Um container pode voltar automaticamente enquanto um comando iniciado num terminal permanece encerrado.
A falta de memória pode encerrar um processo na VPS, mesmo sem reinicialização. Ao escolher um provedor de VPS, confira a capacidade e monitore os logs durante o build. Um terminal preservado pode mostrar o erro depois que a execução já terminou.
Se o trabalho precisa voltar depois de uma reinicialização, configure sua execução como serviço, job ou pipeline. A aplicação também precisa gravar o andamento e saber retomá-lo para evitar repetir uma etapa concluída. Um processo iniciado no boot não recupera automaticamente o ponto anterior.
O tmux continua útil
Nas edições Desktop e Server, o SetupVibe mantém o Herdr e o tmux, que podem coexistir: o Herdr organiza workspaces e mostra agentes na interface, enquanto o tmux preserva sessões no terminal com comandos conhecidos e acesso por diferentes clientes.
Minha preferência pelo Herdr acompanha a visualização dos projetos e agentes. Em manutenção remota, o tmux continua útil para preservar logs e uma sequência de comandos que outro profissional pode retomar.
Teste a recuperação do acesso numa máquina de laboratório. Anote o endereço da VPS, a chave usada, o workspace e o comando necessário para abrir a sessão. Depois conecte outro cliente, confirme o hostname e mantenha as credenciais num gerenciador fora do repositório.
O retorno ao workspace depois da desconexão
Ao voltar ao notebook, confirme a máquina, abra o workspace e leia a última saída do agente. Responda à pergunta com base no projeto, examine a saída se houve erro ou compare os arquivos depois da conclusão. Rode o teste relacionado antes de continuar a implementação.
O acesso pelo computador e pelo celular usa a mesma separação entre dispositivo e servidor, mas a tela pequena funciona melhor para consulta e respostas curtas. Para revisar muitas alterações, prefira o computador.
A Formação DevOps da Promovaweb desenvolve a base para manter servidores, acesso e recuperação. Numa investigação técnica ao vivo, o Desenvolvimento Colaborativo da Dev Side Studio permite que você opere o próprio terminal com orientação.
