Conceptos

Qué puede tocar un mod

En la ficha de cada mod aparece lo que puede tocar: procesos, red, ficheros y más. Te sirve para saber dónde mirar en el código. No es una revisión de seguridad, y aquí te contamos por qué.

4 min de lectura

Las categorías

Cuando se publica un mod, Modyard lee su código y enumera las áreas a las que llega. Esa lista la ves en la ficha del mod dentro de mods, en la pantalla de publicar antes de confirmar y en la API. Son nueve categorías:

CategoríaQué significa
processesEjecuta programas en tu máquina
networkHace peticiones HTTP
filesLee o escribe ficheros
tool callsVe, bloquea o reescribe las herramientas que llama Claude (Bash, Edit...)
promptsVe o cambia lo que envías
modelLlama al modelo o lo dirige
settingsLee o cambia la configuración de Claude Code
mcpHabla con servidores MCP o los declara
displayPinta en la interfaz: línea de estado, paneles, avisos

También puedes filtrar por ellas en la página de mods y en la API REST. Por ejemplo, para dejar fuera todo lo que toca la red o ejecuta procesos:

bash
curl "https://mods.gonzaloverdugo.com/api/v1/mods?q=logger&without=network,processes"

De dónde salen

El código de un mod habla con Claude Code a través de la interfaz del motor, el $ que reciben sus hooks, y de los eventos que registra con on. Cada parte de $ es un sustantivo: $.fs, $.http, $.process, $.ui, $.model, $.tool, $.settings, $.mcp y otros. Modyard lee el código de forma estática, sin ejecutarlo, localiza qué sustantivos y eventos usa y los traduce a categorías. En este módulo, por ejemplo:

tsx
import type { Register } from 'claude-code'

export const register: Register = (on) => {
  on('tool.call', { tool: 'Bash' }, async ($, e, next) => {
    $.ui.status(`Bash: ${e.command.slice(0, 40)}`)
    return next(e)
  })
}

el hook de tool.call da tool calls y $.ui da display. No usa nada más, así que no aparece nada más.

Hay dos señales más que cuentan:

  • Los hooks de comando clásicos, los que ejecutan un comando de shell declarado en la configuración, cuentan como processes, porque eso es justo lo que hacen.
  • Un .mcp.json dentro del mod cuenta como mcp, porque declara servidores que Claude Code arrancará.

Hasta dónde llega

Leer el código sin ejecutarlo es rápido y pilla a la mayoría honrada, pero tiene límites que conviene tener presentes:

  • No es una garantía. Un código puede llegar a algo por caminos que no se ven de un vistazo: nombres de propiedad calculados, código que se monta al ejecutarse, una dependencia metida en el zip que hace lo suyo.
  • Dice qué, no cuánto. files vale igual para leer un fichero de configuración que para reescribirte la carpeta personal. La categoría te dice dónde mirar, no si lo que encuentras está bien.
  • No es una revisión. En Modyard nadie lee los mods para juzgar sus intenciones. La lista se calcula, no se aprueba.
  • Los mods se ejecutan con tus permisos. Todo lo que Claude Code puede hacer en tu máquina, lo puede hacer también un mod que corre dentro.

Léela, por tanto, como un mapa: te señala las partes del código que conviene leer primero. Una lista vacía o corta es buena señal, no una promesa.

Cómo leer un mod antes de instalarlo

Todos los ficheros de todas las versiones se pueden leer en la ficha del mod, así que no tienes que descargar nada para revisarlo. Una rutina corta:

  1. Compara la lista con la descripción. Un mod de línea de estado que toca display y tool calls es coherente. Si ese mismo mod tocara network, querrías una explicación.
  2. Abre hooks/hooks.json. Ahí están los módulos que carga Claude Code:
json
{ "modules": ["./register.tsx"] }
  1. Lee el register de cada módulo. Fíjate en cada llamada a on(...): qué evento, qué filtro y qué hace el manejador con e.
  2. Mira cómo termina cada manejador. Si llama a next(e), deja pasar el resto de la cadena y el comportamiento propio de Claude Code. Si llama a next({ ...e, ... }), cambia la entrada por el camino. Si vuelve sin llamar a next, responde por su cuenta; por ejemplo, bloqueando una llamada a una herramienta:
tsx
on('tool.call', { tool: 'Bash' }, async ($, e, next) => {
  if (e.command.includes('rm -rf')) return { deny: 'Blocked by quiet-band' }
  return next(e)
})

Para un guardián tiene sentido, pero te conviene saber qué llamadas bloquea o reescribe un mod. 5. Sigue los sustantivos delicados. Busca en el código $.process, $.http y $.fs, y qué se les pasa. ¿A dónde va una petición? ¿Qué rutas se escriben? ¿Sale de tu máquina algo de tus prompts o de tus ficheros? 6. Mira qué más trae el zip. Scripts incluidos, ficheros minificados o un .mcp.json merecen su propia lectura. 7. Fíjate en el publicador. La misma revisión vale más cuando sabes de quién te llegarán las actualizaciones. En marketplaces por publicador tienes esa parte.

Si el publicador eres tú

La misma lista sale en publicar antes de confirmar. Úsala para revisarte: si aparece una categoría que no esperabas, algo de tu código o de una dependencia incluida llega hasta ahí. Una lista corta y coherente con la descripción es la forma más fácil de ganarte instalaciones, porque es lo primero que lee la gente.

Tu primer mod, instalado con dos comandos

Entra con Google y tienes un publicador con su propio marketplace. Sube un zip, lee lo que Modyard encontró dentro y comparte el comando de instalación.