Você pede ao Hermes para analisar a página que acabou de capturar em um screenshot, e a resposta vem: “o botão da direita está cortado”. Você quer voltar ali e conferir, então olha para a tela — e não há imagem nenhuma. Só um caminho: /tmp/screenshot-2026-11-05.png. Abrir o gerenciador de arquivos, dar duplo clique, esperar o visualizador, voltar ao terminal. Dois desvios depois, o raciocínio já foi embora.

Esse ciclo agora está fechado. Uma mudança integrada em 4 de novembro faz o Hermes desenhar imagens diretamente no CLI clássico e na TUI: as imagens que você anexa aparecem abaixo da sua mensagem, e as imagens geradas por uma ferramenta aparecem abaixo da linha dessa ferramenta.

Antes era um caminho; agora é a imagem

Dois casos são cobertos:

• Imagens que você anexa — via /paste, /image ou arrastando um arquivo para o terminal — são desenhadas sob a linha da sua mensagem.
• Imagens locais que uma ferramenta produziu ou examinou — uma entrada de vision_analyze, um resultado de image_generate, um screenshot do navegador ou do computer use — aparecem sob a linha dessa ferramenta.

Duas coisas deliberadamente não aparecem, e saber disso economiza uma caçada ao suporte: o read_file não lê imagens, então não desenha nada; e URLs remotas de imagem nunca são buscadas — apenas arquivos locais são renderizados.

Uma configuração, cinco níveis

Fica no config.yaml, em display, e o padrão é auto:

display:
  inline_images: auto   # auto | kitty | iterm | unicode | off

O que cada nível significa:

• auto desenha imagens em resolução total no kitty e no Ghostty (protocolo gráfico do kitty com placeholders Unicode) tanto no CLI quanto na TUI e, no CLI clássico, também usa o protocolo de imagem inline do iTerm2 para desenhar sobre linhas reservadas no iTerm2, no WezTerm e no Konsole. Todo o resto — tmux, GNU screen, sessões SSH dentro do VS Code e a TUI em qualquer lugar fora do kitty/Ghostty — recebe meio-blocos em truecolor: dois caracteres de meia altura por célula de pixel colorido.
• kitty força o protocolo do kitty. O motivo habitual é o CLI clássico dentro do tmux com set -g allow-passthrough on.
• iterm força o protocolo do iTerm2 no CLI clássico; nesse nível a TUI volta para auto.
• unicode sempre usa meio-blocos.
• off mostra apenas caminhos de arquivo, exatamente como antes.

Uma tabela é mais rápida de ler:

Terminal	O que auto entrega
kitty / Ghostty	resolução total (CLI e TUI)
iTerm2 / WezTerm / Konsole	resolução total (apenas CLI clássico)
terminal do VS Code (suporte a imagem ativado)	resolução total (apenas CLI clássico)
tmux / GNU screen / SSH dentro do VS Code	meio-blocos truecolor
qualquer outro, inclusive terminais sixel	meio-blocos truecolor

O VS Code é consultado uma vez, na inicialização

O terminal integrado do VS Code consegue mostrar imagens de verdade, mas só quando terminal.integrated.enableImages está ligado. O Hermes não tinha como saber, então sempre jogava seguro com blocos.

Agora o CLI clássico sonda o VS Code exatamente uma vez por execução: envia uma consulta XTSMGRAPHICS cercada por DA1, na janela antes de o prompt_toolkit assumir o tty. Só o addon de imagens do VS Code responde a essa consulta, então uma resposta significa que as imagens estão ligadas. A resposta é cacheada; a sondagem é ignorada em Remote-SSH, no Windows e quando não existe tty. Se as imagens estiverem desligadas, em cerca de uma execução a cada cinco o Hermes troca a dica aleatória por uma linha citando a configuração — não em todas.

Por que tantos terminais só recebem blocos coloridos

O motivo é mecânico. Um renderizador que dispõe linha por linha consegue medir com segurança duas formas de imagem: os placeholders Unicode do kitty, em que a imagem ocupa células da grade e o número de linhas é conhecido, e os meio-blocos truecolor, em que dois caracteres formam uma célula de pixel. O protocolo do iTerm2 pinta sobre um certo número de linhas reservadas que ninguém contou — por isso ele aparece no CLI clássico e não na TUI.

A mesma restrição explica por que tmux e GNU screen acabam nos meio-blocos: eles podem engolir ou reescrever escapes gráficos de passthrough, a menos que você permita o passthrough explicitamente e fixe o nível kitty.

O que acontece quando você redimensiona

O CLI redesenha o transcript quando o tamanho do terminal muda. Imagens do kitty e meio-blocos voltam nesse redesenho. Imagens desenhadas com o protocolo do iTerm2 deixam linhas em branco na tela redesenhada e permanecem visíveis apenas no scrollback acima dela. Isso é diferença de protocolo, não um recurso quebrado — vale saber antes de abrir um bug.

Quais imagens são desenhadas e quais ficam quietas

O caminho das imagens de ferramenta olha apenas campos nomeados: image_url, url, path, image_path, screenshot_path, lendo o resultado antes dos argumentos. Então uma listagem de search_files cheia de caminhos PNG não vai transformar seu terminal em álbum de fotos.

Prévias PNG grandes demais são recusadas antes de qualquer decodificação — um limite deliberado para que uma única imagem enorme não trave o terminal.

O desenho é renderização local. A imagem iria para o modelo de qualquer forma, como anexo ou resultado de ferramenta; esta camada adiciona pixels à sua tela, não tokens à requisição.

Você já pode usar?

O trabalho entrou na main em 4 de novembro, depois do ponto da release v0.22.7 (3 de novembro), então ainda não está em uma release — até a data deste texto, ele existe apenas na main. Rode a partir do código-fonte se quiser agora, ou espere a próxima versão.

Se você se interessa pela outra metade da história — como uma imagem é compreendida e quanto ela custa em contexto —, o post sobre orçamento de contexto de imagem e o guia de roteamento de visão de imagem cobrem isso. Esta mudança é sobre ver a imagem. Se você vive no teclado, o guia da paleta de comandos é a leitura vizinha, e uma instalação nova começa na página de instalação.