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 encerra o cliente usado para visualizar a sessão. 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

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.

Essa continuidade não cobre reinicialização da VPS, processo encerrado, falta de recursos nem agente aguardando sua resposta. Ao retornar, confira esses quatro estados antes de concluir que a tarefa ainda está avançando.

O notebook fecha somente uma ponta da conexão

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.

Herdr possui cliente e servidor. O cliente apresenta workspaces, abas e painéis. No servidor, os terminais continuam ativos depois que o cliente fecha. A desconexão 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. Eu ainda comparo os arquivos alterados, executo os testes correspondentes e confiro 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

Fechar o notebook interrompe o acesso local. Reiniciar a VPS interrompe processos do servidor, exceto os serviços configurados para iniciar novamente. A restauração visual do workspace não prova que todos os comandos retomaram do mesmo ponto.

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.

Espaço em disco, memória e CPU também influenciam a continuidade. Uma VPS sem recurso disponível pode terminar um processo mesmo sem reinicialização. Monitorar a máquina evita interpretar uma sessão preservada como garantia de execução.

Se o trabalho precisa sobreviver a reinicializações, transforme-o num serviço, job ou pipeline com estado verificável. O terminal atende a investigação e a interação. Ele não substitui a configuração de inicialização da aplicação.

O tmux continua útil

SetupVibe mantém Herdr e tmux nas edições Desktop e Server. As ferramentas podem coexistir. 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, 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.

Retome pelo estado, não pela memória

Ao voltar ao notebook, confirme primeiro a máquina. Depois abra o workspace, leia a última saída e verifique os arquivos alterados. Rode o teste relacionado à tarefa antes de continuar a implementação.

Se o agente deixou uma pergunta, responda com base no projeto. Se encerrou com erro, examine a saída. Se concluiu, compare as alterações. Essa sequência distingue continuidade do terminal de conclusão do trabalho.

O acesso pelo computador e pelo celular usa a mesma separação entre dispositivo e servidor. O celular serve bem para consulta e respostas curtas. A revisão extensa continua mais confortável numa tela maior.

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.

O fim de semana na Developer 01 mostrou o valor da sessão preservada para mim. O teste que você deve repetir é mais simples: desconecte, retorne e confira processo, saída e arquivo. Assim, fechar o notebook vira uma mudança de tela, não uma suposição sobre o servidor.