Postmortem técnico del 14 de julio de 2026. Todo lo que sigue está documentado en el bug 534655509 de Chromium.
Actualización del 19 de agosto de 2026. La conclusión de este postmortem era errónea y la corregimos aquí arriba. El crash no fue un experimento remoto que Google apagó aquella tarde: sigue vivo. Lo hemos vuelto a provocar en Chrome estable 150.0.7871.187 el 28 de julio y en 151.0.7922.138 el 19 de agosto, con sus volcados de memoria. También sabemos ya qué lo dispara, y es más estrecho de lo que creíamos: hacen falta tres cosas a la vez, un router que navega intercambiando el DOM (aquí, el ClientRouter de Astro) y las dos formas de registrar herramientas WebMCP conviviendo en la misma página, la imperativa y la declarativa. Con una sola de las dos vías no crashea. Por eso WebMCP vuelve a estar encendido en kiwop.com, con sus tres herramientas registradas por la vía imperativa. Debajo queda la crónica del 14 de julio, con la bisección corregida: dos de sus cuatro pasos estaban mal.
La mañana del 14 de julio, cualquier visitante de kiwop.com con Chrome 150 que hiciera clic en un enlace veía morir la pestaña: pantalla "Aw, Snap!" y un código de error, RESULT_CODE_KILLED_BAD_MESSAGE. La home cargaba perfecta. Cada página cargaba perfecta si entrabas por URL directa. Solo rompía al navegar. Cuatro horas después el bug desapareció sin que tocáramos una sola línea, y esa es la parte más interesante de la historia.
Esta es la crónica de cómo acorralamos el crash hasta el código fuente de Chromium, por qué la causa más probable no estaba en nuestra web, y qué aprendimos sobre construir con APIs experimentales en producción.
Qué teníamos activo: WebMCP
WebMCP es la API experimental de Chrome que permite a una web registrar herramientas para agentes de IA: expones funciones con document.modelContext.registerTool() y un agente (una extensión, un asistente del navegador) puede descubrirlas y ejecutarlas en vez de pelearse con tu interfaz a golpe de clic simulado.
La teníamos activa mediante el origin trial oficial (Chrome 149 a 156), con el token en una etiqueta meta de todas las páginas. Dos herramientas imperativas y una declarativa en el formulario del chat. Es parte de nuestra apuesta por el agentic browsing: que los agentes puedan operar una web es el siguiente escalón después de que puedan citarla.
En Chrome 149 todo funcionaba. Con la llegada de Chrome 150 a estable, empezó el espectáculo.
Un crash que los health checks no ven
Lo insidioso del fallo es que toda nuestra monitorización estaba en verde. Los checks sintéticos piden URLs y todas devolvían 200. La web estaba "sana" para cualquier robot de vigilancia y rota para cualquier humano que navegara, porque el crash solo saltaba en la navegación same-site iniciada con un clic, la que reutiliza el proceso de render de Chrome.
Primera lección operativa, que ya hemos convertido en norma interna: después de un cambio importante, la web se pasea con clics de verdad en un navegador de verdad. Un 200 no dice que la web funcione, dice que el servidor responde.
La bisección: seis pasos para acorralarlo
En un entorno de desarrollo replicamos el crash y fuimos quitando piezas, una cada vez. La primera tabla, la de aquella mañana, nos salió que el crash aguantaba incluso con cero herramientas registradas, y de ahí nació la hipótesis del experimento remoto. Era ruido de medición. Repetida con calma el 28 de julio y revalidada el 19 de agosto, la bisección real es esta:
- Router de navegación, herramientas imperativas y declarativa, todo a la vez: crash.
- Las mismas herramientas, pero sin el router (navegación clásica de toda la vida): sin crash.
- Router y solo las herramientas imperativas: sin crash.
- Router y solo la declarativa: sin crash.
- Origin trial activo y cero herramientas registradas (
getTools()devuelve una lista vacía): sin crash. - Sin el token del origin trial (la API ni siquiera existe en la página): navegación perfecta.
La conclusión, distinta a la de julio, es que no basta con tener la API activa: el fallo pide una combinación concreta. Y ahí está la buena noticia, porque una combinación se puede deshacer. Aquella mañana apagamos WebMCP en producción y la web volvió a la normalidad al momento, que era lo urgente.
Aquí va la segunda lección: el token vivía en una variable de entorno, así que apagar la feature costó minutos. Si hubiera estado incrustado en las plantillas, la web habría seguido rota mientras tocábamos código a contrarreloj. Toda API experimental en producción necesita su interruptor de apagado.
Lo que dice el código de Chromium
Con el fuego apagado, investigamos a fondo. Lo primero que sorprende: nadie había reportado este crash. Ni en el tracker de Chromium, ni en el repositorio del estándar, ni en Stack Overflow. Éramos, que sepamos, los primeros en verlo.
Lo segundo: el origin trial estaba intacto en Chrome 150. La entrada oficial de Chrome Platform Status confirma el rango de milestones 149 a 156 sin cambios. Lo único que cambió en 150 fue la superficie de la API: navigator.modelContext quedó deprecado en favor de document.modelContext.
Lo tercero, y aquí está la miga: comparamos el código de WebMCP entre las ramas de Chrome 149 y 150, y es idéntico. El gating del origin trial, los bindings, todo. La regresión no estaba en el código de WebMCP.
Lo que sí encontramos es el mecanismo exacto del error. En el proceso principal de Chrome, el fichero model_context_user_data.cc vigila el estado de WebMCP documento a documento. Si el proceso de render y el proceso principal discrepan sobre si WebMCP está habilitado para un documento concreto, el principal interpreta el mensaje del render como IPC ilegal y lo mata. Ese kill es literalmente el RESULT_CODE_KILLED_BAD_MESSAGE que veíamos en pantalla. Y no era la primera vez que esa familia de fallos mordía: una CL de mayo de 2026 arregló un crash idéntico en su mecánica, cuando el render creía que WebMCP estaba activo y el proceso principal no se había enterado.
El giro que nos despistó: el bug se esfumó sin que tocáramos nada
Por la tarde intentamos reproducir el crash en un perfil limpio de Chrome, con el mismo build exacto (150.0.7871.115). Imposible. Probamos ocho configuraciones, incluida una réplica exacta del incidente: la misma web, el mismo token, navegación con clics reales. Nada.
Y unas horas después ya no reproducía ni en el navegador donde había crasheado toda la mañana. Mismo build, mismo perfil, misma web, mismo token. En nuestro lado no había cambiado absolutamente nada.
Cuando un fallo 100% reproducible desaparece sin ningún cambio en el cliente, la explicación que queda vive en el lado del servidor. Chrome activa y desactiva funciones en caliente mediante Finch, su sistema de experimentos remotos: Google puede encender una variante en un porcentaje de instalaciones y revertirla con un killswitch en horas, sin actualizar el navegador. Nuestra hipótesis de trabajo, y así la hemos reportado, es que un experimento relacionado con WebMCP se activó esa mañana, entró en conflicto con el estado por documento del origin trial y alguien en Google le dio al botón de apagar al ver los crashes. Desde fuera no podemos verlo; Google puede comprobarlo en su historial de variaciones en un minuto, y eso es exactamente lo que pedimos en el reporte.
Que conste la honestidad: es una hipótesis. Lo que es un hecho es la secuencia temporal, los nueve volcados de memoria que los crashes dejaron en el Crashpad local y que conservamos como evidencia, y que el fallo murió solo.
Y la hipótesis se cayó. El 28 de julio repusimos el token en el entorno de desarrollo y el primer clic en el menú volvió a matar la pestaña, en Chrome 150 estable, sin experimento que valga. El 19 de agosto se repitió en Chrome 151. Lo que había desaparecido aquella tarde de julio no era el bug: era nuestra capacidad de reproducirlo. Las páginas de prueba mínimas que montamos no llevaban router de navegación, y sin esa pieza el crash no aparece. El sitio real sí lo llevaba, y por eso allí seguía muriendo la pestaña.
Lo que aprendimos, por si construyes con APIs experimentales
- Un origin trial mete a Google en tu runtime. La feature puede cambiar bajo tus pies sin que tú despliegues nada. Asúmelo en el diseño: lo experimental se aísla y se puede apagar.
- Interruptor de apagado o nada. Variable de entorno, flag remota, lo que sea que apague la feature en minutos sin tocar plantillas.
- Los health checks no ven roturas de navegación. Después de cada cambio serio, clics reales en navegador real. Sin excepción.
- Biseca con una variable cada vez. Nuestra tabla es lo que convierte "se me rompe la web" en un reporte que un ingeniero de Chromium puede accionar.
- Guarda los minidumps. El directorio Crashpad de Chrome es la caja negra del accidente: los volcados de la mañana son la única evidencia física que queda del incidente.
El reporte, y qué pasa ahora
El caso completo está en el bug 534655509, con las páginas de reproducción públicas que montamos para el equipo de Chromium. Google todavía no ha reproducido el fallo, y ahora sabemos por qué: probaron nuestro repro mínimo, que es una web clásica sin router de navegación, justo la pieza que faltaba.
WebMCP vuelve a estar encendido en kiwop.com desde el 19 de agosto de 2026: tres herramientas registradas por la vía imperativa, ninguna declarativa, y la web paseada a golpe de clic antes de dar nada por bueno.
Mientras tanto, la moraleja de fondo no cambia: la web agéntica llega con APIs jóvenes, experimentos remotos y errores que ningún monitor clásico detecta. Es terreno nuevo, y es justo donde trabajamos. Si quieres que tu web esté preparada para agentes sin jugarte la navegación por el camino, empieza por una auditoría de IA o escríbenos.
Preguntas frecuentes
¿Qué es WebMCP?
WebMCP es una API experimental de Chrome, impulsada por Google y Microsoft en el W3C, que permite a una página web registrar herramientas para agentes de IA mediante document.modelContext.registerTool(). En julio de 2026 está en origin trial en Chrome desde la versión 149 hasta la 156, con lanzamiento estable previsto para la 157.
¿Qué significa el error RESULT_CODE_KILLED_BAD_MESSAGE de Chrome?
Significa que el proceso principal de Chrome ha matado deliberadamente al proceso de render de una pestaña por enviarle un mensaje IPC que considera ilegal o malformado. No es un cuelgue del render: es una ejecución defensiva, pensada para frenar procesos comprometidos. El usuario lo ve como una pantalla "Aw, Snap!".
¿Qué es Finch, el sistema de experimentos de Chrome?
Finch es el mecanismo de Google para activar o desactivar funciones de Chrome en remoto, por porcentajes de instalaciones y sin publicar una actualización. Cada Chrome descarga periódicamente una "semilla" de experimentos que decide qué variantes tiene activas. Permite lanzamientos graduales y también killswitches: revertir en horas una función que está causando problemas.
¿Es arriesgado activar un origin trial en producción?
Es asumible si lo tratas como lo que es: código experimental cuyo comportamiento puede cambiar sin que tú hagas nada. Las tres reglas que nos funcionan son aislar la feature detrás de un interruptor que la apague en minutos, verificar la web navegando de verdad tras cada cambio de versión de Chrome, y monitorizar también los flujos de navegación, no solo los códigos de respuesta.
