Sehen Sie Ihrem Bot bei der Arbeit zu – und übernehmen Sie die Maus, wenn ein Login auftaucht

Ihr Bot hängt um drei Uhr nachts auf einem Vendor-Portal fest, das eine Anmeldung verlangt. Er sagt es Ihnen im Chat und beendet seinen Turn — und alles danach ist Raterei: auf welcher Seite er stehen geblieben ist, ob er das Formular vermasselt hat, das er eine Minute zuvor abgeschickt hat. Wenn Sie endlich dazu kommen, ist die Session kalt geworden, und in der Zwischenzeit hat er womöglich irgendwo anders geklickt. Bot Screen gibt es, um genau diese Raterei zu streichen. Auf einem headless Linux-Host hat jedes Profil jetzt seinen eigenen Desktop, der live in Hermes Desktop gestreamt wird. Sie können dem Bot bei der Arbeit zusehen, Tastatur und Maus übernehmen, wenn er Sie braucht, und die Kontrolle anschließend zurückgeben, damit er weitermacht.

Was es tatsächlich ist

Ein Satz: Jeder Bot bekommt seinen eigenen Xfce-Desktop, der auf dem Gateway-Host läuft.

  • Das computer_use des Bots (Desktop-Automatisierung) und sein headed Browser (browser.headed: true) agieren auf diesem Bildschirm.
  • Der Bildschirm wird per noVNC in ein Pane in Hermes Desktop gestreamt.
  • Jedes Profil hat seinen eigenen Bildschirm, sein eigenes Browser-Profil und seine eigenen Cookies.
  • Der wichtige Teil: Der Bildschirm lebt auf dem Gateway-Host, nicht auf Ihrem Laptop. App schließen, Deckel zuklappen — der Bot arbeitet auf dem Server weiter.

Das ist der Unterschied zu „Remote-Desktop zurück auf meine eigene Maschine“: Der Agent läuft auf dem Server, der Desktop läuft auf dem Server, und Ihr Client ist nur ein Fenster darauf.

Wofür Sie es nutzen: Logins, 2FA, CAPTCHAs, Zahlungen

Diese Schritte sollte der Bot nicht selbst erledigen — und er sollte auch nicht blockierend auf Sie warten:

  1. Er stößt auf einen Login-, 2FA-, CAPTCHA- oder Zahlungsschritt, sagt es in seiner Antwort und beendet seinen Turn.
  2. Die Aufforderung erreicht Sie in dem Chat, in dem Sie gerade sind — Telegram, Slack, Desktop.
  3. Wenn Sie Zeit haben, öffnen Sie das Pane und klicken auf Take over. Der Rahmen wird rot; Ihre Tastatur und Ihre Maus steuern jetzt.
  4. Anmelden, CAPTCHA lösen, Zahlung freigeben.
  5. Klicken Sie auf Hand back. Der Bot bekommt die Kontrolle zurück und erfasst den Bildschirm erneut, bevor er weitermacht.

Zwei Details sind erwähnenswert. Ein Bot hält nie einen Tool-Call offen und wartet auf Sie — das Übernehmen starten immer Sie. Und wenn zwei Zuschauer um denselben Bildschirm streiten, gewinnt das jüngste Take over; der bisherige Controller fällt aufs Zusehen zurück. „Hand back“ und „Verbindung verloren“ sind außerdem zwei verschiedene Dinge: Klappt der Deckel zu oder bricht das WLAN ab, während Sie die Kontrolle halten, behalten Sie sie — der Bot bleibt von einem Bildschirm ausgesperrt, an dem Sie möglicherweise mitten in einem Login stecken — bis Sie sich wieder verbinden und zurückgeben. Wenn ein Reload dazu führt, dass das Pane behauptet, ein Mensch halte noch die Kontrolle, erscheint ein Hand back (force)-Button.

Erste Schritte

Voraussetzung: Der Gateway-Host läuft unter Linux. macOS- und Windows-Hosts haben bereits ein echtes Display, dort wird das Pane gar nicht angeboten.

Die Desktop-Pakete (TigerVNCs Xvnc plus der Xfce-Kern) werden nie still installiert — hermes update und frische Installationen lassen die Maschine, wie sie ist. Fehlen sie, zeigt das Desktop-Pane Install on host: Ein Klick führt den Paketmanager auf diesem Host aus und fragt nach dem sudo-Passwort jenes Hosts in einer maskierten Karte (das Passwort geht nur an diesen Host und wird nie gespeichert).

Das offizielle Docker-Image — das auch Hermes Cloud betreibt — ist der andere Fall: Der Gateway läuft als unprivilegierter User, und das Image hat kein sudo. Deshalb gibt das Pane die exakte Zeile aus, und ein Operator führt sie einmal als root im Container aus:

docker exec -u 0 <container> apt-get install -y \
  tigervnc-standalone-server xfce4-panel xfwm4 xfdesktop4 xfce4-settings \
  xfce4-terminal dbus-x11 x11-xserver-utils x11-utils xauth fonts-dejavu-core

Die gleichen Operationen aus einer Shell:

hermes computer-use screen status     # installed? running? who holds control?
hermes computer-use screen start      # start this profile's screen
hermes computer-use screen stop       # refuses while a human holds control
hermes computer-use screen stop --force   # force it, and clear a stuck lease
hermes computer-use screen install [-y]   # run apt/dnf/pacman
hermes -p research computer-use screen start   # another profile's screen

Der Bildschirm ist standardmäßig aus, und nichts startet ihn für Sie. bot_desktop.auto_start ist false; schalten Sie es ein, bringt ein headless Host seinen Bildschirm beim ersten computer_use-Call des Bots oder bei der ersten headed Browser-Nutzung hoch. Der Default ist Absicht — wer TigerVNC aus ganz anderen Gründen installiert, sollte nicht plötzlich einen Bildschirm bekommen, den niemand angefordert hat.

bot_desktop:
  geometry: "1440x900"      # screen size; the viewer scales to fit the pane
  auto_start: false         # true = start on first computer_use / headed browser use
  min_free_memory_mb: 1536  # refuse to start below this much free memory (0 = never check)
  idle_stop_minutes: 30     # stop a screen nobody used for this long (0 = keep it up)

Rechnen Sie zuerst den Speicher durch

Der Desktop ist günstig; der Browser ist der Kostenfaktor. Gemessen im offiziellen Image:

Posten Footprint
Gateway idle ~300 MB
Xvnc + Xfce ~220 MB
Headed Chromium, während eines Takeovers geöffnet 0,5–1 GB (~550 MB für eine Seite)
CPU praktisch gratis (idle Desktop ≈ 0,01 Core)
Disk, Pakete unter Debian 13 ~930 MB

Planen Sie 1,1–1,5 GB pro offenem Bildschirm mit Browser ein. Die offizielle Empfehlung: 4 GB reichen für den Desktop, ab 8 GB ist ein Takeover mit Browser komfortabel. Vor dem Start prüft Hermes, ob der Host — oder sein Container-cgroup, je nachdem, was knapper ist — min_free_memory_mb frei hat; darunter verweigert es den Start und sagt es im Pane, und ein bereits laufender Bildschirm wird von dieser Prüfung nie abgeräumt. Idle-Bildschirme stoppen nach idle_stop_minutes (standardmäßig 30) und kommen bei der nächsten Nutzung zurück.

Neu seit 2026-09-23: zwei Image-Varianten

Ein gehostetes Deployment (Fly Machines, Azure Container Instances) kann zur Laufzeit nichts installieren, also müssen die Pakete eingebaut sein. Die CI veröffentlicht jetzt zwei Varianten jeder Version:

  • die Tags ohne Suffix (:latest, :v*) — ohne die Pakete;
  • die -desktop-Tags (:latest-desktop, :v*-desktop) — mit TigerVNC, den Xfce-Komponenten und dem Chromium der Distribution.

Ziehen Sie den Tag mit Suffix auf einer gehosteten Instanz, und Bot Screen ist da. Die heutige Einschränkung, klar in den Docs benannt: Der Provisioner wählt noch nirgends -desktop aus, eine gehostete Instanz kommt also weiterhin schlank hoch — den Tag mit Suffix selbst zu ziehen funktioniert. Ein eigenes Image zu bauen ist ebenfalls Opt-in; das offizielle Build-Argument ist standardmäßig aus, damit ein schlichtes docker build . schlank bleibt:

docker build --build-arg HERMES_BOT_DESKTOP=1 -t hermes-agent:screen .

Einen Tag später (2026-09-24) kam eine begleitende Änderung dazu: Jedes Image, auch die schlanken Tags ohne Desktop, enthält jetzt den vollen Chromium-Build statt der leichteren headless Shell von Playwright — ein gepinnter, mit Checksumme versehener Browser bedient sowohl headless Browsing als auch headed Bot-Screen-Sessions, zum Preis eines größeren Images.

Browser-Sessions überleben die Übergabe

Das ist das Praktischste an Bot Screen: Das Browser-Tool des Bots und das Browser-Icon im Pane sind derselbe Browser. Jeder Bot führt ein persistentes User-Data-Verzeichnis (<HERMES_HOME>/bot-desktop/browser-profile), während eines Takeovers sind Sie also in den Fenstern und dem Cookie Jar des Bots unterwegs — und wo Sie sich anmelden, das nutzt der Bot danach, in diesem Run und in jeder späteren Session, bis die Seite den Login verfallen lässt.

Setzen Sie browser.headed: true, wenn das eigene Browsing des Bots ebenfalls auf dem Bildschirm sichtbar sein soll. Beachten Sie, dass das Dock nur einmal befüllt wird, beim ersten Screen-Start für ein Profil: Der Guard ist die Panel-Layout-Datei <HERMES_HOME>/bot-desktop/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. Solange sie existiert, pinnt ein geänderter AGENT_BROWSER_EXECUTABLE_PATH oder AGENT_BROWSER_PROFILE plus Neustart das Browser-Icon nicht neu — löschen Sie die Datei, und das Dock baut sich beim nächsten screen start neu auf.

Die Sicherheitsgrenze: eine Arbeitsfläche, keine Sandbox

Die Docs sagen das unverblümt, und es lohnt sich, es sinngemäß wörtlich zu wiederholen: Der RFB-Socket des Bildschirms, das X-Display, das Browser-Profil und die Datei mit der Control-Lease gehören alle dem OS-User des Gateways. Jeder Prozess, der als dieser User läuft — ein anderer Bot auf demselben Host und das terminal-Tool des Bots selbst — kann direkt darauf zugreifen und dabei das Pane und die Lease umgehen. Die Lease ist ein Zaun auf Tool-Ebene für computer_use und die Browser-Tools, kein Zaun des Betriebssystems.

Eine Grenze ist weiter als der OS-User: Chromiums DevTools-Port (das Browser-Icon im Dock und jeder agent-browser-Start benutzen je einen auf Loopback) ist für jeden lokalen User auf dem Host erreichbar, und Chromium bietet dafür keine Beschränkung pro User. Jeden Bot als eigenen OS-User laufen zu lassen ist out of scope; wenn diese Isolation wichtig ist oder auf dem Host nicht vertrauenswürdige lokale User existieren, packen Sie die Bots auf getrennte Hosts.

Zwei Timing-Details: Die WebSocket-Bridge cached ihre Lease-Entscheidung bis zu 250 ms lang, ein Takeover durch einen anderen Prozess wird also innerhalb dieses Fensters durchgesetzt. Und das nur einmal verwendbare, 30 Sekunden gültige display_ticket des Viewers wandert absichtlich als URL-Query-Parameter (noVNC kann keine WebSocket-Subprotokolle aushandeln), was bedeutet, dass das Access-Log eines Reverse Proxy ein bereits verbrauchtes Ticket protokollieren kann.

Die Kurzfassung: Tippen Sie keine Secrets in einen Bot, dem Sie sie nicht anvertrauen würden.

Unterm Strich

Bot Screen macht aus „Der Bot hängt auf einer Login-Seite“ einen Klick, ein Takeover und ein Hand-back — wobei der Bildschirm auf dem Server bleibt, damit Ihr Laptop kommen und gehen kann. Standardmäßig aus, bei Idle zurückgeholt und durch eine explizite Speicherprüfung abgesichert, frisst es keine kleine Instanz heimlich auf. Wenn Sie tiefer einsteigen wollen, lesen Sie den Bot-Mode-Leitfaden dazu, wie aus Profilen benannte Bots werden, was ein geteilter Docker-Container für parallele Agenten bedeutet und den Rest dieses Fensters auf der Release-Seite v0.21.5.