Retomar o chat não é retomar o trabalho do agente
Imagine uma tarefa pequena: corrigir a mensagem de erro de um formulário React. O agente altera o componente, abre uma prévia local e começa a verificar o comportamento. Você fecha a interface e volta depois.
O histórico está lá, inclusive a última mensagem: "Vou testar agora". Dá vontade de escrever "pode continuar" e seguir o dia.
Só que essa mensagem não diz se o teste terminou. Também não confirma que a prévia aberta corresponde aos arquivos atuais ou que o processo continua ativo. Antes de pedir mais código, eu conferiria o ponto em que o trabalho realmente parou.
O que um terminal persistente ajuda a recuperar
O OpenCode 2.2.4 trouxe uma mudança útil para esse cenário: os terminais do Desktop passaram a pertencer à sessão, com histórico de saída e nomes preservados após reinícios do servidor, sincronizados com o TUI e outras janelas. A mudança usa PTYs persistentes. PTY é um pseudoterminal, uma interface do sistema operacional que permite a um programa funcionar como se estivesse conectado a um terminal.
Isso ajuda a evitar que a continuidade do terminal dependa de uma única janela. Ainda assim, a recuperação documentada não equivale a garantir que qualquer processo sobreviva a um reinício da máquina. E recuperar o histórico de saída não demonstra, por si só, que o servidor de desenvolvimento está rodando agora.
Vale separar esse recurso da capacidade do modelo. O harness é a camada ao redor dele que organiza instruções, contexto, ferramentas e ambiente de execução. É nessa camada que entram decisões sobre persistência e reconexão. Escolher um modelo com mais contexto não resolve automaticamente o ciclo de vida do terminal.
A tarefa ficou espalhada por lugares diferentes
No exemplo do formulário, parte do trabalho está na conversa: o pedido, o plano e as decisões tomadas. Outra parte está nos arquivos, talvez com alterações ainda não commitadas. A prévia depende de um processo. Se houver um serviço externo envolvido, o acesso a ele depende das integrações e permissões atuais.
Essas partes podem estar em situações diferentes quando você volta. O chat pode ter sido recuperado corretamente enquanto a prévia parou. O terminal pode mostrar um teste aprovado que aconteceu antes da última edição. Outra janela pode ter alterado o mesmo projeto.
Uma retomada útil precisa deixar claro qual dessas situações você encontrou. "Lembro do que estávamos fazendo" ajuda na conversa, mas ainda falta conferir o projeto.
Para experimentar isso sem colocar trabalho importante em risco, use um projeto descartável e dados sintéticos. A tarefa pode ser a mesma do exemplo: ao simular uma falha no envio do formulário, a interface deve mostrar uma mensagem compreensível e permitir uma nova tentativa. Essa é uma proposta de teste, não um resultado obtido neste artigo.
Faça uma interrupção pequena e confira a volta
Antes de começar, registre o diretório do projeto, a branch, a revisão-base e as alterações que já existem. Inclua arquivos novos e mudanças que já estejam na área de preparação do Git. Assim, fica mais fácil distinguir o que o agente fez do que já estava lá.
Anote também o critério de aceite e o identificador da sessão, se a ferramenta o oferecer. Pode ser uma ficha curta:
Tarefa: corrigir a mensagem de erro do formulário.
Aceite: a falha simulada aparece na tela e é possível tentar novamente.
Diretório, branch e revisão-base: preencher antes do início.
Alterações já existentes: preencher antes do início.
Sessão: registrar o identificador disponível.
Prévia: registrar endereço e processo responsável, quando disponível.
Verificações: registrar o que terminou e quais alterações foram verificadas.
Próxima ação pendente: preencher antes da interrupção, se possível.
Feche apenas a interface e reabra a mesma sessão. Não mate o processo do agente nem reinicie a máquina nesse primeiro ensaio: você estaria testando outra condição. Um reinício do servidor pode virar um segundo teste, separado, quando houver um procedimento documentado para a ferramenta.
Na volta, confira:
- Se você está na mesma sessão e se a próxima ação ainda faz sentido. Uma decisão tomada em outra janela pode ter mudado a tarefa.
- Se o diretório, a branch, a revisão e o diff correspondem ao trabalho esperado. Branch e worktree ajudam a organizar alterações; não são uma barreira de segurança.
- Se a prévia responde no endereço esperado e pertence ao projeto e ao processo corretos. Uma porta aberta pode estar servindo outra aplicação; um log antigo pode ser só histórico.
- Quais verificações terminaram e sobre quais alterações elas rodaram. Se os arquivos mudaram depois, aquele resultado não cobre automaticamente o estado atual.
- Se as integrações necessárias continuam disponíveis com as permissões adequadas à tarefa. Não reconecte serviços nem amplie acesso só para preencher a lista.
No formulário, eu voltaria à tela, provocaria a falha com dados de teste e verificaria a mensagem e a possibilidade de tentar novamente. Se a prévia não estiver disponível, primeiro identificaria o processo e usaria o procedimento de inicialização do projeto. Abrir outro servidor sem conferir o anterior pode deixar duas prévias e tornar a checagem mais confusa.
O objetivo é conseguir registrar algo específico, como "arquivos recuperados, prévia recriada, verificação ainda pendente", em vez de apenas "a sessão voltou". Preencha isso com o que você observar; a ferramenta pode preservar algumas partes e precisar reconstruir outras.
Quando o resultado ficou desconhecido, não repita no automático
Há uma diferença entre saber que uma ação falhou e não saber se ela terminou. Se a interface caiu durante uma gravação em um serviço externo, reenviar a ação pode duplicar o efeito. Antes de repetir, consulte o estado no destino ou outro registro confiável da operação.
No ensaio local, prefira ações conhecidamente seguras de repetir. Isso permite avaliar a recuperação sem misturar o teste com o risco de uma operação real. Também vale olhar o que a ferramenta conserva: histórico de terminal pode guardar saída sensível e detalhes de tarefas antigas. Persistir mais estado exige cuidado com o que fica salvo.
Para a próxima tarefa pequena com um agente, experimente fechar só a interface uma vez e anotar o que foi preservado, recriado ou perdido. Se você conseguir identificar os arquivos atuais, a situação da execução e a próxima verificação necessária, terá uma base melhor para mandar continuar.