Para que dois agentes de IA compartilhem contexto no nodeterm, você desenha uma linha entre eles. Cada agente é um nó em um canvas infinito, e traçar uma aresta de um para outro dá ao segundo uma ferramenta com a qual pode ler a transcrição, o resumo ou a saída recente do terminal do primeiro. nodeterm é um gerenciador de terminais baseado em nós para macOS e Linux. Claude Code, Codex, Gemini e opencode podem ser conectados assim.
Essa função se chama Context Link, e é o motivo para conferir nodeterm. Rodar quatro agentes em paralelo não é difícil: tmux o faz há anos. O difícil é que cada um inicia sem nenhuma informação. O agente que faz a migração não faz ideia do que descobriu o agente que acabou de ler o schema, e você acaba sendo o barramento de mensagens, copiando e colando entre painéis. Context Link transforma o canvas nesse cabeamento.
O que é nodeterm?
nodeterm é um gerenciador de terminais baseado em nós, construído com Electron, TypeScript e React Flow. Em vez de uma barra de abas, você tem um canvas com pan e zoom onde cada nó é um terminal real respaldado por PTY, uma sessão de agente, um editor Monaco, uma visualização de diff do git, um painel de chat, uma nota adesiva ou um frame de grupo.
Um nó de agente não reimplementa nada. De acordo com a documentação, “um nó de agente é um preset de terminal que lança a CLI de um agente de código como comando de inicialização, e depois acompanha o que o agente está fazendo no cabeçalho do nó”. Os quatro integrados lançam claude, codex, gemini e opencode respectivamente: o que você já tiver em seu PATH.
O badge de status merece uma nota por como está resolvido. nodeterm “não analisa a saída do agente para adivinhar o que está fazendo”. O sistema de hooks de cada agente publica em um pequeno servidor HTTP loopback dentro de nodeterm quando um turno começa, uma ferramenta é executada, o trabalho termina ou o agente volta a esperar. É por isso que os badges são precisos e não uma heurística sobre stdout raspado.
Como funciona o Context Link?
Você desenha uma aresta entre dois nós de agente integrados: a mesma aresta visual que você já usa para organizar o canvas. A documentação é direta: “Context Link conecta nós no canvas para que um agente possa ver o que outro nó sabe”. O link pode ser unidirecional ou bidirecional.
O que o agente linkado pode recuperar são três coisas: a transcrição (o histórico completo da conversa), um resumo (uma versão condensada) e a saída recente do terminal (o stdout dessa sessão).
O mecanismo importa mais que a lista de recursos. É pull, não push: “a leitura é pull, não push; nenhum agente é forçado a receber o histórico do outro”. Cada agente recebe um helper que pode invocar quando decide que o outro nó é relevante — uma skill invocável no caso de Claude, e instruções que descrevem como chegar ao link nos outros. Nada é injetado na janela de contexto de ninguém por sua conta, que é a diferença entre um link útil e uma conta de tokens.
Como usar Claude Code, Codex e Gemini no mesmo projeto?
Você abre uma pasta como projeto e adiciona um nó por agente. Cada nó roda a CLI que você já tem instalada, com sua própria sessão e suas próprias credenciais; nodeterm não faz proxy nem traduz nada entre eles.
O padrão que torna isso vale a pena é dividir por função em vez de por tarefa. Um nó de leitura que explora o repositório e responde perguntas sobre o schema ou a arquitetura. Um nó de escrita que faz as mudanças. Uma aresta do segundo para o primeiro, e quem escreve consulta quem leu quando precisa, em vez de percorrer o código novamente sozinho.
Aí é onde aparece a vantagem concreta: o trabalho de exploração é pago uma única vez. Sem o link, cada novo agente repete o mesmo reconhecimento do repositório e o cobra em tokens.
Se você se interessa pelo problema de mover trabalho entre vários agentes, já cobrimos duas abordagens distintas: OmniRoute, que aponta para um runtime universal, e Cross-Code Organizer, que resolve a organização de um dashboard.
Quais agentes podem ser conectados?
Apenas os quatro integrados: Claude Code, Codex, Gemini e opencode. A documentação é explícita: “apenas nós de agente integrados podem ser linkados como fontes de contexto. Agentes personalizados e terminais normais não podem ser lidos assim”.
Então se você envolveu sua própria CLI como um nó de agente personalizado, ou quer que um agente leia o que um terminal de build tem estado a imprimir, Context Link não é o caminho. É um limite real e é a primeira coisa a verificar antes de projetar um fluxo de trabalho em torno disso.
A capacidade também não é uniforme entre os quatro. Claude Code tem a integração mais ampla: visualização de subagentes, conversas ramificadas, nós de chat, contas gerenciadas e modos de permissões. Os outros três têm detecção de status por hooks, retomada após reinicialização e link de contexto, mas não o resto.
O que contribuem os subagentes e as conversas ramificadas?
Duas mecânicas de contexto relacionadas, ambas do lado de Claude.
Quando Claude lança subagentes, “nodeterm mostra cada um como um card efêmero conectado por uma aresta ao nó do agente pai”, com o tipo e a tarefa do subagente, se está trabalhando ou terminou, sua duração, seus tokens e sua contagem de uso de ferramentas. Cuidado: isso é visualização de algo que Claude Code já faz por conta própria. A documentação não descreve uma troca de dados própria de nodeterm entre pai e filho, então não assuma que existe.
Ramificar é diferente e sim move contexto. Ramificar uma conversa de Claude “abre um novo nó que retoma a conversa original: o novo nó continua o fio assim como estava antes da divisão”. Você termina com duas sessões ativas no canvas que compartilham tudo até o ponto de corte e divergem a partir daí. É a forma barata de testar uma segunda abordagem sem perder a primeira.
Como instalar nodeterm no Mac e Linux?
No macOS, baixe o .dmg de nodeterm.dev — o site detecta se você tem Apple Silicon ou Intel —, abra-o, arraste nodeterm para Aplicativos e lance-o. Não há comandos posteriores.
No Linux, o caminho recomendado é o AppImage, porque se autoatualiza:
chmod +x nodeterm-*.AppImage
./nodeterm-*.AppImage
O .deb é a alternativa e não se atualiza sozinho:
sudo apt install ./nodeterm-*.deb
Depois abra um projeto: na tela de boas-vindas escolha Open folder e selecione seu diretório de trabalho. Clique com o botão direito em um ponto vazio do canvas, ou pressione o + do dock inferior, e escolha terminal — ou um nó de Claude, Codex, Gemini ou opencode, que são adicionados exatamente da mesma forma. ⌘K abre a paleta de comandos para criar nós, saltar para um por título ou label, e mudar de projeto.
Por que você precisa de tmux?
Porque sem ele a promessa de persistência não é cumprida. A documentação é direta: a continuidade de sessão depende de tmux e “sem ele, um terminal é um shell comum que termina quando seu nó é fechado”.
Com tmux em seu PATH, os terminais rodam dentro de sessões de tmux que sobrevivem à aplicação: você fecha nodeterm, reinicia a máquina, reabre o projeto e o trabalho longo ainda está lá. É a propriedade mais útil da ferramenta e também a que falha silenciosamente se você pulou a dependência. Execute which tmux antes de culpar a app.
nodeterm funciona no Windows?
Não. A documentação lista apenas macOS (Apple Silicon ou Intel) e Linux (x64), e não há build para Windows. A alternativa que aponta é a Server Edition: rodar nodeterm headless em uma máquina Linux e acessar o canvas do navegador. WSL não aparece mencionado como um caminho suportado.
nodeterm é open source?
Não no sentido do OSI. A licença é BUSL-1.1, a Business Source License. O código é público no GitHub e você pode lê-lo, modificá-lo e usá-lo em produção; o que você não pode é oferecê-lo como serviço concorrente. Cada release passa para MIT quatro anos depois de publicado.
Para a maioria dos leitores essa distinção é acadêmica: você instala e usa no trabalho hoje. Se você precisa passar dependências por questões legais, ou está decidindo se construir em cima disso, não é acadêmica em absoluto — e o enquadramento de „gerenciador de terminais open source