Du betreibst zwei Profile: einen persönlichen Assistenten und einen Team-Bot — jedes mit eigenem Telegram- oder Feishu-Bot. Um 3 Uhr nachts ist der geplante Job des Team-Bots fertig — und das Ergebnis wird über deinen persönlichen Bot zugestellt. Oder noch schlimmer: Die Zustellung schlägt mit Bot not in chat fehl — der Job war erfolgreich, aber niemand hat das Ergebnis je zu Gesicht bekommen. Ein am 31. August gemergter Fix (PR #99375) gräbt diese ganze Klasse von Kreuzgesprächen an der Wurzel aus: Welcher Bot die Nachricht eines Cron-Jobs zustellt, entscheidet das Profil, dem der Job gehört — nicht irgendein Prozess, der ihn zufällig ausgeführt hat.

Die Ursache: Die Zustellungsidentität folgte der falschen „Person“

In Hermes’ Multi-Profil-Design hat jedes Profil seine eigene Konfiguration, eigene Zugangsdaten, eine eigene Session-Datenbank und eigene Messaging-Bots. Doch vor diesem Fix hatte die Cron-Zustellung einen fatalen Fehler: Die Zustellungsidentität folgte dem ausführenden Prozess statt dem Besitzer-Profil des Jobs.

Konkret: Du startest das Gateway aus deinem Hauptprofil, und es hostet nebenbei die Jobs von Profil B. Wenn Bs Job läuft, liest das System die Zugangsdaten „des aktuellen Prozesses“ — also die des Hauptprofils —, und Bs Ergebnis geht über den Bot des Hauptprofils raus. Soll es in Bs Gruppen-Chat zugestellt werden? Der Bot ist dort nicht Mitglied, also gibt es einen Fehler. Soll es in den Chat des Hauptprofils? Dann landet die Nachricht am falschen Ort. Der Job lief erfolgreich, und trotzdem verschwand das Ergebnis.

Und das war erst die halbe Wahrheit. Auch cron status log: Er behandelte irgendein laufendes Gateway eines Profils als Beweis für Gesundheit — selbst wenn der Scheduler von Profil B gar nicht lief. Der Status sah grün aus, während Bs Jobs nie feuern würden.

Der Fix: vier Ursachen, ein Prinzip

PR #99375 übernimmt Commits von neun Beitragenden und behebt jedes Glied dieser Kette unter einem Prinzip: Die Zustellungsidentität muss vom Besitzer-Profil des Jobs kommen. Konkret:

• Jeder Ticker eines Profils bekommt seine eigene Adapter-Map: Beim Multiplexing (_start_multiplex) erhält der Ticker jedes Profils seine eigene Platform-Adapter-Map; geteilte Adapter bleiben dem Default-Profil vorbehalten und dienen niemals als Fallback für nicht verbundene Sekundärprofile;
• Der Secret-Scope des Profils umfasst jetzt die Zustellung: Vorher wurde der Scope direkt nach dem Joblauf zurückgesetzt, sodass standalone-send-Fallbacks die Platform-Tokens des ausführenden Prozesses auflösten; jetzt deckt der Scope _deliver_result von Anfang bis Ende ab;
• Home-Chat-IDs werden aus den Secrets des Besitzer-Profils aufgelöst: Ziel-Chat-ID und Thread-ID werden über get_secret im Scope des Besitzer-Profils aufgelöst statt über rohe Umgebungsvariablen;
• Profil-Jobs schreiben Sessions in ihre eigene state.db: Die SessionDB wird über contextvars.copy_context() konstruiert, sodass Cron-Läufe von B aufhören, Sessions in die Datenbank des Default-Profils zu schreiben;
• Preflight-Rettung für Satellitenprofile: Satelliten, die über gateway.profile_routes geroutet werden, lesen die Primärkonfiguration direkt, scheitern fail-closed und geben keine Umgebung preis;
• cron status sagt die Wahrheit: Die systemd-PID-Erkennung ist auf den Dienstnamen dieses Profils begrenzt, und ein nie gesehener Heartbeat erscheint als Warnung statt als Grün.

So verifizierst du es auf deinem Rechner

Nach dem Update auf das aktuelle main prüfst du zuerst, ob der Scheduler-Status deines Profils jetzt vertrauenswürdig ist:

# Status für den eigenen Scheduler eines Profils — kein „irgendein Gateway lebt“-Grünlicht mehr
hermes -p work cron status

Danach führst du einen Cron-Job mit Zustellung aus und beobachtest, ob die Nachricht vom eigenen Bot genau dieses Profils kommt und im Home-Chat dieses Profils landet. Für alle, die mehrere Profile über mehrere Plattformen betreiben, ist das eine sofort sichtbare Verbesserung: Ergebnisse verschwinden nicht mehr, Kreuzgespräche sind weg, und die Geistermeldungen „Job erfolgreich, aber niemand hat etwas erhalten“ hören auf.

Wann du es nutzen kannst

PR #99375 wurde am 31. August 2026 gemerged und ist nur auf main — noch in keinem Release. Sie behebt ein Bündel echter Nutzerberichte: #94862, #97909, #99028, #98790, #97476 — alles Beschwerden der Art „Nachricht kam nie an“ oder „Status lügt“.

Mehrere Profile gehören zu den am meisten unterschätzten Fähigkeiten von Hermes: Jedes Profil bekommt seine eigene Identität, eigene Erinnerungen und eigene Bots. Um sie gut zu nutzen, starte mit unserem kompletten Multi-Profil-Guide und Feishu-Multi-Profil-Routing; das vollständige Cron-Playbook liegt im kompletten Cron-Automations-Guide.