What a mod can touch

#The categories

When a mod is published, Modyard reads its code and lists the areas it reaches. You see the list on the mod's page under mods, on the publish screen before you confirm, and in the API. There are nine categories:

You can also filter by them on the mods page and in the REST API, for example to hide everything that touches the network or runs processes:

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

#How they are derived

A mod's code talks to Claude Code through the engine interface, the $ its hooks receive, and through the events it registers with on. Each part of $ is a noun: $.fs, $.http, $.process, $.ui, $.model, $.tool, $.settings, $.mcp and others. Modyard reads the code statically, without running it, finds which nouns and events are used, and maps them to categories. For example, in this module:

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)
  })
}

the tool.call hook gives tool calls and $.ui gives display. Nothing else is used, so nothing else is listed.

Two more signals count:

• Classic command hooks, the kind that run a shell command declared in configuration, count as processes, because running a command is exactly that.
• A .mcp.json in the mod counts as mcp, because it declares servers for Claude Code to start.

#Where it stops

Static reading is fast and catches the honest majority, but it has limits you should keep in mind:

• It is not a guarantee. Code can reach a capability in ways a reader of the source does not see at a glance: computed property names, code assembled at run time, a dependency bundled into the zip that does its own thing.
• It says what, not how much. files covers reading one config file and rewriting your home directory alike. The category tells you where to look, not whether what you find is fine.
• It is not a review. Nobody at Modyard reads mods for intent. The list is computed, not approved.
• Mods run with your permissions. Whatever Claude Code can do on your machine, a mod running inside it can do too.

So read the list as a map: it points at the parts of the code worth reading first. An empty or short list is a good sign, not a promise.

#How to read a mod before installing

Every file of every version is browsable on the mod page, so you do not need to download anything to review it. A short routine:

1. Compare the list with the description. A status-line mod that touches display and tool calls is coherent. The same mod touching network needs an explanation.
2. Open hooks/hooks.json. It names the modules Claude Code loads:

{ "modules": ["./register.tsx"] }

3. Read each module's register. Look at every on(...) call: which event, which matcher, and what the handler does with e.
4. Check how each handler ends. A handler that calls next(e) lets the rest of the chain and Claude Code's own behavior run. One that calls next({ ...e, ... }) changes the input on the way through. One that returns without calling next answers by itself, for example blocking a tool call:

on('tool.call', { tool: 'Bash' }, async ($, e, next) => {
  if (e.command.includes('rm -rf')) return { deny: 'Blocked by quiet-band' }
  return next(e)
})

That is fine for a guard, but you want to know which calls a mod blocks or rewrites. 5. Follow the risky nouns. Search the code for $.process, $.http and $.fs, and for what is passed to them. Where does a request go? Which paths are written? Is any of your prompt or file content sent somewhere? 6. Look at what else is in the zip. Bundled scripts, minified files or a .mcp.json deserve a look of their own. 7. Check the publisher. The same review means more when you know whose marketplace updates will come from. Publisher marketplaces covers that side.

#When you are the publisher

The same list shows on publish before you confirm. Use it as a check on yourself: if a category appears that you did not expect, something in your code or in a bundled dependency reaches it. Keeping the list short and matching the description is the easiest way to earn installs, because it is the first thing people read.