Talvez você não precise de tmux: como substituir o tmux no fluxo de trabalho de desenvolvimento

• O autor usou tmux por muito tempo, mas recentemente passou a questionar sua complexidade e limitações, como compatibilidade de cores, scrollback, cópia com mouse e falta de suporte a protocolos
• Recursos principais do tmux, como persistência de sessão (detach/attach) e divisão/gerenciamento de janelas, não são necessariamente exclusivos do tmux
• Usando ferramentas leves inspiradas na filosofia Unix, como dtach, abduco e shpool, é possível focar apenas no gerenciamento de sessão e ainda manter scrollback nativo e simplicidade
• Em especial, com a combinação de shpool + ssh, é possível gerenciar várias sessões remotas diretamente pelo gerenciador de janelas, mantendo intactos recursos nativos como notificações, rolagem e títulos
• Não é uma solução perfeita, mas, para o autor, foi possível substituir completamente o tmux e obter satisfação com um workflow simples e fácil de manter

---

Vantagens e desvantagens do tmux

• Recursos como manutenção de sessão (detach/attach) e gerenciamento de janelas (abas, split) eram o núcleo do workflow oferecido pelo tmux
• Porém, sem a configuração correta de TERM, surgem problemas de renderização de cores, e a necessidade de considerar a interação entre o terminal e o tmux aumenta a complexidade
• O uso do buffer de rolagem também exige se acostumar com o modo próprio do tmux, e copiar áreas com o mouse em um ambiente com splits também era incômodo
• Há também suporte insuficiente a novos recursos de terminal, como o kitty graphics protocol, além da falta de suporte a protocolos experimentais
• Também existe a crítica de que, ao reinterpretar códigos de escape duplicadamente e impor os conceitos de sessão/janela, o multiplexador atrapalha a evolução do ecossistema de terminais

Explorando formas de substituir o tmux

• Persistência de sessão:
  • Há opções simples como ctrl-z + fg, nohup e disown, mas é difícil considerá-las um substituto completo
  • Surgiram várias ferramentas voltadas apenas para manter a sessão (dtach, abduco, shpool)
    • Elas usam uma combinação de fork() e sockets UNIX para conectar daemon e cliente
    • Ao contrário do tmux, oferecem scrollback nativo sem splits virtuais, e algumas também restauram buffers
  • Na experiência do autor, a maioria das alternativas tinha bugs e problemas de acabamento, como teclas de detach que não funcionavam dentro do nvim
  • Apenas o shpool pareceu mais maduro em termos de comandos de detach/attach e personalização de keymap
• Gerenciamento de janelas:
  • No ambiente local, o gerenciamento de divisão e posicionamento fica por conta do gerenciador de janelas
  • Mesmo em ambiente remoto (SSH), é possível combinar ssh_config com shpool para manter várias sessões de forma independente em janelas separadas
  • Em conjunto com autossh, também é possível manter as sessões mesmo em cenários de reconexão de rede

Novo workflow

• Pessoalmente, o autor usa ghostty (no notebook) e sway+foot (no PC pessoal) para gerenciar janelas. O servidor roda em uma VM headless baseada em Proxmox, mantendo sempre um ambiente de desenvolvimento via SSH
• Várias sessões do shpool são conectadas automaticamente por atalhos ssh e controladas de forma independente no gerenciador de janelas local
  • No ssh_config, o attach às sessões do shpool é automatizado para cada host
  • É possível acessar separadamente múltiplas sessões, como IRC, gerenciamento de dotfiles e um ambiente específico de neovim, em cada terminal
• Recursos como rolagem nativa, notificações e título do terminal, que o tmux suportava de forma instável, passam a funcionar de maneira mais natural
• Também há desvantagens: ao reconectar no vim, a restauração do estado do terminal demora, e há problemas de redimensionamento ao usar nvim
  • Não há suporte a multiplayer (se vários clientes iniciarem autossh ao mesmo tempo, as sessões entram em conflito)
• Ainda assim, para o autor, a substituição completa do tmux foi bem-sucedida

Conclusão

• Não é algo totalmente idêntico, mas é possível migrar para um workflow de gerenciamento de sessões simples e flexível, deixando para trás a complexidade e as limitações do tmux
• Dependendo do workflow de cada pessoa, vale a pena considerar ferramentas alternativas como shpool

[egirlasm]

Hoje em dia, a gente usa IA para gerar coisas como o tmux e sair usando. Com xterm.js + react + electron, em 3 ou 4 horas dá para criar umas 100 coisas dessas, e se precisar ajustar em tempo real e usar, é tipo comer shabu-shabu? Você coloca o que quiser e o código fonte vem bem servido.

[barca105]

Estou usando com conforto no wezterm.

[iolothebard]

Screen é bom demais!

[helio]

cargo install shpool... acho que vou continuar usando tmux... precisa ter pacotes para cada sistema operacional!

[mineboo]

Existe o Zellij, uma revelação excelente. Recomendo muito.

[xguru]

Zellij - terminal para desenvolvedores & Ops

Também postei isso há bastante tempo, haha

[GN⁺]

Comentários do Hacker News

• Este post é voltado para usuários de Linux no desktop, mas quero destacar que o tmux realmente brilha quando usado com o iTerm2 no MacBook
  Graças à integração do iTerm2 com o tmux, ele se encaixa de forma completamente natural no meu fluxo de trabalho
  Se você configurar o ~/.ssh/config como abaixo, pode sempre acessar facilmente seu servidor remoto de desenvolvimento via ssh e tmux, mesmo depois de ligar o MacBook de novo ou trocar de rede
  Com a integração entre iTerm2 e tmux, abas remotas do tmux e o buffer de rolagem funcionam como se fossem abas locais e, na prática, dá até para usar sem saber os comandos do tmux

  • Eu uso Linux em todos os meus equipamentos pessoais e trabalho principalmente em um MacBook, então o tmux é realmente útil por reproduzir o mesmo ambiente de forma independente da plataforma
    No Linux eu uso Alacritty, mas no macOS sempre aparece algum detalhe que não funciona logo de cara por causa de configuração, janela/rolagem e outras diferenças
    Não quero gastar tempo com essas diferenças entre sistemas, então a combinação de tmux com iTerm2 é ótima porque me dá uma experiência quase idêntica à do Linux
    Para mim, também é uma vantagem ter o scrollback separado por sessão
    Acho que as críticas ao tmux dizem mais respeito a problemas para desenvolvedores de terminais
    Se o suporte for ruim, é só migrar para um terminal que ofereça suporte melhor

  • Eu uso a combinação de mosh com screen
    Consigo restaurar a sessão mesmo se o servidor reiniciar, e a sessão não cai quando mudo de rede
    Referência: Immortal SSH Sessions

  • Já tentei usar tmux dezenas de vezes, mas nunca gostei muito e sempre acabava voltando para o screen
    Mas essa dica me deu vontade de tentar de novo

  • Eu esbarro com frequência em problemas de cor e fonte na combinação vim + tmux + iTerm2, e no fim acabei desistindo do tmux localmente
    Não era algo que sobrevivesse bem a atualizações, e o ganho com persistência de sessão não era tão grande
    Se eu resolver os problemas de fonte, toparia tentar de novo, mas no momento estou sem tempo

  • Fico curioso se existe algum terminal para Linux com integração com tmux como a do iTerm2
    Ainda uso GNU Screen, mas estaria disposto a dar outra chance ao tmux

• Esse post de blog me fez perceber mais uma vez por que eu uso tmux
  Ver as pessoas tendo que fazer um monte de coisas para recriar um fluxo de trabalho parecido com o do tmux só me faz pensar que é muito melhor simplesmente usar tmux
  Às vezes copiar e colar é um pouco incômodo, mas não ligo muito para isso
  A crítica de que “um multiplexador cria overhead desnecessário” é algo com que ninguém precisa se preocupar, a menos que mantenha a base de código

  • O problema de copiar e colar não é exclusivo do tmux
    Qualquer app que desenhe a tela inteira do terminal por conta própria, como o vim, pode ter isso
    Dá para resolver isso facilmente com a sequência de escape de terminal OSC52
    Se você usar um script simples em Python, também pode mandar direto para a área de transferência do sistema coisas como resultados de grep
    tmux e nvim já suportam OSC52, e isso também é fácil de aproveitar em outros lugares

  • Só para constar, eu já enviei um PR para o tmux e gostei bastante da forma como o mantenedor Nick Marriott se comunica
    O código também é bem organizado, e o tmux ficou melhor por causa disso

  • Estou cansado dessas discussões que parecem inventar problemas onde eles não existem
    Não acho convincentes os motivos apresentados pelo autor e, sinceramente, até fico em dúvida sobre a suposta “experiência de mais de 7 anos com tmux” dele

• Conheci o Tmux há algumas semanas e fiquei fascinado com a possibilidade de criar scripts que enviam teclas programaticamente para um pane específico
  Inspirado por um fórum japonês, comecei a pensar se o Claude Code (doravante CC) poderia interagir diretamente com scripts CLI que exigem interação, e confirmei que isso dá para fazer usando Tmux
  Então criei uma pequena ferramenta chamada claude-code-tools, que permite a agentes CLI como o CC criar panes do Tmux, executar scripts neles e até interagir em tempo real
  É como uma versão para terminal do Playwright ou do Puppeteer
  Link do GitHub do claude-code-tools
  Com esse método, o CC pode automatizar testes de scripts CLI interativos, abrir uma UI em outro pane e testar no navegador com Puppeteer MCP, ativar um depurador e parar em breakpoints, integrar múltiplos agentes e muito mais
  Fico curioso para saber se ferramentas alternativas ao tmux conseguiriam oferecer essa mesma extensibilidade

  • Só para constar, o screen também consegue enviar teclas programaticamente para um pane usando o comando “stuff”

  • Com esse método, o Claude Code consegue controlar várias instâncias de CC, como Gemini CLI e OpenCode, em modo interativo
    Isso permite um tipo de integração diferente do modelo tradicional de subagentes

  • Fico curioso se um wrapper de tmux-cli realmente ajuda a melhorar os resultados
    No meu caso, basta dizer ao Claude para usar os comandos existentes do tmux que tudo funciona bem, então faço todos os comandos rodarem dentro de uma sessão tmux sem nem precisar de Bash à parte

  • Se você quiser fazer esse tipo de coisa com mais facilidade no nível do terminal, o recurso de remote control do Kitty também é muito legal
    Introdução ao Kitty Remote Control

  • No fim das contas, um terminal é essencialmente só um descritor de arquivo, então ferramentas parecidas como script(1), expect(1) e chat(8) já existem desde os anos 80
    Não é obrigatório usar tmux

• O problema de cores e afins não aparecerem corretamente no tmux quando o TERM não está configurado direito é o mesmo que acontece com qualquer emulador de terminal ou programa
  Nos sistemas Unix e Linux, os próprios conceitos de TERM e terminfo/termcap são fundamentais, então a configuração correta é indispensável
  Isso não é um problema exclusivo do tmux

  • Ainda assim, é uma pena ver o autor jogando a culpa no tmux
    Também fico em dúvida se o problema de rolagem é realmente do tmux, já que o tmux usa alternate screen buffer, algo introduzido para deixar clara a linha de base da viewport e facilitar o movimento do cursor
    A maioria dos terminais modernos permite rolagem local mesmo no alternate screen, então essa característica acaba não sendo respeitada como deveria

  • A maioria dos programas também não funciona como esperado se a configuração padrão não estiver correta
    No caso do tmux, é desconfortável porque o “porquê” não aparece de imediato, mas não está claro qual seria a solução ideal, como por exemplo definir o padrão como 256colors

  • É verdade, mas ao usar tmux você adiciona mais uma camada com a qual precisa se preocupar
    Dentro do tmux, você precisa usar um TERM específico do tmux; fora dele, precisa usar o TERM apropriado ao seu terminal
    Só de olhar o FAQ do tmux já dá para ver que a maioria dos problemas de exibição vem de TERM mal configurado

• A crítica de que “um multiplexador adiciona overhead desnecessário” é justamente um dos motivos de eu preferir tmux
  Num cenário em que cada vez mais apps abandonam o suporte a termcap, o tmux me permite continuar executando aplicativos até mesmo em terminais antigos como meu VT520
  Não me importo muito se algum desenvolvedor de terminal não gosta de tmux
  No fim, para o usuário, o que importa é funcionar bem, não a elegância arquitetural
  Pessoalmente, acho o alacritty melhor, embora eu use mais o Konsole

  • Só queria dizer que invejo você por ter um VT520
    Há muito tempo procuro um VT525, mas é caro e a maioria dos vendedores está no exterior
    Sempre tive curiosidade de saber se o nosh realizer funciona bem em um VT525 genuíno
    Mesmo que o tmux desapareça, ainda dá para transliterar apps com incompatibilidades sutis de TERM de outras formas

  • Meu VT420 não tem suporte a controle de fluxo por hardware, então preciso usar controle de fluxo por software, e esse método não combina muito bem com os apps de terminal de hoje em dia
    O GNU Screen tem sido uma solução excelente para isso, além de oferecer vários outros recursos
    Já usei bastante tmux em emuladores modernos, mas em terminais antigos parece faltar esse importante recurso de controle de fluxo
    Concordo que o tmux é útil para lidar com apps que não suportam termcap/terminfo

  • Fico curioso sobre por que você acha o alacritty melhor
    Em hardware antigo ele inicia mais devagar, carece de recursos práticos como abas e, nos benchmarks, fica atrás de kitty/ghostty/konsole/foot
    Ainda assim, é interessante ver que há gente que usa alacritty por algum motivo específico

• Ainda pretendo continuar usando tmux
  Gosto dele porque facilita o gerenciamento de sessões entre vários projetos e a recuperação das sessões depois de reinicializações
  Nunca tive problema com copiar/colar com mouse usando tmux-yank
  Uso o mesmo ambiente há anos
  Com o recurso send-keys do tmux, automatizei a atualização simultânea de aliases e arquivos de configuração em vários panes/sessões e até o reinício do nvim ao refatorar meus dotfiles
  Reuni essa experiência em um post de blog e vídeo

• Eu vejo a discussão de “you might not need tmux” como algo parecido com “you might not need browser tabs”
  Se você só lida com uma ou duas sessões de terminal ou páginas web, talvez realmente não precise, mas quando passa disso o gerenciamento de janelas fica desconfortável demais e você acaba reimplementando as mesmas funcionalidades

  • Hoje em dia, eu simplesmente tento aproveitar ao máximo os recursos de gerenciamento de janelas do window manager que uso
    Em vez de abas do navegador, abas de terminal ou tmux, deixo o window manager cuidar da disposição das janelas, das abas e dos favoritos, e isso não me incomoda

  • Estou cada vez mais convencido de que o gerenciamento de abas deve ser responsabilidade do window manager, não do aplicativo
    Meu window manager consegue organizar janelas em mosaico ou agrupar janelas sobrepostas em abas
    Essas abas podem ser usadas tanto com o mesmo app quanto com apps diferentes

  • As abas do navegador podem ser facilmente separadas em janelas distintas ou reunidas de novo, mas as abas do tmux são menos flexíveis nesse aspecto
    Um bom window manager permite recombinar abas e janelas livremente

  • Minha configuração do tmux tem abas clicáveis

  • O gerenciamento de múltiplas janelas no MS Windows (Alt Tab, Win Tab etc.) é excelente
    Eu diferencio cada terminal com ícones e cores de fundo, e o próprio sistema operacional faz grande parte do trabalho de gerenciamento de janelas
    Já usei Mac também, mas nesse ponto ele não me satisfaz tanto quanto o Windows

• As reclamações sobre tmux, como scrollback de buffer e afins, acabam sendo justamente o que me faz querer usar tmux
  Meu segundo laptop é uma máquina antiga com Debian dedicada a terminal, sem mouse, então só consigo copiar e colar usando tmux
  Para mim, tmux é insubstituível

  • A combinação tmux capture-pane - | vim - às vezes é mais conveniente do que a roda de rolagem do mouse

• O pessoal do suckless adota a abordagem oposta: ao projetar terminais, decide deliberadamente não implementar recursos do tipo tmux
  Referência: st.suckless.org/goals

  • Dá para dizer que suckless e Kitty são opostos em termos de filosofia de desenvolvimento

• Espero que o Kitty tenha sucesso, porque parece capaz de apontar o futuro dos emuladores de terminal
  Mas eu não consigo usá-lo no trabalho e, sem tmux, perderia sessões, layout de janelas, estado, buffer de cópia e scrollback, então não tenho como abrir mão dele
  Até surgir uma alternativa adequada no Windows, pretendo continuar usando tmux no trabalho, mesmo mantendo o Kitty ao lado

  • Também experimentei Kitty por um tempo, e achei impressionante como ele consegue reproduzir um ambiente parecido com o de uma configuração do tmux
    Mesmo assim, no fim voltei para a combinação de tmux com o terminal padrão
    O tmux ainda é a melhor opção porque funciona bem em qualquer lugar e porque essa forma de compor ferramentas tende a durar mais tempo