Hay un tipo de problema que no sabes que tienes hasta que un día te sientas encima.
El mío era este: demasiadas extensiones de Chrome instaladas. Algunas para el trabajo, otras para proyectos concretos, otras que instalé una tarde para probar algo y siguen ahí sin ningún motivo… El navegador va bien, más o menos, pero nunca sabes exactamente qué tienes activo ni por qué. Y digo más o menos, porque nunca sabes cómo te está afectando tener tantas activas en términos de velocidad…
La solución de toda la vida es entrar a chrome://extensions, ir desactivando una a una, y acordarte de volver a activarlas cuando las necesites. Funciona, pero también es un rollo.
Por qué necesitaba un gestor de extensiones de Chrome
Quería algo más simple: agrupar las extensiones por contexto —las del trabajo, las de diseño, las de desarrollo, las personales— y poder cambiar entre perfiles de un clic. Algo como los perfiles de Chrome, pero solo para extensiones.
Busqué si existía algo así en la Chrome Web Store, y encontré varias buscando «extension manager» pero sencillamente tenían demasiadas cosas. Así que decidí hacerme una.
El contexto: llevo un tiempo trabajando con Claude Code para este tipo de proyectos pequeños. Ya he hecho una extensión de fichaje automático con Factorial, un contador/gestor de pestañas, un validador de schema.org y varias extensiones SEO. La dinámica ya la conozco: le explico la idea, definimos juntos la estructura, y a partir de ahí voy iterando en conversación.
La idea: activar y desactivar extensiones de Chrome en grupo
La extensión necesitaba tres cosas básicas: leer las extensiones instaladas, guardar grupos con nombres, y activarlas o desactivarlas en bloque.
Para leer y controlar extensiones en Chrome existe la API chrome.management. Al parecer, el problema es que es un permiso marcado como «sensible» por Google. Si algún día quiero publicarla en la Chrome Web Store, voy a tener que justificar por escrito por qué la uso. De esto no tenía ni idea, pero Claude me advirtió al final del todo.
El otro tema era Manifest V3. Todas mis extensiones ya van con MV3 —es el estándar actual, MV2 está siendo descontinuado— y eso significa que el service worker tiene restricciones importantes: no puede mantener estado en memoria entre llamadas, y hay cosas que antes funcionaban en background scripts que ahora tienes que repensar. De nuevo, todo esto lo gestionaría Claude.
De este modo, al final, toda la lógica vive en el popup, que sí puede usar las APIs directamente. El background.js se quedó casi vacío, solo con el listener de instalación y un handler de ping que no hace gran cosa. Todo esto me lo iba contando Claude sobre la marcha.
De la idea al código: planificar una extensión Chrome con IA
Lo primero que hice fue describir el proyecto completo y pedirle a Claude que entrara en modo planificación antes de escribir una sola línea de código. Quería una arquitectura clara antes de empezar a iterar.
El plan definió seis archivos: manifest, popup HTML, popup JS, CSS, background y los iconos. El modelo de datos era simple: grupos guardados en chrome.storage.local, cada uno con un ID generado por timestamp, un nombre y un array de IDs de extensión. Confieso que no he mirado mucho esta parte (nada).
Lo más interesante del plan fue la gestión de corner cases. Extensiones que desaparecen del sistema después de haberse añadido a un grupo. Extensiones de sistema o de políticas de empresa que no se pueden desactivar. La propia extensión que no puede desactivarse a sí misma. Todos esos casos estaban previstos antes de escribir código.
Eso es algo que he aprendido trabajando con IA: si le das el contexto completo al principio, los problemas raros aparecen en el plan y no cuando ya llevas un rato depurando.
Cómo añadí la función de desactivar extensiones en bulk y otras mejoras
El primer popup funcionaba. Podías crear grupos, añadir extensiones, activarlas o desactivarlas. Pero faltaban cosas que solo notas cuando lo usas de verdad.
El badge que muestra «X/Y activas» en cada grupo marcaba mal el denominador. Si tenías 17 extensiones en un grupo pero una era de sistema y estaba filtrada de la lista gestionable, el badge mostraba «16/17» aunque activas estuvieran todas las posibles. El número incorrecto no rompía nada, pero generaba desconfianza. Lo arreglamos cambiando cómo se calcula el total: solo cuentan las extensiones que Chrome puede realmente gestionar.
Los botones de subir y bajar grupos vinieron después. Al principio el orden era el de creación, fijo. En cuanto tienes tres o cuatro grupos te das cuenta de que quieres los más usados arriba. Dos botones, una función de intercambio en el array, guardado inmediato en storage. Gracias Claude.
El toast de feedback —ese aviso pequeño que aparece cuando activas o desactivas extensiones— se ponía encima de la barra de botones inferior y quedaba feo. Un ajuste de posición en CSS, asunto resuelto.
El botón de «Activar todas» para activar todas las extensiones de golpe llegó casi al final. Y con él, el de «Desactivar todas». Ese par de botones no es lo que más uso, pero están muy a mano y para un golpetazo rápido vienen bien.
Publicar en Chrome Web Store: permisos, CSP y compliance
Cuando terminé la funcionalidad, le pedí a Claude que hiciera una revisión de seguridad como si fuera a publicarla en la Chrome Web Store.
Esto es algo que normalmente se salta. Y es un error. Tengo un promt «final» específico para esto.
El reporte salió limpio en los puntos críticos —sin eval, sin código remoto, sin innerHTML con datos sin sanitizar, sin host_permissions innecesarios— pero apareció algo que no había pensado: faltaba declarar la Content Security Policy explícita en el manifest. MV3 ya aplica una CSP restrictiva por defecto, pero los revisores de Google quieren verla declarada. También faltaba minimum_chrome_version, que evita que alguien con una versión antigua instale la extensión y no entienda por qué falla.
Dos líneas en el manifest.json. Pero líneas que marcan la diferencia entre un rechazo en revisión y que te lo acepten a la primera.
Y la justificación del permiso management, que es el núcleo de todo esto: Google va a pedir que justifiques por escrito para qué lo usas. El texto tiene que explicar
- qué hace exactamente la extensión con ese permiso,
- por qué no hay alternativa menos invasiva, y
- que ningún dato sale del dispositivo.
Lo que aprendí construyendo un gestor de extensiones con Claude
Este proyecto tardó menos de lo que parece. La extensión completa, con el ciclo de planificación, implementación, iteración y revisión de compliance, se construyó en una sola sesión de trabajo.
Lo que cambia cuando trabajas con IA no es que el código sea mágicamente perfecto desde el primer intento. Es que puedes plantear el problema completo antes de escribir una línea, anticipar los casos raros, y cuando algo falla tienes a alguien con quien depurar en lenguaje natural en lugar de releer Stack Overflow durante veinte minutos. XD
La extensión ya la uso. Tengo dos grupos: Prioritarias y Extras. Cambiar entre ellos es un clic. Los dados físicos 😉 siguen debajo del sofá, pero las extensiones están, por fin, donde deben estar.
La puedes descargar desde aquí: https://github.com/javierferraz/gestor-extensiones
