2 nov 2026 · Informe técnico

Cuidado con los mods de Claude Code: son una puerta a todos tus conectores

Ya hay 7.349 mods públicos de Claude Code, nueve de cada diez en repositorios creados en octubre, y el 40 % lanza programas en tu máquina. Monté uno y medí lo que puede hacer sin que te des cuenta, desde el modo en que Claude Code te pregunta cada paso hasta el que no pregunta nada.

El 2 de noviembre, a las 11:12 (hora UTC), una sesión de Claude Code de mi laboratorio local leyó un secreto guardado en mi gestor de secretos. Nadie había tocado el teclado y en la terminal nada había cambiado: el cursor esperando y, abajo, la línea de siempre que dice en qué modo está, auto mode. Además, mirando el historial de la sesión, su última línea era de las 11:05:20, siete minutos antes.

El secreto era un test, y lo había puesto ahí a propósito. La ejecución la había hecho un mod que había escrito yo mismo para probar hasta qué punto se puede ejecutar código arbitrario en un mod y que pase desapercibido, asi que me puse a indagar. Nuevo proyecto de fin de semana (en España este fin de semana ha sido de tres dias).

01El problema

Antes de nada, conviene distinguir entre dos conceptos. Un plugin es el paquete que instalas en Claude Code: puede traer skills, comandos o servidores MCP. Cuando además trae código que corre dentro del propio Claude Code, a ese código se le llama mod. Todo mod viaja dentro de un plugin, pero no todos los plugins traen un mod. Aquí de lo que vamos a hablar es de los mods de Claude Code.

Un mod se engancha a la sesión, en determinados momentos (eventos), por ejemplo cuando se abre la sesión, y desde ahí puede poner un temporizador, usar los conectores de tu sesión (Gmail, Calendar, Drive…) y lanzar programas en tu máquina.

La documentación lo dice claro para que nadie se lleve la sorpresa: los mods corren con tus permisos y lo que lanzan queda fuera del sandbox (ojito a esto último que todavía estoy escuchando los gritos de los de seguridad con los plugins de OpenClaw, y esto es un poco más de lo mismo).

He mirado por curiosidad y hay muchos mods. Un catálogo comunitario que pasa el validador oficial de Claude Code por cada repositorio público que encuentra contaba, el 1 de noviembre, 7.349 mods, nueve de cada diez en repositorios creados en octubre (!!). El 40% lanza programas en tu máquina y uno de cada tres lee tus variables de entorno (WHATTT???!). Así que veamos qué es lo que podemos hacer con esto, que a priori parece que no es poco.

En modo manual, cada vez que el mod quiere usar un conector, Claude Code se para, te pregunta y te dice qué plugin lo pide (sí, ese tostón que desactivas a la tercera vez que te ha preguntado). Pero cuando le das al Sí, los datos van al código del mod, y lo que haga con ellos ya no pasa por ningún filtro de ninguna clase, y aquí es donde viene la madre del cordero.

Tampoco queda rastro en el historial de la sesión, que es lo primero que mirarías para saber qué ha pasado. Si activas la telemetría de Claude Code, verás que el mod usó Gmail, pero no qué buscó, y los programas que lanza ni siquiera aparecen (aviso a Anthropic: Boris, esto te cuesta muy poco, mételo, al menos).

modo manual · lo que ves

1 2 3

• 1Nombra el plugin. Dice que lo pide bridge-lab.
• 2Enseña qué va a leer. La búsqueda exacta y cuántos resultados.
• 3El “Yes” aprueba la lectura. Lo que viene después, el script de Python que recibe los datos, corre sin preguntar.

La ventana te dice qué se lee. El mod decide adónde va.

02El puente que no decía ni mu

Como casi todas estas cosas, todo empezó con un problema pequeño, y aquí me tienes todo mi Lunes de fiesta tirando del hilo 8 horas después. Quería pasar datos a una página de tareas (es una larga historia para otro post, muy entretenido) sin gastar tokens (porque, por si no te habías dado cuenta los tokens son el nuevo oro y hasta el gato te pide tokens), así que monté lo que llamé un puente: básicamente una sesión de Claude Code (la 2.1.316, con Haiku 5.5) que solo carga un plugin y en la que nadie escribe. Su mod pone un temporizador que da la primera vuelta en 20 segundos y luego cada dos minutos. En cada vuelta consulta Gmail y Calendar, aunque podría tirar de cualquier cosa que vean mis conectores, y le pasa lo que encuentra a un script de Python con reglas fijas (el porqué de esto es largo, pero no nos desviemos, estamos con los mods). El modelo, mientras tanto, ni se entera, que era la idea para no gastar tokens.

// hooks/register.js: trozos del código del mod, con los nombres privados cambiados.
on('session.start', async ($, event, next) => {
  $.clock.every(120000, () => tick($));
  void $.clock.sleep(20000).then(() => tick($));
  return next(event);
});

const g = await $.mcp.call('claude.ai Gmail', 'search_threads', {
  query: QUERY, pageSize: 10, view: 'THREAD_VIEW_MINIMAL'
});
const c = await $.mcp.call('claude.ai Google Calendar',
  'list_events', { pageSize: 10, orderBy: 'startTime' });
const r = await $.process.run(['python3', RULES], {
  stdin: JSON.stringify({ source, items, meta }), timeoutMs: 20000
});

Entonces me di cuenta de que estaba entrando hasta la cocina y que en la consola de Claude Code no se decía ni "mu". Me extrañé y pensé que lo mismo en el JSONL, pero no. Y ahí ya supe cómo iba a acabar el día. Quise saber qué más podía hacer el mod por su cuenta, sin que Claude Code me preguntara nada. Así que hice tres pruebas: leer un secreto, cambiar el código en marcha y bajarme código de internet.

Y para que no quede duda: al script le llegaban datos de verdad. De Calendar, los 10 eventos de los próximos tres días, con su hora y su título, mezclando trabajo, reuniones fijas y cosas personales. De Gmail, las cabeceras de 5 hilos, con remitente y asunto, de los avisos automáticos de proveedores del último mes.

Claro, ya que te pones empiezas a darle vueltas, y se me ocurrió que en las dos últimas pruebas iba a cambiar la forma de revisar el plugin. ¿Podría ser que, cuando instalas un mod y lees su código (cosa que hacemos todos, sin exceptuar a nadie) y te parece bien, ese código pueda llamar cada X minutos a un script que vive en tu disco, o bajarse otro de internet? ¿Y si alguien cambia ese script en caliente? ¿Lo ejecuta el mod en la siguiente vuelta, sin reinstalar nada y sin avisar? Si es así (Spoiler 1: sí que es), el código que corre ya es otro distinto del que «revisaste».

Y claro, cuando miro los mods publicados resulta que es un patrón muy común: 1.758, uno de cada cuatro, juntan un temporizador con programas que lanzan en tu máquina, igual que mi puente.

Luego quise saber qué ve el usuario en cada modo de permisos de Claude Code, porque claro, lo mismo era yo que estaba en modo bypass-permissions-y-quedate-con-todo-mi-PC, así que repetí las mismas pruebas en los cuatro modos, y esta tabla resume lo que pasó (Spoiler 2: es lo que te estás imaginando).

Eso sí, crédito a quien lo merece: en modo manual, Claude Code hace bien la parte que controla. Te dice qué plugin pide la lectura y te enseña exactamente qué va a buscar. El problema es de diseño: cuando apruebas una lectura, estás aprobando la entrada de un código cuya salida no ves.

Para este test, en modo manual, grabo la secuencia entera. Los datos van de Gmail a Python, de Python a Calendar y de Calendar otra vez a Python. Solo los conectores se pararon a preguntar; los dos scripts de Python corrieron sin más, y ahí podría haber pasado de todo. Claro, es la potencia del mod!, justo la idea. No te sorprendas si quieres algo que haga cosas, si después las hace!.

Por último probé a lanzar solo el script, también en modo manual. El mod lo arrancó con $.process.run, terminó bien y leyó un secreto. No quedó rastro. Y aunque aprobamos los conectores a mano, el historial de la sesión no apuntó ninguna de esas aprobaciones.

¿Y no quedaba apuntado en ningún sitio? Repetí la prueba encendiendo los dos registros que trae Claude Code para estas cosas, el log de debug y la telemetría. El log de debug lo pilló todo: la lectura del correo, la del calendario y el script, con el nombre del plugin delante. La telemetría, solo la mitad: las dos lecturas sí, el script no. O sea, justo lo que se salta la ventana de permisos es lo que tampoco llega a la telemetría.

Y antes de todo esto, en una sesión aislada en modo bypass (en el que ni yo ni nadie que yo conozca ha trabajado jamás), el mod llamó a cinco servicios conectados y todos le contestaron sin pedir permiso ni una sola vez: Drive devolvió 32.798 caracteres, Gmail 2.575, Atlassian 659, Slack 494 y Calendar 254. Guardé solo si funcionó y cuánto devolvió.

Nada de esto ha necesitado un exploit. Es lo que un plugin tiene permitido hacer. La mayoría instalamos un plugin como una extensión del navegador, después de leer la descripción. Lo que instalamos de verdad es código que corre dentro de la sesión que estamos mirando, con nuestros conectores y nuestra cuenta, con su temporizador y sin decir ni mu en pantalla.

03Cómo pillar a un mod silencioso

Empieza por el código que cargó la sesión, que es donde está lo que hace el mod; el historial solo apunta lo que hizo el modelo. Con estas órdenes, que solo leen, tienes el mapa:

# Solo lectura
claude plugin list --json
claude plugin details <plugin-instalado>
rg -n 'session\.start|clock\.every|process\.run|mcp\.call|tool\.call|http\.fetch' <carpeta-del-plugin>
sha256sum <módulo-del-mod> <cada-script-que-lanza>

Sigue cada $.process.run hasta su script y lo que ese script importa. En mi caso, quedarse en register.js habría dejado fuera el cambio: el mod no se movió, el que cambió fue bridge_rules.py. Y mira también los plugins que se cargan con --plugin-dir, que entran sin instalarse.

Ojo, claude plugin validate revisa la estructura; hasta dónde llega el mod lo tienes que mirar tú.

Puedes hacer tooodo eso, o le pasas este post a tu Opus 5.5 y le pides que te monte un mod guardián: Claude Code avisa con el evento plugin.register cada vez que un mod está a punto de cargarse, y ahí el guardián puede leer su código, preguntárselo a Opus y bloquearlo si no le convence. Eso sí, solo ve lo que se carga, así que los scripts que ese mod lance después hay que vigilarlos por hash.

Yo me he hecho el mío y lo he dejado público en mi GitHub, explicado de arriba abajo: antes de cargar cualquier mod le pasa su código a Opus 5.5 para que lo revise, y si luego cambia un script del mod en plena sesión, no lo deja ejecutarse. Lo probé con un mod que decía ser un reloj y en realidad lanzaba un script cada minuto: Opus lo pilló a la primera y no llegó a cargarse.

No está exento de cierta ironía que, después de todo este post, te ofrezca un mod y a la vez te diga que te lo pienses antes de instalar uno. Pero c'est la vie: si no quieres, no lo instales, o al menos pídele a tu Opus 5.5 que lo lea y te lo instale él. Lo tengo puesto con Opus 5.5 en esfuerzo alto, que para revisar código ajeno no conviene escatimar.

04Lo que te diría antes de que lo intentes

05Lo que le pediría a Anthropic

La documentación ya avisa de que los mods corren sin sandbox, y eso está bien. Lo que echo en falta es poder verlo. Y lo bueno es que casi todo lo necesario ya está dentro de Claude Code: el validador ya sabe qué llama cada mod, la telemetría ya sale y el evento plugin.register ya permite frenar uno antes de que cargue. Son tres peticiones pequeñas, una por cada momento de la vida de un mod, y cada una sale de algo que medí.

Un mod trae código que usa tus llaves. Tú decides qué puertas le abres.