Postmortem técnico del 14 de julio de 2026. Todo lo que sigue está documentado en el bug 534655509 de Chromium.
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: cuatro pasos para acorralarlo
En un entorno de desarrollo replicamos el crash y fuimos quitando piezas, una cada vez:
- Herramientas imperativas y declarativa activas: crash.
- Solo las imperativas, declarativa fuera: crash.
- Origin trial activo y cero herramientas registradas (
getTools()devuelve una lista vacía): crash igual. - Sin el token del origin trial (la API ni siquiera existe en la página): navegación perfecta.
La conclusión era incómoda pero clara: no era nuestro uso de la API. Bastaba la presencia del token para romper la navegación del sitio entero. Apagamos WebMCP en producción y la web volvió a la normalidad al momento.
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: 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.
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 de cuatro pasos 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. WebMCP sigue apagado en kiwop.com y volverá cuando el bug tenga respuesta o cuando Chrome 151 llegue a estable, lo que ocurra antes. El día que vuelva, la web se paseará otra vez 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.
