Technisches Postmortem vom 14. Juli 2026. Alles Folgende ist im Chromium-Bug 534655509 dokumentiert.
Update vom 19. August 2026. Die Schlussfolgerung dieses Postmortems war falsch, deshalb korrigieren wir sie hier oben. Der Absturz war kein Remote-Experiment, das Google an jenem Nachmittag abgeschaltet hat: Er lebt weiter. Wir haben ihn am 28. Juli erneut auf dem stabilen Chrome 150.0.7871.187 und am 19. August auf 151.0.7922.138 ausgelöst, samt Speicherabbildern. Wir wissen inzwischen auch, was ihn tatsächlich auslöst, und das ist enger, als wir dachten: Es braucht drei Dinge gleichzeitig, einen Router, der per DOM-Austausch navigiert (hier der ClientRouter von Astro), und beide Wege, WebMCP-Werkzeuge zu registrieren, den imperativen und den deklarativen, auf derselben Seite. Mit nur einem der beiden Wege stürzt nichts ab. Deshalb ist WebMCP auf kiwop.com wieder eingeschaltet, mit seinen drei Werkzeugen auf dem imperativen Weg. Darunter steht die ursprüngliche Chronik vom 14. Juli, mit korrigierter Bisektion: Zwei ihrer vier Schritte waren falsch.
Am Morgen des 14. Juli sah jeder Besucher von kiwop.com mit Chrome 150, der auf einen Link klickte, seinen Tab sterben: der Bildschirm "Aw, Snap!" und ein Fehlercode, RESULT_CODE_KILLED_BAD_MESSAGE. Die Startseite lud einwandfrei. Jede Seite lud einwandfrei, wenn man sie per direkter URL aufrief. Nur beim Navigieren brach es zusammen. Vier Stunden später verschwand der Bug, ohne dass wir eine einzige Zeile angefasst hätten, und das ist der interessanteste Teil der Geschichte.
Dies ist die Chronik, wie wir den Absturz bis in den Chromium-Quellcode zurückverfolgt haben, warum die wahrscheinlichste Ursache nicht auf unserer Website lag, und was wir über die Arbeit mit experimentellen APIs in Produktion gelernt haben.
Was wir aktiviert hatten: WebMCP
WebMCP ist die experimentelle Chrome-API, mit der eine Website Werkzeuge für KI-Agenten registrieren kann: Man stellt Funktionen über document.modelContext.registerTool() bereit, und ein Agent (eine Erweiterung, ein Browser-Assistent) kann sie entdecken und ausführen, statt sich mit simulierten Klicks durch die Oberfläche zu kämpfen.
Wir hatten sie über den offiziellen Origin Trial aktiviert (Chrome 149 bis 156), mit dem Token in einem Meta-Tag auf allen Seiten. Zwei imperative Werkzeuge und ein deklaratives im Chat-Formular. Das ist Teil unserer Strategie rund um Agentic Browsing: dass Agenten eine Website bedienen können, ist die nächste Stufe, nachdem sie sie zitieren können.
In Chrome 149 lief alles einwandfrei. Mit der Ankunft von Chrome 150 im Stable-Kanal ging die Vorstellung los.
Ein Absturz, den die Health-Checks nicht sehen
Das Tückische an dem Fehler: Unser gesamtes Monitoring stand auf Grün. Die synthetischen Checks riefen URLs auf, und alle lieferten 200 zurück. Die Website war für jeden Überwachungsroboter "gesund" und für jeden navigierenden Menschen kaputt, denn der Absturz trat nur bei der Same-Site-Navigation per Klick auf, also genau der, die den Render-Prozess von Chrome wiederverwendet.
Erste operative Lehre, die wir bereits zur internen Regel gemacht haben: Nach jeder größeren Änderung wird die Website mit echten Klicks in einem echten Browser durchgegangen. Eine 200 sagt nicht, dass die Website funktioniert, sie sagt, dass der Server antwortet.
Die Bisektion: sechs Schritte, um ihn einzukreisen
In einer Entwicklungsumgebung reproduzierten wir den Absturz und entfernten Stück für Stück einzelne Teile. Die erste Tabelle, die von jenem Morgen, ergab, dass der Absturz sogar mit null registrierten Werkzeugen bestehen blieb, und daraus entstand die Hypothese vom Remote-Experiment. Das war Messrauschen. In Ruhe wiederholt am 28. Juli und am 19. August erneut bestätigt, sieht die echte Bisektion so aus:
- Navigations-Router, imperative und deklarative Werkzeuge, alles gleichzeitig: Absturz.
- Dieselben Werkzeuge, aber ohne Router (ganz klassische Navigation): kein Absturz.
- Router und nur die imperativen Werkzeuge: kein Absturz.
- Router und nur das deklarative Werkzeug: kein Absturz.
- Origin Trial aktiv und null registrierte Werkzeuge (
getTools()liefert eine leere Liste): kein Absturz. - Ohne den Origin-Trial-Token (die API existiert auf der Seite gar nicht): einwandfreie Navigation.
Die Schlussfolgerung fällt anders aus als im Juli: Es reicht nicht, dass die API aktiv ist, der Fehler verlangt eine bestimmte Kombination. Und genau das ist die gute Nachricht, denn eine Kombination lässt sich auflösen. An jenem Morgen schalteten wir WebMCP in Produktion ab, und die Website normalisierte sich augenblicklich, was in dem Moment das Dringende war.
Hier die zweite Lehre: Der Token lag in einer Umgebungsvariable, sodass das Abschalten der Funktion nur Minuten kostete. Wäre er fest in den Templates verankert gewesen, wäre die Website weiter kaputt geblieben, während wir unter Zeitdruck am Code herumgeschraubt hätten. Jede experimentelle API in Produktion braucht ihren eigenen Not-Aus-Schalter.
Was der Chromium-Quellcode verrät
Nachdem das Feuer gelöscht war, gingen wir der Sache gründlich auf den Grund. Das Erste, was überrascht: Niemand hatte diesen Absturz zuvor gemeldet. Weder im Chromium-Tracker noch im Repository des Standards noch auf Stack Overflow. Soweit wir wissen, waren wir die Ersten, die ihn gesehen haben.
Das Zweite: Der Origin Trial war in Chrome 150 unangetastet. Der offizielle Eintrag im Chrome Platform Status bestätigt den Milestone-Bereich 149 bis 156 ohne Änderungen. Das Einzige, was sich in 150 änderte, war die Oberfläche der API: navigator.modelContext wurde zugunsten von document.modelContext als veraltet markiert.
Das Dritte, und hier liegt der Kern der Sache: Wir haben den WebMCP-Code zwischen den Chrome-Branches 149 und 150 verglichen, er ist identisch. Das Gating des Origin Trial, die Bindings, alles. Die Regression steckte nicht im WebMCP-Code.
Was wir tatsächlich fanden, ist der genaue Mechanismus des Fehlers. Im Hauptprozess von Chrome überwacht die Datei model_context_user_data.cc den WebMCP-Status dokumentweise. Wenn Render-Prozess und Hauptprozess nicht übereinstimmen, ob WebMCP für ein bestimmtes Dokument aktiviert ist, interpretiert der Hauptprozess die Nachricht des Render-Prozesses als illegales IPC und beendet ihn. Dieser Kill ist buchstäblich der RESULT_CODE_KILLED_BAD_MESSAGE, den wir auf dem Bildschirm sahen. Und es war nicht das erste Mal, dass diese Fehlerfamilie zugeschlagen hat: Eine CL vom Mai 2026 behob einen in der Mechanik identischen Absturz, bei dem der Render-Prozess glaubte, WebMCP sei aktiv, während der Hauptprozess davon nichts wusste.
Die Wendung, die uns auf die falsche Fährte führte: der Bug verschwand, ohne dass wir etwas angefasst hätten
Am Nachmittag versuchten wir, den Absturz in einem sauberen Chrome-Profil zu reproduzieren, mit exakt demselben Build (150.0.7871.115). Unmöglich. Wir testeten acht Konfigurationen, darunter eine exakte Nachbildung des Vorfalls: dieselbe Website, derselbe Token, Navigation mit echten Klicks. Nichts.
Und einige Stunden später ließ sich der Fehler nicht mehr reproduzieren, nicht einmal in dem Browser, der den ganzen Vormittag über abgestürzt war. Gleicher Build, gleiches Profil, gleiche Website, gleicher Token. Auf unserer Seite hatte sich absolut nichts verändert.
Wenn ein zu 100 Prozent reproduzierbarer Fehler ohne jede Änderung auf Clientseite verschwindet, liegt die verbleibende Erklärung auf der Serverseite. Chrome aktiviert und deaktiviert Funktionen im laufenden Betrieb über Finch, sein System für Remote-Experimente: Google kann eine Variante bei einem Prozentsatz der Installationen einschalten und sie per Killswitch innerhalb von Stunden zurücknehmen, ohne den Browser zu aktualisieren. Unsere Arbeitshypothese, so haben wir es auch gemeldet, lautet: Ein WebMCP-bezogenes Experiment wurde an jenem Morgen aktiviert, geriet in Konflikt mit dem dokumentweisen Status des Origin Trial, und jemand bei Google hat beim Anblick der Abstürze den Not-Aus gedrückt. Von außen können wir das nicht sehen; Google kann es in seiner Variations-Historie innerhalb einer Minute nachprüfen, und genau darum haben wir im Bug-Report gebeten.
Der Ehrlichkeit halber: Das ist eine Hypothese. Fakt sind die zeitliche Abfolge, die neun Speicherabbilder, die die Abstürze im lokalen Crashpad hinterlassen haben und die wir als Beweismittel aufbewahren, sowie die Tatsache, dass der Fehler von selbst verschwand.
Und die Hypothese fiel in sich zusammen. Am 28. Juli setzten wir den Token in der Entwicklungsumgebung wieder ein, und der erste Klick im Menü tötete den Tab erneut, auf stabilem Chrome 150, ohne jedes Experiment. Am 19. August wiederholte sich das auf Chrome 151. Was an jenem Juli-Nachmittag verschwunden war, war nicht der Bug, sondern unsere Fähigkeit, ihn zu reproduzieren. Den minimalen Testseiten, die wir gebaut hatten, fehlte der Navigations-Router, und ohne dieses Teil taucht der Absturz nicht auf. Die echte Website hatte ihn, und dort starb der Tab weiterhin.
Was wir gelernt haben, falls Sie mit experimentellen APIs bauen
- Ein Origin Trial holt sich Google in Ihre Runtime. Die Funktion kann sich unter Ihren Füßen ändern, ohne dass Sie irgendetwas deployen. Planen Sie das von Anfang an ein: Experimentelles wird isoliert und ist abschaltbar.
- Not-Aus-Schalter oder gar nichts. Umgebungsvariable, Remote-Flag, was auch immer die Funktion innerhalb von Minuten abschaltet, ohne Templates anzufassen.
- Health-Checks sehen keine Navigationsfehler. Nach jeder ernsthaften Änderung: echte Klicks in einem echten Browser. Ohne Ausnahme.
- Bisektieren Sie mit jeweils einer Variable. Unsere Tabelle ist das, was aus "meine Website ist kaputt" einen Report macht, auf den ein Chromium-Ingenieur reagieren kann.
- Bewahren Sie die Minidumps auf. Das Crashpad-Verzeichnis von Chrome ist die Blackbox des Vorfalls: Die Speicherabbilder vom Vormittag sind der einzige physische Beweis, der vom Vorfall übrig bleibt.
Der Bug-Report, und wie es weitergeht
Der vollständige Fall ist im Bug 534655509 dokumentiert, samt den öffentlichen Reproduktionsseiten, die wir für das Chromium-Team aufgesetzt haben. Google hat den Fehler bis heute nicht reproduziert, und jetzt wissen wir, warum: Getestet wurde unser minimaler Repro, eine klassische Website ohne Navigations-Router, also genau ohne das fehlende Teil.
Seit dem 19. August 2026 ist WebMCP auf kiwop.com wieder eingeschaltet: drei Werkzeuge auf dem imperativen Weg registriert, keines deklarativ, und die Website Klick für Klick durchgegangen, bevor wir etwas für gut befunden haben.
Die grundlegende Lehre bleibt unterdessen dieselbe: Das agentische Web kommt mit jungen APIs, Remote-Experimenten und Fehlern, die kein klassisches Monitoring erkennt. Das ist Neuland, und genau dort arbeiten wir. Wenn Sie möchten, dass Ihre Website für Agenten bereit ist, ohne die Navigation aufs Spiel zu setzen, beginnen Sie mit einem KI-Audit oder schreiben Sie uns.
Häufig gestellte Fragen
Was ist WebMCP?
WebMCP ist eine experimentelle Chrome-API, vorangetrieben von Google und Microsoft im W3C, die es einer Webseite erlaubt, Werkzeuge für KI-Agenten über document.modelContext.registerTool() zu registrieren. Im Juli 2026 befindet sie sich in Chrome von Version 149 bis 156 im Origin Trial, mit stabilem Rollout geplant für Version 157.
Was bedeutet der Fehler RESULT_CODE_KILLED_BAD_MESSAGE in Chrome?
Er bedeutet, dass der Hauptprozess von Chrome den Render-Prozess eines Tabs absichtlich beendet hat, weil dieser eine IPC-Nachricht gesendet hat, die als illegal oder fehlerhaft eingestuft wird. Es ist kein Absturz des Render-Prozesses, sondern eine defensive Hinrichtung, gedacht, um kompromittierte Prozesse zu stoppen. Der Nutzer sieht dabei den Bildschirm "Aw, Snap!".
Was ist Finch, das Experimentiersystem von Chrome?
Finch ist der Mechanismus von Google, um Chrome-Funktionen remote zu aktivieren oder zu deaktivieren, nach Prozentsätzen von Installationen und ohne ein Update zu veröffentlichen. Jedes Chrome lädt regelmäßig einen "Seed" mit Experimenten herunter, der entscheidet, welche Varianten aktiv sind. Das ermöglicht graduelle Rollouts und auch Killswitches: eine Funktion, die Probleme verursacht, innerhalb von Stunden zurückzunehmen.
Ist es riskant, einen Origin Trial in Produktion zu aktivieren?
Es ist vertretbar, wenn Sie es als das behandeln, was es ist: experimenteller Code, dessen Verhalten sich ändern kann, ohne dass Sie selbst etwas tun. Die drei Regeln, die bei uns funktionieren, sind: die Funktion hinter einem Schalter isolieren, der sie innerhalb von Minuten abschaltet, die Website nach jedem Chrome-Versionswechsel mit echter Navigation prüfen, und auch die Navigationsabläufe überwachen, nicht nur die Antwortcodes.
