Technisches Postmortem vom 14. Juli 2026. Alles Folgende ist im Chromium-Bug 534655509 dokumentiert.
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: vier Schritte, um ihn einzukreisen
In einer Entwicklungsumgebung reproduzierten wir den Absturz und entfernten Stück für Stück einzelne Teile:
- Imperative und deklarative Werkzeuge aktiv: Absturz.
- Nur die imperativen, deklaratives Werkzeug entfernt: Absturz.
- Origin Trial aktiv und null registrierte Werkzeuge (
getTools()liefert eine leere Liste): trotzdem Absturz. - Ohne den Origin-Trial-Token (die API existiert auf der Seite gar nicht): einwandfreie Navigation.
Die Schlussfolgerung war unbequem, aber eindeutig: Es lag nicht an unserer Nutzung der API. Allein die Anwesenheit des Tokens reichte, um die Navigation der gesamten Website zu zerstören. Wir schalteten WebMCP in Produktion ab, und die Website normalisierte sich augenblicklich.
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: 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.
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 vierstufige 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. WebMCP bleibt auf kiwop.com abgeschaltet und kommt zurück, sobald der Bug eine Antwort erhält oder Chrome 151 den Stable-Kanal erreicht, je nachdem, was zuerst eintritt. An dem Tag, an dem es zurückkommt, wird die Website erneut Klick für Klick durchgegangen, bevor wir irgendetwas für gut befinden.
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.
