Technische postmortem van 14 juli 2026. Alles wat volgt is gedocumenteerd in bug 534655509 van Chromium.
De ochtend van 14 juli zag elke bezoeker van kiwop.com met Chrome 150 die op een link klikte de tab sterven: een "Aw, Snap!"-scherm en een foutcode, RESULT_CODE_KILLED_BAD_MESSAGE. De homepage laadde perfect. Elke pagina laadde perfect als je er via een directe URL naartoe ging. Alleen navigeren brak het. Vier uur later verdween de bug zonder dat we ook maar één regel hadden aangeraakt, en dat is het interessantste deel van dit verhaal.
Dit is het verslag van hoe we de crash terugvoerden tot de broncode van Chromium, waarom de meest waarschijnlijke oorzaak niet in onze website lag, en wat we hebben geleerd over bouwen met experimentele API's in productie.
Wat we actief hadden: WebMCP
WebMCP is de experimentele Chrome-API waarmee een website tools kan registreren voor AI-agents: functies worden beschikbaar gesteld via document.modelContext.registerTool(), en een agent (een extensie, een browserassistent) kan ze ontdekken en uitvoeren in plaats van zich met gesimuleerde kliks door de interface heen te worstelen.
We hadden hem actief via de officiële origin trial (Chrome 149 tot en met 156), met de token in een meta-tag op elke pagina. Twee imperatieve tools en een declaratieve tool in het chatformulier. Dit maakt deel uit van onze inzet op agentic browsing: dat agents een website kunnen bedienen is de volgende stap nadat ze haar al konden citeren.
In Chrome 149 werkte alles. Met de komst van Chrome 150 naar stable begon het probleem.
Een crash die de health checks niet zien
Het verraderlijke aan de fout was dat al onze monitoring op groen stond. De synthetische checks vragen URL's op en die gaven allemaal 200 terug. De website was "gezond" voor elke bewakingsrobot en kapot voor elke mens die navigeerde, omdat de crash alleen optrad bij same-site-navigatie die met een klik werd gestart, de navigatie die het renderproces van Chrome hergebruikt.
Eerste operationele les, die we inmiddels tot interne norm hebben gemaakt: na een belangrijke wijziging lopen we de website na met echte kliks in een echte browser. Een 200 zegt niet dat de website werkt, het zegt dat de server antwoordt.
De bisectie: vier stappen om de fout in te sluiten
In een ontwikkelomgeving reproduceerden we de crash en verwijderden we stap voor stap onderdelen:
- Imperatieve en declaratieve tools actief: crash.
- Alleen de imperatieve tools, declaratieve uit: crash.
- Origin trial actief en geen enkele geregistreerde tool (
getTools()geeft een lege lijst terug): nog steeds crash. - Zonder de token van de origin trial (de API bestaat dan niet eens op de pagina): navigatie zonder problemen.
De conclusie was ongemakkelijk maar duidelijk: het lag niet aan ons gebruik van de API. De aanwezigheid van de token alleen al was genoeg om de navigatie van de hele site te breken. We zetten WebMCP in productie uit en de website was meteen weer normaal.
Dan de tweede les: de token stond in een omgevingsvariabele, dus de feature uitzetten kostte minuten. Had die in de templates gestaan, dan was de website kapot gebleven terwijl we onder tijdsdruk code moesten aanpassen. Elke experimentele API in productie heeft een aan/uit-schakelaar nodig.
Wat de Chromium-broncode zegt
Met het vuur geblust, gingen we grondig verder onderzoeken. Het eerste dat verbaast: niemand had deze crash gemeld. Niet in de Chromium-tracker, niet in de repository van de standaard, niet op Stack Overflow. Voor zover wij weten waren we de eersten die hem zagen.
Het tweede: de origin trial was in Chrome 150 ongewijzigd. De officiële vermelding op Chrome Platform Status bevestigt het milestone-bereik 149 tot en met 156 zonder aanpassingen. Het enige dat in 150 veranderde was het oppervlak van de API: navigator.modelContext werd afgekeurd (deprecated) ten gunste van document.modelContext.
Het derde, en hier zit de kern: we vergeleken de WebMCP-code tussen de branches van Chrome 149 en 150, en die is identiek. De gating van de origin trial, de bindings, alles. De regressie zat niet in de WebMCP-code.
Wat we wel vonden is het exacte mechanisme achter de fout. In het hoofdproces van Chrome houdt het bestand model_context_user_data.cc per document de status van WebMCP bij. Als het renderproces en het hoofdproces het oneens zijn over of WebMCP voor een bepaald document ingeschakeld is, interpreteert het hoofdproces het bericht van het renderproces als illegale IPC en beëindigt het dat proces. Die kill is letterlijk de RESULT_CODE_KILLED_BAD_MESSAGE die we op het scherm zagen. En het was niet de eerste keer dat dit soort fouten toesloeg: een CL uit mei 2026 loste een qua mechaniek identieke crash op, waarbij het renderproces dacht dat WebMCP actief was terwijl het hoofdproces daar niet van op de hoogte was.
De wending: de bug verdween zonder dat we iets aanraakten
's Middags probeerden we de crash te reproduceren in een schoon Chrome-profiel, met exact dezelfde build (150.0.7871.115). Onmogelijk. We probeerden acht configuraties, waaronder een exacte replica van het incident: dezelfde website, dezelfde token, navigatie met echte kliks. Niets.
En een paar uur later reproduceerde het probleem zelfs niet meer in de browser waarin het de hele ochtend had gecrasht. Zelfde build, zelfde profiel, zelfde website, zelfde token. Aan onze kant was er absoluut niets veranderd.
Als een voor 100% reproduceerbare fout verdwijnt zonder enige wijziging aan de clientkant, ligt de resterende verklaring aan de serverkant. Chrome schakelt functies live in en uit via Finch, zijn systeem van externe experimenten: Google kan een variant activeren voor een percentage van de installaties en die binnen enkele uren terugdraaien met een killswitch, zonder dat de browser wordt bijgewerkt. Onze werkhypothese, en zo hebben we die ook gerapporteerd, is dat er die ochtend een experiment gerelateerd aan WebMCP werd geactiveerd, dat dit in conflict kwam met de per-document-status van de origin trial, en dat iemand bij Google na het zien van de crashes de killswitch heeft omgezet. Van buitenaf kunnen we dat niet zien; Google kan het binnen een minuut nakijken in zijn variatiegeschiedenis, en dat is precies wat we in het rapport hebben gevraagd.
Voor de duidelijkheid: dit is een hypothese. Wat wel vaststaat is de tijdlijn, de negen geheugendumps die de crashes achterlieten in de lokale Crashpad en die we als bewijs bewaren, en dat de fout vanzelf verdween.
Wat we hebben geleerd, voor als u bouwt met experimentele API's
- Een origin trial brengt Google in uw runtime. De feature kan onder uw voeten veranderen zonder dat u zelf iets deployt. Houd daar in het ontwerp rekening mee: isoleer wat experimenteel is en zorg dat het uitgeschakeld kan worden.
- Een aan/uit-schakelaar, of niets. Een omgevingsvariabele, een externe flag, wat dan ook waarmee u de feature binnen minuten uitzet zonder templates aan te raken.
- Health checks zien navigatiestoringen niet. Na elke ingrijpende wijziging: echte kliks in een echte browser. Zonder uitzondering.
- Bisecteer met steeds één variabele tegelijk. Ons overzicht van vier stappen is wat "mijn website is kapot" omzet in een rapport waar een Chromium-engineer mee aan de slag kan.
- Bewaar de minidumps. De Crashpad-map van Chrome is de zwarte doos van het incident: de dumps van die ochtend zijn het enige fysieke bewijs dat van het incident overblijft.
Het rapport, en wat er nu gebeurt
De volledige zaak staat in bug 534655509, met de publieke reproductiepagina's die we voor het Chromium-team hebben opgezet. WebMCP staat nog steeds uit op kiwop.com en komt terug zodra de bug een reactie krijgt of zodra Chrome 151 naar stable gaat, wat zich het eerst voordoet. Op de dag dat het terugkomt, lopen we de website weer klik voor klik na voordat we iets goedkeuren.
De onderliggende les blijft ondertussen dezelfde: het agentische web komt met jonge API's, externe experimenten en fouten die geen enkele klassieke monitor opmerkt. Dat is nieuw terrein, en precies waar wij werken. Wilt u dat uw website klaar is voor agents zonder de navigatie op het spel te zetten, begin dan met een AI-audit of neem contact met ons op.
Veelgestelde vragen
Wat is WebMCP?
WebMCP is een experimentele Chrome-API, voortgetrokken door Google en Microsoft binnen de W3C, waarmee een webpagina tools kan registreren voor AI-agents via document.modelContext.registerTool(). In juli 2026 bevindt de API zich in origin trial in Chrome, van versie 149 tot en met 156, met een stabiele release die voor versie 157 gepland staat.
Wat betekent de foutmelding RESULT_CODE_KILLED_BAD_MESSAGE van Chrome?
Het betekent dat het hoofdproces van Chrome het renderproces van een tab bewust heeft beëindigd omdat het een IPC-bericht ontving dat het als illegaal of misvormd beschouwt. Het is geen crash van het renderproces zelf: het is een defensieve executie, bedoeld om gecompromitteerde processen te stoppen. De gebruiker ziet dit als een "Aw, Snap!"-scherm.
Wat is Finch, het experimentensysteem van Chrome?
Finch is het mechanisme waarmee Google functies van Chrome op afstand kan in- of uitschakelen, per percentage van de installaties en zonder een update uit te brengen. Elke Chrome-installatie haalt periodiek een experimentele "seed" op die bepaalt welke varianten actief zijn. Dit maakt geleidelijke uitrol mogelijk, maar ook killswitches: een functie die problemen veroorzaakt binnen enkele uren terugdraaien.
Is het riskant om een origin trial in productie te activeren?
Het is aanvaardbaar als u het behandelt voor wat het is: experimentele code waarvan het gedrag kan veranderen zonder dat u zelf iets doet. De drie regels die bij ons werken zijn: de feature isoleren achter een schakelaar die hem binnen minuten uitzet, de website daadwerkelijk navigerend controleren na elke Chrome-versiewijziging, en ook de navigatiestromen monitoren, niet alleen de responscodes.
