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ía | Qué significa |
|---|---|
processes | Ejecuta programas en tu máquina |
network | Hace peticiones HTTP |
files | Lee o escribe ficheros |
tool calls | Ve, bloquea o reescribe las herramientas que llama Claude (Bash, Edit...) |
prompts | Ve o cambia lo que envías |
model | Llama al modelo o lo dirige |
settings | Lee o cambia la configuración de Claude Code |
mcp | Habla con servidores MCP o los declara |
display | Pinta 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:
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:
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.jsondentro del mod cuenta comomcp, 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.
filesvale 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:
- Compara la lista con la descripción. Un mod de línea de estado que toca
displayytool callses coherente. Si ese mismo mod tocaranetwork, querrías una explicación. - Abre
hooks/hooks.json. Ahí están los módulos que carga Claude Code:
{ "modules": ["./register.tsx"] }- Lee el
registerde cada módulo. Fíjate en cada llamada aon(...): qué evento, qué filtro y qué hace el manejador cone. - 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 anext({ ...e, ... }), cambia la entrada por el camino. Si vuelve sin llamar anext, responde por su cuenta; por ejemplo, bloqueando una llamada a una herramienta:
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.