Du fragst Hermes nach der Seite, die du gerade gescreenshottet hast, und bekommst die Antwort „der Button rechts ist abgeschnitten“. Du willst zurückzeigen und nachsehen, also schaust du hoch — und da ist kein Bild. Nur ein Pfad: /tmp/screenshot-2026-11-05.png. Dateimanager öffnen, Doppelklick, auf den Viewer warten, zurück ins Terminal. Zwei Umwege später ist dein Gedankengang weg.

Diese Schleife ist jetzt geschlossen. Eine am 4. November gemergte Änderung lässt Hermes Bilder direkt in der klassischen CLI und in der TUI zeichnen: Anhänge erscheinen unter deiner Nachricht, und Bilder, die ein Tool erzeugt hat, erscheinen unter der Zeile dieses Tools.

Früher war es ein Pfad, jetzt ist es das Bild

Zwei Fälle sind abgedeckt:

• Bilder, die du anhängst — über /paste, /image oder per Drag-and-drop ins Terminal — werden unter deiner Nachricht gezeichnet.
• Lokale Bilder, die ein Tool erzeugt oder angesehen hat — eine vision_analyze-Eingabe, ein image_generate-Ergebnis, ein Browser- oder Computer-Use-Screenshot — werden unter der Zeile des jeweiligen Tools gezeichnet.

Zwei Dinge erscheinen bewusst nicht, und wer das weiß, spart sich eine Support-Suche: read_file kann keine Bilder lesen und zeichnet deshalb nichts; und entfernte Bild-URLs werden nie geladen — nur lokale Dateien werden gerendert.

Ein Schalter, fünf Stufen

Er sitzt in config.yaml unter display und steht standardmäßig auf auto:

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

Was die einzelnen Stufen bedeuten:

• auto zeichnet Bilder in voller Auflösung in kitty und Ghostty (kitty-Grafikprotokoll mit Unicode-Platzhaltern), sowohl in der CLI als auch in der TUI, und nutzt in der klassischen CLI zusätzlich das iTerm2-Inline-Image-Protokoll, um über reservierte Zeilen in iTerm2, WezTerm und Konsole zu zeichnen. Alles andere — tmux, GNU screen, SSH-Sitzungen in VS Code und die TUI überall außerhalb von kitty/Ghostty — bekommt Truecolor-Halbblöcke: zwei halbhohe Zeichen pro farbiger Pixelzelle.
• kitty erzwingt das kitty-Protokoll. Der übliche Grund ist die klassische CLI in tmux mit set -g allow-passthrough on.
• iterm erzwingt das iTerm2-Protokoll in der klassischen CLI; die TUI fällt auf dieser Stufe auf auto zurück.
• unicode nutzt immer Halbblöcke.
• off zeigt nur Dateipfade, genau wie vorher.

Eine Tabelle geht schneller:

Terminal	Was auto liefert
kitty / Ghostty	volle Auflösung (CLI und TUI)
iTerm2 / WezTerm / Konsole	volle Auflösung (nur klassische CLI)
VS Code Terminal (Bildsupport an)	volle Auflösung (nur klassische CLI)
tmux / GNU screen / SSH in VS Code	Truecolor-Halbblöcke
alles andere, Sixel-Terminals eingeschlossen	Truecolor-Halbblöcke

VS Code wird einmal gefragt, beim Start

Das integrierte Terminal von VS Code kann echte Bilder zeigen, aber nur wenn terminal.integrated.enableImages an ist. Hermes hatte keine Möglichkeit, das zu wissen, und blieb deshalb immer sicher bei Blöcken.

Jetzt prüft die klassische CLI VS Code genau einmal pro Start: Sie schickt eine XTSMGRAPHICS-Abfrage, eingefasst von DA1, in dem Fenster, bevor prompt_toolkit das tty übernimmt. Nur das Image-Addon von VS Code antwortet auf diese Abfrage, eine Antwort heißt also, dass Bilder an sind. Die Antwort wird gecacht; über Remote-SSH, unter Windows und ohne tty wird die Prüfung übersprungen. Sind Bilder aus, tauscht Hermes bei ungefähr jedem fünften Start seinen zufälligen Tipp gegen einen Einzeiler, der die Einstellung nennt — nicht bei jedem Start.

Warum so viele Terminals nur farbige Blöcke bekommen

Der Grund ist mechanisch. Ein Renderer, der Zeile für Zeile layoutet, kann zwei Bildformen zuverlässig messen: kittys Unicode-Platzhalter, bei denen das Bild Rasterzellen belegt und die Zeilenzahl bekannt ist, und Truecolor-Halbblöcke, bei denen zwei Zeichen eine Pixelzelle ergeben. Das iTerm2-Protokoll malt über eine Anzahl reservierter Zeilen, die niemand gezählt hat — deshalb erscheint es in der klassischen CLI und nicht in der TUI.

Dieselbe Einschränkung erklärt, warum tmux und GNU screen bei Halbblöcken landen: Sie können Passthrough-Grafik-Escapes verschlucken oder umschreiben, wenn du Passthrough nicht ausdrücklich erlaubst und die Stufe kitty festnagelst.

Was beim Ändern der Fenstergröße passiert

Die CLI zeichnet ihr Transkript neu, wenn sich die Terminalgröße ändert. kitty-Bilder und Halbblöcke kommen bei diesem Neuzeichnen zurück. Bilder, die mit dem iTerm2-Protokoll gezeichnet wurden, hinterlassen leere Zeilen im neu gezeichneten Bildschirm und bleiben nur im Scrollback darüber sichtbar. Das ist ein Protokollunterschied, kein kaputtes Feature — gut zu wissen, bevor du einen Bug meldest.

Welche Bilder gezeichnet werden — und welche still bleiben

Der Tool-Bild-Pfad schaut nur auf benannte Felder: image_url, url, path, image_path, screenshot_path, und liest dabei das Ergebnis vor den Argumenten. Ein search_files-Listing voller PNG-Pfade macht aus deinem Terminal also kein Fotoalbum.

Zu große PNG-Vorschauen werden abgelehnt, bevor irgendetwas sie dekodiert — eine bewusste Grenze, damit ein einziges riesiges Bild das Terminal nicht blockiert.

Das Zeichnen ist lokales Rendering. Das Bild wäre ohnehin als Anhang oder Tool-Ergebnis ans Modell gegangen; diese Schicht fügt Pixel auf deinem Bildschirm hinzu, keine Tokens in der Anfrage.

Kannst du es heute nutzen?

Die Arbeit wurde am 4. November in main gemergt, nach dem Release-Punkt von v0.22.7 (3. November), ist also noch in keinem Release — zum Zeitpunkt dieses Textes liegt sie nur auf main. Starte aus dem Quellcode, wenn du sie jetzt willst, oder warte auf die nächste Version.

Wenn dich die andere Hälfte des Bildes interessiert — wie ein Bild verstanden wird und was es im Kontext kostet —, dann decken der Beitrag zum Bild-Kontextbudget und der Leitfaden zum Bild-Vision-Routing das ab. Diese Änderung geht darum, es zu sehen. Wenn du in der Tastatur lebst, ist der Leitfaden zur Befehlspalette die nächstliegende Lektüre, und eine frische Installation beginnt auf der Installationsseite.