Hermes liefert dir jetzt die Dateien, die sein Agent in Remote-Sandboxes erzeugt

Stell dir einen Freitagabend vor: Du steckst die Hände von Hermes in eine Remote-Sandbox – eine Modal-Cloud-Umgebung oder eine SSH-Dev-Box deines Unternehmens –, weil du eine saubere Isolation willst, die niemals die Dateien auf deinem Laptop anfasst. Der Agent erledigt den Job, erzeugt in der Sandbox ein Diagramm, einen Bericht, einen Screenshot einer Webseite und hängt den Dateipfad freudig an seine Antwort an. In deinem Chatfenster erscheint nichts. Die einzige Spur ist eine Logzeile: „Skipping unsafe MEDIA directive path.“ Die Datei existiert – sie kann dich nur nicht erreichen.
Warum Dateien früher verschwanden
Um das zu verstehen, musst du zuerst wissen, wie Hermes dir Dateien überhaupt zustellt. Der Agent schreibt in seine Antwort einen MEDIA:<path>-Tag; das Gateway erkennt ihn, holt die Datei heraus und schickt sie als Bild oder Anhang in deinen Chat. Diese Pfadvalidierung war schon immer bewusst host-only – Medienzustellung darf niemals zu einem Kanal werden, über den sich beliebige Systemdateien lesen lassen. Deshalb stehen ~/.ssh, Systemverzeichnisse und die eigenen Credential-Speicher von Hermes auf einer Denylist und werden grundsätzlich abgelehnt.
Das Problem ist genau dieser „host-only“-Teil. Wenn dein Terminal-Backend ssh, Modal, Daytona, Singularity oder eine Vercel-Sandbox ist, laufen die Terminalbefehle des Agents auf einer anderen Maschine – einem anderen Dateisystem. Die Datei hinter MEDIA: liegt schlicht nicht auf dem Gateway-Host, die Validierung schlägt fehl, und der Anhang wird als „unsafe path“ verworfen. Die Datei wurde einwandfrei erzeugt – das Gateway kam nur nicht an sie heran.
Der Fix: In die Sandbox greifen und die Datei zurückholen
PR #103600, am 5. September 2026 gemerged (die ausgehende Hälfte von issue #466), ändert das. Die Idee ist simpel: Schlägt die Host-Validierung fehl, läuft die aktuelle Session aber wirklich in einer Remote-Sandbox, holt das Gateway die Datei nun über den Exec-Channel zurück und führt sie durch den normalen Zustellablauf.
Das läuft in drei Schichten ab:
- Transport (
tools/environments/base.py): Jedes Environment-Backend hat ein einheitlichesfetch_file/fetch_realpathbekommen – die Datei wird base64-kodiert und über den Exec-Channel zurückgeschickt, innerhalb der Sandbox auf eine Maximalgröße begrenzt (head -c max+1, derselbe Trick, dentools.image_sourcenutzt, damit ein endloser Stream wie/dev/zeroden Host-Speicher nicht fluten kann), mit Payload-Markern, die das Rauschen der Login-Shell abgrenzen. - Trigger (neu in
gateway/media_fetch.py, rund 120 Zeilen): Feuert nur, wenn ein Remote-Backend aktiv ist und die Host-Validierung bereits fehlgeschlagen ist – ein lokales Backend nimmt diesen Pfad nie. - Hook (
gateway/platforms/base.py::_validated_delivery_path): eine Ergänzung von drei Zeilen am einzigen Engpass, den alle MEDIA-Filterstellen teilen – ein Fix, überall wirksam.
Sicherheitsgrenzen: Das ist kein Hintertürchen an der Denylist vorbei
Dateien aus einer Remote-Sandbox zurückzuholen ist genau die Art Feature, die zu einem Denylist-Bypass ausarten könnte. Deshalb wird der Pfad zweimal gesiebt: zuerst durch dieselbe Host-Denylist (Systempräfixe, Verzeichnisse der ~/.ssh-Klasse, Hermes-Credential-Speicher), bevor sich auch nur ein Byte bewegt, und danach erneut, nachdem readlink -f den tatsächlichen Pfad aufgelöst hat – ein Symlink, der auf eine Credential-Datei zeigt, wird ohne Umschweife abgelehnt, kein einziges Byte wird übertragen. Dateien, die bestehen, landen in cache/documents/ (selbst eine allowlistete Zustellwurzel) und werden anschließend exakt wie jede Host-Datei validiert und zugestellt. Das Limit liegt bei 50 MB und entspricht dem Upload-Limit der jeweiligen Plattform.
Das alte Verhalten zurück? Unter HERMES_MEDIA_DELIVERY_STRICT (strict mode) werden Remote-Dateien weiterhin nie geholt – eine geholte Kopie würde in einer allowlisteten Wurzel landen und könnte das Recency-Gate überspringen, für das strict mode gedacht ist. Strict mode lässt also alles beim Alten.
Welche Setups profitieren
Jedes Remote-Terminal-Backend – ssh, Modal, Daytona, Singularity, Vercel-Sandbox – stellt nun Dateien zu, die der Agent dort erzeugt und über einen MEDIA:-Tag referenziert: Screenshots eines Scrapers, der in der Sandbox läuft, Diagramme aus einem Datenanalyse-Skript, Berichte nach einer langwierigen Aufgabe. Kurz: alles, worum du den Agenten gebeten hast, es zu „speichern und mir zu schicken“. Lokale Backends verhalten sich exakt wie bisher – sie brauchten das Zurückholen nie.
Eine ehrliche Einschränkung: Backends, die ihr entferntes Home-Verzeichnis melden können (_remote_home, etwa ssh, Daytona und Vercel), erhalten volle Unterstützung; Modal, Singularity und Docker ohne Host-Mounts können das entfernte Home nicht bestätigen und behalten deshalb die konservative Any-Component-Denylist – Dateien unter Systempräfixen wie /root werden dort standardmäßig weiterhin nicht geholt, außer die Umgebung setzt _remote_home explizit, um sich dafür zu entscheiden.
Was noch fehlt
Damit ist nur die „ausgehende“ Hälfte von #466 umgesetzt. Der PR schließt bewusst aus: ein eigenständiges send_file-Core-Tool (der bestehende MEDIA:-Tag ist die Schnittstelle – die erste Sprosse der Footprint-Leiter), native Transporte pro Backend sowie das Einschleusen eingehender Anhänge in die Sandbox (in #466 weiterhin offen). Diese folgen der Footprint-Leiter und erscheinen inkrementell statt auf einen Schlag.
So bekommst du den Fix
Kein neuer Befehl, keine neue Konfiguration – das ist ein Verhaltens-Fix des Gateways; er wird beim Upgrade aktiv. Die Änderung ist in main gemerged (2026-09-05) und steckt noch in keinem Release-Tag; installiere jetzt eine dev/main-Version, um es auszuprobieren, oder führe einfach hermes update aus, sobald das nächste Release erscheint. So verifizierst du es hinterher schnell: Lass den Agenten in einer Remote-Sandbox ein Bild erzeugen und es dir zuschicken – es sollte ankommen; lege danach einen Symlink auf ~/.ssh an und bestätige, dass er weiterhin abgelehnt wird. Beide Prüfungen greifen wie vorgesehen.
Mehr zu Sandboxes und Backends findest du in unseren früheren Guides zu gemeinsamen Docker-Containern und pluggable Terminal-Backends; die Release-Kadenz steht auf der Releases-Seite.