Technical postmortem from July 14, 2026. Everything that follows is documented in Chromium bug 534655509.
On the morning of July 14, any visitor to kiwop.com running Chrome 150 who clicked a link watched the tab die: an "Aw, Snap!" screen and an error code, RESULT_CODE_KILLED_BAD_MESSAGE. The homepage loaded fine. Every page loaded fine if you landed on it via a direct URL. It only broke on navigation. Four hours later the bug vanished without us touching a single line, and that's the most interesting part of the story.
This is the account of how we cornered the crash all the way to Chromium's source code, why the most likely cause wasn't in our site, and what we learned about building with experimental APIs in production.
What We Had Enabled: WebMCP
WebMCP is Chrome's experimental API that lets a website register tools for AI agents: you expose functions with document.modelContext.registerTool(), and an agent (a browser extension, an assistant) can discover and execute them instead of wrestling with your interface through simulated clicks.
We had it enabled through the official origin trial (Chrome 149 through 156), with the token in a meta tag on every page. Two imperative tools and one declarative tool on the chat form. It's part of our bet on agentic browsing: agents being able to operate a website is the next step after being able to cite it.
On Chrome 149, everything worked. When Chrome 150 hit stable, the trouble started.
A Crash the Health Checks Can't See
The insidious part of the failure is that all our monitoring was green. The synthetic checks request URLs and every single one returned 200. The site was "healthy" for any watchdog robot and broken for any human navigating it, because the crash only triggered on same-site navigation initiated by a click, the kind that reuses Chrome's render process.
First operational lesson, one we've already turned into internal policy: after a significant change, walk the site with real clicks in a real browser. A 200 doesn't say the site works, it says the server responds.
The Bisection: Four Steps to Corner It
In a development environment we reproduced the crash and started removing pieces, one at a time:
- Imperative and declarative tools active: crash.
- Only the imperative tools, declarative off: crash.
- Origin trial active with zero tools registered (
getTools()returns an empty list): crash anyway. - No origin trial token (the API doesn't even exist on the page): navigation works perfectly.
The conclusion was uncomfortable but clear: it wasn't our use of the API. The mere presence of the token was enough to break navigation across the entire site. We disabled WebMCP in production and the site returned to normal immediately.
Here's the second lesson: the token lived in an environment variable, so disabling the feature took minutes. Had it been hardcoded into the templates, the site would have stayed broken while we raced to patch code under pressure. Every experimental API in production needs a kill switch.
What the Chromium Source Code Says
With the fire out, we dug in. The first surprise: nobody had reported this crash. Not on the Chromium tracker, not in the spec's repository, not on Stack Overflow. As far as we could tell, we were the first to see it.
The second: the origin trial was untouched in Chrome 150. The official Chrome Platform Status entry confirms the 149 to 156 milestone range with no changes. The only thing that changed in 150 was the API surface: navigator.modelContext was deprecated in favor of document.modelContext.
The third, and here's the crux of it: we compared the WebMCP code between the Chrome 149 and 150 branches, and it's identical. The origin trial gating, the bindings, all of it. The regression wasn't in WebMCP's code.
What we did find is the exact mechanism of the error. In Chrome's browser process, the file model_context_user_data.cc tracks WebMCP's state document by document. If the render process and the browser process disagree about whether WebMCP is enabled for a given document, the browser process interprets the render's message as illegal IPC and kills it. That kill is literally the RESULT_CODE_KILLED_BAD_MESSAGE we were seeing on screen. And it wasn't the first time this family of bugs had bitten: a CL from May 2026 fixed a crash identical in mechanics, where the render believed WebMCP was active and the browser process hadn't gotten the memo.
The Twist: The Bug Vanished Without Us Touching Anything
In the afternoon we tried to reproduce the crash on a clean Chrome profile, with the exact same build (150.0.7871.115). No luck. We tried eight configurations, including an exact replica of the incident: the same site, the same token, navigation with real clicks. Nothing.
And a few hours later it no longer reproduced even in the browser that had been crashing all morning. Same build, same profile, same site, same token. Nothing had changed on our end whatsoever.
When a 100% reproducible failure disappears with zero changes on the client, the explanation that's left lives on the server side. Chrome turns features on and off live through Finch, its remote experimentation system: Google can flip on a variant for a percentage of installs and revert it with a kill switch within hours, without shipping a browser update. Our working hypothesis, and the one we've reported, is that a WebMCP-related experiment was enabled that morning, conflicted with the origin trial's per-document state, and someone at Google hit the kill switch after seeing the crashes. We can't see this from the outside; Google can check it against their variations history in a minute, and that's exactly what we asked for in the report.
For the record, in the interest of honesty: this is a hypothesis. What is fact is the timeline, the nine memory dumps the crashes left in the local Crashpad directory, which we kept as evidence, and that the bug died on its own.
What We Learned, in Case You're Building with Experimental APIs
- An origin trial puts Google inside your runtime. The feature can change under your feet without you shipping anything. Design for it: experimental code gets isolated and gets a way to turn it off.
- A kill switch, or nothing. An environment variable, a remote flag, whatever it takes to disable the feature in minutes without touching templates.
- Health checks can't see navigation breakage. After every serious change, real clicks in a real browser. No exceptions.
- Bisect one variable at a time. Our four-step table is what turns "my site is broken" into a report a Chromium engineer can act on.
- Keep the minidumps. Chrome's Crashpad directory is the accident's black box: that morning's dumps are the only physical evidence left of the incident.
The Report, and What Happens Now
The full case is in bug 534655509, with the public reproduction pages we built for the Chromium team. WebMCP remains disabled on kiwop.com and will come back once the bug gets a response or once Chrome 151 hits stable, whichever comes first. The day it comes back, we'll walk the site click by click again before calling anything good.
In the meantime, the underlying lesson doesn't change: the agentic web arrives with young APIs, remote experiments, and errors that no classic monitor catches. It's new ground, and it's exactly where we work. If you want your site ready for agents without gambling on navigation along the way, start with an AI audit or get in touch.
Frequently Asked Questions
What is WebMCP?
WebMCP is an experimental Chrome API, driven by Google and Microsoft at the W3C, that lets a web page register tools for AI agents through document.modelContext.registerTool(). As of July 2026, it's in origin trial in Chrome from version 149 through 156, with a stable rollout planned for 157.
What does Chrome's RESULT_CODE_KILLED_BAD_MESSAGE error mean?
It means Chrome's browser process has deliberately killed a tab's render process for sending it an IPC message it considers illegal or malformed. It isn't a render hang: it's a defensive kill, meant to stop compromised processes in their tracks. The user sees it as an "Aw, Snap!" screen.
What is Finch, Chrome's experimentation system?
Finch is Google's mechanism for turning Chrome features on or off remotely, by percentage of installs and without shipping an update. Every Chrome instance periodically downloads a "seed" of experiments that decides which variants are active. It enables gradual rollouts as well as kill switches: reverting a feature causing problems within hours.
Is it risky to enable an origin trial in production?
It's manageable if you treat it for what it is: experimental code whose behavior can change without you doing anything. The three rules that work for us are isolating the feature behind a switch that disables it in minutes, verifying the site by actually navigating it after every Chrome version change, and monitoring navigation flows too, not just response codes.
