Pular para o conteúdo
    Guia · Nível IntermediárioProgramação e desenvolvimento

    Como sincronizar e retomar sessões de agentes de IA entre máquinas com o Atuin Threads

    Aprenda a configurar o Atuin Threads para capturar, criptografar, buscar e retomar conversas de agentes como Claude Code e Codex em diferentes computadores.

    Monitor de computador desktop e notebook lado a lado em uma mesa escura, exibindo o mesmo código em janelas de terminal e conectados por fios de luz sob iluminação azul e laranja.
    O Atuin Threads permite sincronizar e continuar sessões de agentes de IA no terminal entre diferentes máquinas.
    Neste artigo

    Comandos digitados no terminal atravessam diferentes máquinas há anos por meio de ferramentas de sincronização, mas as sessões de agentes de codificação costumavam ficar presas na pasta local onde foram iniciadas. Este guia mostra como configurar o Atuin Threads (abre em nova aba) para capturar, criptografar, buscar e retomar sessões de agentes de inteligência artificial entre múltiplos ambientes de trabalho. O recurso está disponível a partir da versão 18.24 do Atuin, opera de forma opcional (opt-in) e permite tanto o uso do servidor de sincronização oficial quanto a hospedagem própria (self-hosting) ou o armazenamento estritamente local.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​‌‌​​‌​‌​​‌‌​‌​‌​‌‌​​​​‌​‌‌​​​​‌​‌‌​​‌​‌​​‌‌​​‌​​​‌‌​​‌‌​​‌‌​‌​‌​​‌​‌‌​‌​‌‌​​​‌‌​​‌‌‌​​​​​‌‌​‌‌‌​​‌‌​​​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌​​​‌‌​​​‌​‌‌​​​​‌​​‌​‌‌​‌​​‌‌‌​​‌​‌‌​​​‌​​​‌‌‌​​‌​​‌‌‌​​‌​​‌​‌‌​‌​‌‌​​‌‌​​‌‌​​‌​‌​​‌‌​​​​​​‌‌​​‌​​‌‌​​​​‌​​‌‌​‌​​​‌‌​​​​‌​​‌‌‌​​‌​​‌‌​​​‌​‌‌​​​​‌​‌‌​​​‌‌​​‌‌​​​‌⁠

    Quando um desenvolvedor inicia uma refatoração usando o Claude Code em um servidor remoto de desenvolvimento e, horas depois, abre o notebook para continuar a mesma tarefa dentro do Codex sem perder o contexto das tentativas anteriores, ele está fazendo o fork e a retomada de sessão entre diferentes interfaces de agentes (chamadas tecnicamente de harnesses). O histórico tradicional do shell registra o comando exato que rodou, mas omite o raciocínio; a sessão do agente guarda a intenção, os erros intermediários e as saídas em texto claro, mas perdia a portabilidade assim que o usuário trocava de máquina ou de máquina virtual efêmera.

    Como funciona a arquitetura de sincronização

    À primeira vista, sincronizar conversas inteiras de múltiplos assistentes de IA parece exigir uma infraestrutura separada daquela usada para salvar linhas avulsas do .bash_history. Na prática, o Atuin reutiliza o mesmo motor de sincronização criptografado de ponta a ponta (E2EE, na sigla em inglês, onde os dados saem cifrados do dispositivo de origem e o servidor intermediário não possui a chave de leitura). Segundo Ellie Huxtable no blog oficial do Atuin (abre em nova aba), esse motor foi projetado de forma genérica para lidar com qualquer estrutura modelada como um append-only log (registro somente de anexação, no qual novos eventos são apenas adicionados ao final da fila), formato que corresponde à maneira como a maioria das sessões de IA armazena interações no diretório do usuário.

    Dois monitores lado a lado em um ambiente escuro exibindo linhas de código sincronizadas, conectados por feixes de luz azul e ícones de cadeados digitais.
    O Atuin Threads permite sincronizar o histórico de conversas de agentes de código entre diferentes máquinas com criptografia.

    Essa estrutura compartilhada ganhou validação em observações independentes após o lançamento. Em um teste conduzido pelo engenheiro Tony Wu com a versão 18.24.6 em ambiente Rocky Linux 9 e Podman 5.4.0 (com SELinux em modo Enforcing), verificou-se que o cliente utiliza a mesma chave criptográfica e o mesmo servidor de sincronização, mas divide o tráfego em dois repositórios de registros (record stores) independentes: o canal history, dedicado aos comandos de terminal, e o canal ai-session, exclusivo para o Threads. No teste com servidor próprio, a sincronização entre duas máquinas de 5 comandos de shell e 3 mensagens de Thread levou em média 0,31 segundo ao longo de cinco rodadas.

    Pré-requisitos e agentes compatíveis

    Antes de iniciar a configuração nas máquinas que compartilharão o contexto, confira as exigências do ambiente.

    A cobertura de ferramentas cresceu rapidamente desde o anúncio inicial. Enquanto o comunicado de lançamento listava cinco integrações (Claude Code, Codex, Pi, Omp e OpenCode), a documentação técnica e os registros da versão 18.24.6 abrangem um conjunto maior de harnesses:

    Agente / HarnessIdentificador técnico / CLIArmazenamento originalMétodo de captura pelo Atuin
    Claude Codeclaude-code / claudeDisco localAutomático via daemon e importação local
    CodexcodexDisco localAutomático via daemon e importação local
    OpenCodeopencodeDisco localAutomático via daemon e importação local
    PipiDisco localAutomático via daemon e importação local
    CopilotcopilotDisco localAutomático via daemon e importação local
    Grok BuildgrokDisco localAutomático via daemon e importação local
    KirokiroDisco localAutomático via daemon e importação local
    OmpompDisco localAutomático via daemon e importação local
    Hermes AgentConsta na branch main da docDisco localAutomático via daemon e importação local
    AmpampServidores do AmpRequer instalação de plugin (hook) e flag específica na importação

    Passo a passo: configuração e sincronização entre máquinas

    O procedimento abaixo deve ser executado na máquina onde as sessões são criadas e repetido nos computadores onde você deseja consultá-las ou retomá-las.

    Passo 1: Instalar ou atualizar o Atuin

    Caso ainda não tenha o binário instalado ou esteja em uma versão anterior à 18.24, execute o script oficial de configuração no terminal:

    curl --proto '=https' --tlsv1.2 -LsSf https://setup.atuin.sh | sh

    Se esta for uma instalação nova e você quiser sincronizar dados entre computadores diferentes, certifique-se de estar autenticado na mesma conta de sincronização em ambos os ambientes antes de prosseguir.

    Passo 2: Ativar a captura do Threads e o daemon

    A captura de sessões vem desativada por padrão (capture = false). Para habilitá-la, execute:

    atuin threads enable

    Esse comando é um atalho para atuin config enable threads. Ele realiza três operações simultâneas: grava a diretiva capture = true sob a seção [threads] no seu arquivo config.toml, inicia o daemon do Atuin (caso ainda não esteja rodando) e oferece a opção interativa de importar as sessões que seus agentes já possuem salvas no computador.

    Se você precisar desativar a coleta posteriormente em alguma máquina específica, basta rodar:

    atuin config disable threads

    Passo 3: Importar sessões antigas e configurar exceções (Amp)

    A ativação do recurso registra apenas as sessões em que seus agentes trabalharem a partir daquele momento. Se você pulou a importação inicial ou deseja processar o histórico preexistente manualmente, utilize o comando de importação:

    atuin threads import

    Esse comando varre os diretórios locais dos agentes suportados, mas ignora o agente Amp por padrão. Como o Amp armazena as conversas nos próprios servidores em vez do disco local, tem um passo adicional para quem utiliza essa ferramenta: instalar um plugin que repassa os turnos ao Atuin em tempo real.

    Para configurar o Amp, instale o hook, reinicie o agente e faça a importação explícita dos registros remotos:

    atuin hook install amp
    # Reinicie o Amp após este comando e execute a importação dedicada:
    atuin threads import --harness amp

    Para integrações customizadas, o Atuin também dispõe do subcomando atuin threads push --harness <agent> --session <id>, que aceita o envio direto de mensagens formatadas no padrão da ferramenta.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​‌‌​​‌​‌​​‌‌​‌​‌​‌‌​​​​‌​‌‌​​​​‌​‌‌​​‌​‌​​‌‌​​‌​​​‌‌​​‌‌​​‌‌​‌​‌​​‌​‌‌​‌​‌‌​​​‌‌​​‌‌‌​​​​​‌‌​‌‌‌​​‌‌​​​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌​​​‌‌​​​‌​‌‌​​​​‌​​‌​‌‌​‌​​‌‌‌​​‌​‌‌​​​‌​​​‌‌‌​​‌​​‌‌‌​​‌​​‌​‌‌​‌​‌‌​​‌‌​​‌‌​​‌​‌​​‌‌​​​​​​‌‌​​‌​​‌‌​​​​‌​​‌‌​‌​​​‌‌​​​​‌​​‌‌‌​​‌​​‌‌​​​‌​‌‌​​​​‌​‌‌​​​‌‌​​‌‌​​​‌⁠

    Passo 4: Retomar ou transferir sessões entre agentes

    Com o daemon ativo e a sincronização operando, abra o terminal na segunda máquina. Para abrir a interface visual de terminal (TUI, sigla para Text User Interface) e escolher uma conversa anterior, execute:

    atuin resume

    (Nota: se você rodar atuin resume em uma máquina onde a captura ainda estiver desligada, a própria ferramenta oferecerá a ativação e a importação no ato).

    Dentro da interface, você pode selecionar uma sessão iniciada em outro computador e retomá-la no mesmo agente ou fazer um fork para outro harness instalado localmente (por exemplo, abrir no Codex uma investigação iniciada no Claude Code). Por padrão, a configuração capture_tools = true garante que a sessão retomada mantenha o histórico do que foi enviado a cada ferramenta, o retorno obtido e o diff de cada edição de arquivo realizada.

    Passo 5: Conectar o servidor MCP aos agentes

    Sincronizar arquivos resolve metade do problema; a outra metade é evitar que você precise explicar manualmente ao agente o que foi tentado na semana anterior. O Atuin inclui um servidor de Model Context Protocol (MCP, protocolo aberto que permite a modelos de linguagem consultar fontes de dados externas de maneira padronizada) acessível pelo comando atuin mcp.

    Para instalar e conectar automaticamente o servidor MCP aos seus agentes, execute o comando correspondente às ferramentas que você utiliza:

    atuin mcp install claude/codex/pi/opencode

    Com o MCP ativo, o próprio agente ganha autonomia para pesquisar sessões antigas quando recebe uma tarefa. No relato publicado pela equipe do Atuin, essa capacidade permitiu dois fluxos práticos: recuperar tentativas de código de onboarding que foram descartadas antes de chegar à branch main (evitando repetir abordagens que já haviam falhado) e acelerar a resolução de um incidente de permissão em chaves do serviço de armazenamento Tigris, no qual um agente acionado com uma pergunta curta localizou sozinho a triagem feita horas antes por outro agente conectado ao Sentry.

    Você pode aproveitar essa integração diretamente nos seus comandos diários ao agente:

    Prompt para investigação baseada em sessões anteriores via Atuin MCP

    Use este prompt em um agente com o servidor MCP do Atuin instalado (Claude Code, Codex, Pi ou OpenCode) para retomar implementações abandonadas ou cruzar diagnósticos de incidentes.

    • [tema_ou_erro]: Nome da funcionalidade, módulo ou mensagem de erro que já foi investigada no passado
    • [objetivo_atual]: O que você deseja implementar ou corrigir agora
    Consulte o histórico de sessões do Atuin para buscar investigações e tentativas anteriores relacionadas a [tema_ou_erro]. Identifique quais abordagens já foram testadas, por que foram descartadas ou qual foi a causa raiz apontada nos logs anteriores, e use esse contexto para [objetivo_atual] sem repetir os passos que falharam.

    Como verificar o funcionamento

    Para confirmar que a captura local e a sincronização entre máquinas estão operando conforme o esperado, utilize os comandos de inspeção da CLI em um segundo terminal ou em outro dispositivo conectado à mesma conta:

    1. Listagem e acompanhamento: execute atuin threads para listar, exibir e acompanhar (follow) as sessões registradas no armazenamento local e sincronizadas.
    2. Teste de busca indexada: faça uma pesquisa por um termo discutido em uma sessão recente usando o subcomando search:
    atuin threads search "migration"

    Ajustes de privacidade, limites e solução de problemas

    Em equipes que lidam com bases de código sensíveis ou repositórios extensos, registrar o conteúdo integral de todas as edições de arquivos pode ser indesejado, seja por políticas de governança ou pelo volume de dados sincronizados. É possível instruir o Atuin a gravar apenas o nome de cada ferramenta acionada pelo agente e o status de sucesso ou falha da chamada, descartando os parâmetros completos e os diffs de código.

    Para aplicar essa restrição, edite seu arquivo config.toml e defina capture_tools = false na seção [threads]:

    [threads]
    capture = true
    capture_tools = false

    (Em versões anteriores à introdução do bloco [threads], essas chaves se chamavam capture_sessions e capture_tools dentro da seção [ai]; a documentação informa que o formato antigo continua funcionando caso o bloco [threads] não esteja declarado no arquivo).

    Sobre limites operacionais e problemas conhecidos, considere os seguintes pontos documentados:

    • Descompasso de versões iniciais: se os diffs de edição de shell gerados pelo Claude Code não estiverem aparecendo nas sessões retomadas ou se um agente aparecer listado com o nome de outro harness, verifique a versão instalada com atuin --version. Esses dois bugs específicos foram corrigidos no lançamento da versão 18.24.6.
    • Custos e cotas de armazenamento: a documentação técnica analisada e o anúncio oficial não divulgam tabelas de preços, limites de espaço em megabytes para o canal ai-session no servidor hospedado pelo Atuin nem restrições específicas para uso comercial. Caso sua operação tenha restrições quanto a cotas externas ou conformidade de dados, a alternativa documentada é hospedar o próprio servidor de sincronização do Atuin ou manter os dados apenas na máquina local.
    • Diferença entre Atuin Threads e Atuin AI: não confunda a seção [threads] com a seção [ai] (enabled = true) do config.toml. O bloco [ai] controla os recursos de sugestão interativa da própria linha de comando do Atuin (que exigem a configuração adicional de pty-proxy para ler saídas do terminal), enquanto o Threads atua estritamente na captura e sincronização das sessões dos seus agentes externos.

    Verificação rápida do ambiente Atuin Threads

    • Atuin atualizado para a versão 18.24 ou superior (preferencialmente 18.24.6+) em todas as máquinas.
    • Captura habilitada via atuin threads enable e processo daemon em execução.
    • Sessões antigas importadas com atuin threads import (e flag --harness amp com hook instalado, se usar Amp).
    • Parâmetro capture_tools ajustado no config.toml de acordo com a política de privacidade de diffs do projeto.
    • Servidor MCP conectado aos agentes locais via atuin mcp install para permitir consultas autônomas ao histórico.
    • Busca testada na segunda máquina usando palavras completas com atuin threads search.

    Enquanto a configuração atual resolve a fragmentação de contexto para o desenvolvedor individual que alterna entre servidores e computadores pessoais, o próximo passo anunciado pela criadora do projeto é permitir o compartilhamento opcional de sessões entre membros de uma mesma equipe, tratando o histórico de raciocínio de um agente como uma branch de código que um engenheiro pode transferir para outro continuar o trabalho.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​‌‌​​‌​‌​​‌‌​‌​‌​‌‌​​​​‌​‌‌​​​​‌​‌‌​​‌​‌​​‌‌​​‌​​​‌‌​​‌‌​​‌‌​‌​‌​​‌​‌‌​‌​‌‌​​​‌‌​​‌‌‌​​​​​‌‌​‌‌‌​​‌‌​​​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌​​​‌‌​​​‌​‌‌​​​​‌​​‌​‌‌​‌​​‌‌‌​​‌​‌‌​​​‌​​​‌‌‌​​‌​​‌‌‌​​‌​​‌​‌‌​‌​‌‌​​‌‌​​‌‌​​‌​‌​​‌‌​​​​​​‌‌​​‌​​‌‌​​​​‌​​‌‌​‌​​​‌‌​​​​‌​​‌‌‌​​‌​​‌‌​​​‌​‌‌​​​​‌​‌‌​​​‌‌​​‌‌​​​‌⁠

    Este conteúdo foi útil para você?

    Filipe Mendes

    Ver perfil completo