Hermes v0.20.6: Der Agent lernt, als du zu browsen – ein MCP-Katalog mit 50+ Servern und Secrets ohne Keychain-Gefrage


Du bittest deinen Agenten, etwas in deinem Unternehmens-Dashboard nachzusehen – „ruf die Deployment-Seite auf und sag mir, welche Version live ist“ – und er kommt mit einer Login-Wand zurück, weil der Browser, den er steuert, jede Session ausgeloggt startet. Also kopierst du die URL in deinen eigenen Browser, loggst dich ein und machst das Ganze von Hand. Genau diese kleine Reibung nimmt v0.20.6 (Tag v2026.8.27, erschienen am 27. August 2026) ins Visier: Der Agent kann jetzt als du browsen – mit deinen echten Logins, unter ausdrücklicher Zustimmung und standardmäßig deaktiviert.

Im Fenster wurden seit v0.20.5 rund 525 PRs und ~1.313 Commits über ~1.557 Dateien gemergt. Die Schlagzeile ist consent-gesteuertes Real-Profile-Browsing, aber die Release rollt von dort aus weiter: ein Desktop-Browser, der endlich ein eigenes OS-Fenster bekommt, eine verwaltete SSH-Remote-Update-Engine für Fleets, ein Remote-MCP-Katalog jenseits von 50 live-verifizierten Vendor-Servern, TTL-Caching für die Websuche, Lean-Tail-Kompression als Standard, Multi-Query-tool_search und Opt-in-OS-Keychain-Verschlüsselung für gespeicherte Secrets. Gehen wir sie durch.

Real-Profile-Browsing ist aus gutem Grund die Schlagzeile. Wenn es aktiviert ist (browser.use_real_profile: true oder Einstellungen → Browser → Mein echtes Browser-Profil verwenden in der Desktop-App), kopiert Hermes das aktive Profil deines Standard-Browsers – das, mit dem du wirklich surfst, samt Cookies, gespeicherten Logins und Einstellungen – in einen verwalteten Snapshot unter ~/.hermes/browser-profile/ und steuert diesen Snapshot mit seinem gebündelten Chromium (#1f4d095fd8, #830e4a29be).

Drei Details sind wichtig:

  • Dein Live-Profil wird nie direkt geöffnet. Der Snapshot ist ein separates Verzeichnis, kämpft also nicht mit deinem laufenden Browser um die Profil-Sperre und umgeht außerdem Chrones Block gegen Remote-Debugging des Standard-Profilverzeichnisses ab Chrome 136+.
  • Auth wird neu synchronisiert. Cookies und Logins werden bei jedem Start einer frischen Session erneut kopiert, sodass ein Login, den du in deinem eigenen Browser machst, in der nächsten Session des Agenten auftaucht.
  • Zustimmung widerrufen löscht alles. Wird der Schalter deaktiviert, wird der Snapshot-Speicher bei der nächsten Browser-Nutzung entfernt – kopierte Zugangsdaten bleiben nach dem Widerruf nicht zurück.

Windows hat eine Eigenheit: Chrome/Edge/Brave sperren ihre Cookie-Datenbanken mit einer Deny-All-Sperre, solange sie laufen, also muss der Browser vollständig beendet sein, bevor das Profil kopiert werden kann (Hermes schlägt schnell mit einer klaren Meldung fehl, statt zu hängen). Mit browser.real_profile_autoclose: true darf der Agent anbieten, ihn für dich zu schließen – von selbst tut er das nie, und wenn das Profil danach immer noch gesperrt ist, bleibt er blockiert und sagt dir, du sollst den Browser beenden. Nicht-Chromium-Standards (Firefox) verweigern sicherheitshalber mit einer klaren Meldung. Im browser_exec-Tool erscheint ein local-Argument, sobald der Schalter aktiv ist; es erzwingt eine Real-Profile-Session auch unter einem Cloud-Browser-Backend.

Ist das sicher? Es ist Consent-gesteuerte Bequemlichkeit, keine Isolationsgrenze: Eine Seite, die der Agent besucht, läuft mit deinen echten Logins. Genau deshalb ist es standardmäßig deaktiviert – aktiviere es, wenn du willst, dass der Agent als du handelt. Zur Mechanik der Browser-Tools sieh dir unseren Browser-Use-CLI-Guide und den Beitrag zum Browser-Snapshot-Budget an.

Der Desktop-Browser wächst: eigenes OS-Fenster + verwaltete SSH-Updates

Der Desktop-Browser war ein eingebettetes Paneel; jetzt kann er in einem eigenen OS-Fenster geöffnet werden – vergrößern, zwischen Monitoren verschieben, neben deinem Editor andocken. Falls du dir je gewünscht hast, dass das Vorschaufenster mehr Platz hätte: Genau das ist es.

Die andere Desktop-Geschichte ist eine verwaltete SSH-Remote-Update-Engine: Updates können jetzt pro Verbindung über SSH für Remote-Gateways angestoßen werden, sodass eine Fleet von Maschinen von einer Desktop-App aus aktuell bleibt. Die Fleet-Profil-Leiste folgt – Profile wechseln, und die Update-Ziele wechseln mit. Zusammen mit den Update-Verbesserungen unten wird „alles aktualisieren“ zunehmend zu einer One-Click-Operation, die sich verifizieren lässt. Zur größeren Update-Geschichte sieh dir unseren Guide zum sanften Upgrade an.

Ein Remote-MCP-Katalog jenseits von 50 live-verifizierten Servern

Der eingebaute Remote-MCP-Katalog wächst weiter: 50+ live-verifizierte, von Vendoren gehostete Server – Cloudflare, Grafana Cloud, Better Stack, Railway, Canva, Dropbox, GitLab, Strava und mehr. Jeder Eintrag wird gegen den Live-Endpoint des Vendors verifiziert, und ?codemode=false ist fixiert, damit tool_search die volle Endpoint-Oberfläche sieht. Wenn du seit Längerem nicht mehr ins Katalog-Innere geschaut hast, lohnt sich ein Blick:

hermes mcp catalog list --remote

Für einen tieferen Blick in den Katalog selbst sieh dir unseren Guide zum offiziellen Remote-MCP-Katalog an.

Caching, Kompression und eine klügere Tool-Suche

Drei leisere Upgrades, die jeden Tag Tokens und Geld sparen:

  • TTL-Ergebnis-Caching für web_search/web_extract: Wiederholte Abfragen innerhalb des TTL-Fensters liefern das gecachte Ergebnis, statt den Vendor erneut zu belasten. Ein Retry, eine erneute Ausführung, ein Cron-Job, der dieselbe URL prüft – alles günstiger. (Konfigurierbar über web.cache_ttl; die ganze Geschichte in unserem Beitrag zum Web-Search-Cache.)
  • Lean-Tail-Kompression ist jetzt der Standard: Nach der Kompression behält der Agent eine kompakte Zusammenfassung plus einen kurzen, wertvollen Tail statt eines langen, wenig wertvollen – weniger, das jeder Turn erneut senden muss, geringere Kosten. Unser Kompression-Guide deckt die Stellschrauben ab.
  • Multi-Query-tool_search mit Stemming: tool_search nimmt jetzt queries: string[] entgegen und sucht jede Query unabhängig (Limit pro Query, Standard 5 / Maximum 25), und tool_describe nimmt names: string[] und liefert eine nach Namen verschlüsselte Map – ein einzelner falscher Name lässt nicht mehr den ganzen Aufruf scheitern. Snowball-Stemming bedeutet, dass „browsing“ auf „browser“ matcht.
{ "queries": ["browser snapshot", "web search cache", "read pdf"] }

Das Ergebnis: weniger Round-Trips, wenn der Agent nach dem richtigen Tool sucht, und günstigere Discovery. Die Details haben wir in unserem tool_search-Multi-Query-Guide aufgeschrieben.

Secrets ohne Keychain-Gefrage

Wenn du den Hermes-Desktop unter macOS nutzt, kennst du vielleicht den Dialog „Keychain Not Found“ – Electrons safeStorage legt einen App-spezifischen Schlüssel in der Login-Keychain ab, und auf Maschinen mit gesperrter, fehlender oder korrupter Keychain wurde daraus bei jedem Start ein blockierender Passwort-Prompt. v0.20.6 macht die Keychain-gestützte Verschlüsselung zu einem expliziten Opt-in (Einstellungen → Gateway): Der Standardpfad fasst safeStorage gar nicht mehr an, und eine Einmal-Migration wandelt beim ersten Start vorhandene verschlüsselte Blobs in einfache 0600-Dateien um. Wird der Schalter umgelegt, werden alle gespeicherten Secret-Stores an Ort und Stelle neu kodiert. Kein Prompt mehr – und volle Verschlüsselung, wenn du sie willst. Die komplette Einrichtung in unserem Guide zur Keychain-Secret-Verschlüsselung.

Updates, die dein Gateway nicht killen

Updater pausieren Gateways jetzt über den Control-Socket, statt sie per Tree-Kill zu beenden: Dienste quiescen, das Update wird eingespielt, die Gateways laufen weiter – laufende Turns und Messaging-Verbindungen überleben das Upgrade. Image-/paketverwaltete Installationen verweigern außerdem unsichere In-Place-Updates über ein gemeinsames Gate (#91277 Phase 3), und gitignored-Nutzerdateien blockieren das destruktive ZIP-Overlay (#96440). Der Updater beweist sein Ergebnis weiterhin und setzt damit den Bogen fort, den wir in den v0.20.5-Housekeeping-Release-Notes behandelt haben.

Weitere Erwähnenswerte

  • Cron: dauerhafte Incident-Acks – einen Incident eines Jobs einmal bestätigen, und der Ack bleibt erhalten; klarere Code-Skew-Fehler, wenn Scheduler und Gateway uneins sind.
  • Slack: Link-Unfurl-Steuerung, damit Teams verhindern können, dass die Links des Agenten zu Karten aufgeklappt werden.
  • Docker: Vertrauenswürdige Profile können sich für einen gemeinsamen persistenten Container entscheiden; Third-Party-Sandboxes lassen sich als Terminal-Backends einstecken, ohne den Kern anzufassen.
  • Modelle: GLM-5.3-Flash erreicht die z.ai- und OpenCode-Auswahlmenüs, MiniMax M3 free kommt zu OpenRouter, MiniMax H3 Max ins FAL-Video-Auswahlmenü.
  • Gateway-Zuverlässigkeit: Zwei-Witness-Loop-Liveness – der eigene Heartbeat des Watchdogs kann ein gesundes Gateway nicht mehr einfrieren oder killen (#92315); der Doppel-Kill von launchd --replace wurde per SIGUSR1-Graceful-Restart behoben (#96427).

Für die vollständige Highlight-für-Highlight-Aufschlüsselung inklusive der kompletten Improvements- und Fixes-Listen sieh dir unsere v0.20.6-Release-Notes an. Das Upgrade ist unkompliziert:

hermes update

Nach dem Upgrade hermes doctor ausführen und das Gateway neu starten (hermes gateway), damit Plattformänderungen wirksam werden. v0.20.6 braucht keine einzige dramatische Schlagzeile – es ist ein stetiger Strom, in dem der Agent dir endlich auf deinem eingeloggten Web begegnet und die täglichen Pflichten (Caching, Kompression, Keychain, Updates) leise aus dem Weg gehen.