Understand what a Claude Code mod is
In videos that circulated about Claude Code mods, two safeguards appeared: a collision (two agents in the same file) and one of "blast radius" (the size of the damage a command that deletes can cause).
The idea is great. The kit makes its own version, using only official resources: the hooks from Claude Code. The split is simple: the rule stays in the script, the screen stays in the mod.
🆕 New here? Four words from this module
- Hook (hook) — a command that Claude Code runs automatically at a set time.
PreToolUseruns before a tool (edit, run Bash);PostToolUseruns then. - Plugin — an official package that adds hooks, commands, or screens to Claude Code. It has a
.claude-plugin/plugin.jsonwith a name and version. - Mod — the nickname the videos gave the plugins. In the kit, the mods are in
runtime/mods/. - Worktree — a second working copy of the same Git repository in a separate folder. Two agents, two copies, no one stepping on the other's work.
How to read the diagram: the amber box is the control point. Every edit and command passes through it before taking effect. If there is no risk, it follows the blue arrow. If there is a risk, the guard neither blocks nor allows it: it sends the question back to you (N2).
.claude/settings.json from the kit (the guard is already enabled)"PreToolUse": [
{
"matcher": "Edit|Write|MultiEdit|NotebookEdit",
"hooks": [ { "type": "command",
"command": "node \"$CLAUDE_PROJECT_DIR/runtime/mods/runtime-guarda/hooks/colisao.mjs\" pre",
"timeout": 10 } ]
},
{
"matcher": "Bash",
"hooks": [ { "type": "command",
"command": "node \"$CLAUDE_PROJECT_DIR/runtime/mods/runtime-guarda/hooks/raio.mjs\"",
"timeout": 15 } ]
}
]
…
"PostToolUse": [ … colisao.mjs pos … ]
matcher says which tool triggers the hook. Editing triggers the collision; Bash triggers the lightning bolt.runs before or after
the official "mod"
colisao.mjs · raio.mjs
the panel
See the collision guard in action
The pain is real. It happened in one of our projects: one session emptied a file that another was editing. Neither one was wrong on its own. Each thought the file belonged only to them.
The collision resolves this with memory. After each edit, it notes, “this session just changed this file.” Before the next edit, it checks the note and the file’s date.
How to read the diagram: the blue arrow is session A's normal edit, which is recorded. The red arrow is session B arriving within the 30-minute window. You answer the question in the amber box.
After editing: log it
colisao.mjs pos records the file path, the session ID, and the time at toques.json. The write is atomic: two sessions won’t corrupt the record.
Before editing: check
colisao.mjs pre checks whether another session changed the file, or whether the file's date changed externally, in the last 30 minutes.
If there's a risk: ask
The text assembled by the script is: Guarda de colisão: Outra sessão (<id>) editou <arquivo> há <N> min. Seguir mesmo assim, usar outra cópia (worktree) ou cancelar?
✓ Ask when
- ✓ Another Claude session edited the file less than 30 min ago
- ✓ The file changed externally: Codex, editor, or someone else
✗ Stays quiet when
- ✗ The file is new (there’s nothing to protect)
- ✗ It was the same session that last edited it
- ✗ The last change was made more than 30 min ago
Proven in CHANGELOG 0.3.0: with 5 cases (old file, changed externally, same session, another session, nonexistent), the collision only prompts in cases involving another session and external changes. In Claude, an Edit to a file from another session was blocked, and the file remained intact.
⚠️ Codex limitation
Codex still doesn't have an equivalent "before editing" hook. The guard protects Claude sessions and detects Codex edits by the file's date. It doesn't prevent Codex from editing. If Codex and Claude will work in the same folder, give each one a worktree.
💡 Adjust the window
If your team works slowly, increase the window: INEMA_COLISAO_MIN=60 make the guard consider the last hour instead of 30 minutes.
Prove the scope before deleting
O ray comes before a rm or git clean. It counts how many existing files would be deleted, adds up their size, and lists the first paths. Then it asks: "Do you have a backup? Confirm to continue."
The lightning bolt doesn’t delete anything: it only reads the disk. And if the command wouldn’t delete any existing files, it stays quiet. You can test the script on its own, without opening Claude, by sending it the same request Claude would send.
rm -rIn the terminal. Replace /caminho/do/kit from the folder where you cloned the kit:
mkdir -p /tmp/teste-raio/x && echo a > /tmp/teste-raio/x/a && cd /tmp/teste-raio
printf '{"cwd":"%s","tool_name":"Bash","tool_input":{"command":"rm -r x"}}' "$PWD" \
| node /caminho/do/kit/runtime/mods/runtime-guarda/hooks/raio.mjs
Result confirmed in CHANGELOG 0.3.0 / expected by instructions R7:
a saída traz "permissionDecision":"ask" e o texto Raio: este comando apaga 1 arquivo(s)
x is still there. The command above only asked the ray; it didn’t delete anything.🆕 New here? What the printf … | do it
O printf builds text in the format Claude Code sends to the hook: the folder (cwd), the tool (Bash) and the command (rm -r x). The bar | put this text inside the raio.mjs. It's a rehearsal: the hook responds as it would to Claude.
| Tested case (CHANGELOG 0.3.0) | The lightning bolt… |
|---|---|
rm -r, rm -f *.txt, git clean -fd | lists exactly which files would be deleted and asks |
rm for a nonexistent file, ls | nothing to delete: doesn’t ask |
Claude in the mode that unlocks everything, asking rm -r pasta | blocked by "Raio"; folder intact |
💡 Two layers, not one
O .claude/settings.json already denies it rm -rf at a time (module 4.1). The lightning bolt covers the rest: rm -r, rm with a wildcard, git clean. A denial is a wall; the lightning bolt is a door that opens only with your approval.
size of the damage
files and size
never deletes
the final question
Take the safeguard to another project
The guard is already enabled in the kit folder. But Sônia has another folder, the one for monthly closings, where agents also run. She wants the same protection there.
Recipe R7 offers two ways. Choose one, not both.
Way 1 · This session only
Opens Claude with the guard loaded as a plugin. When the session ends, so does the guard.
Good for testing or a short-lived project.
Way 2 · Fixed for the project
Copy the block hooks of the .claude/settings.json from the kit for the .claude/settings.json from the other project, changing the path.
Good for the folder you use every day.
In the terminal, from inside the other project's folder (replace /caminho/do/kit):
claude --plugin-dir /caminho/do/kit/runtime/mods/runtime-guarda
Result confirmed in CHANGELOG 0.3.0:
com --plugin-dir runtime-guarda e o modo que libera tudo, rm -r pasta foi barrado pelo "Raio" e a pasta ficou intacta; Edit em arquivo editado por outra sessão foi barrado pela "colisão".
rm -r. It has to stop and show the Raio question. Answer "no".💡 Why the path changes
In the kit, settings uses $CLAUDE_PROJECT_DIR/runtime/mods/…, that is, "this project’s folder." In the other project, there is no runtime/. That's why, with method 2, the path has to point to where the kit actually is.
only in this session
fixed in the project
never both
points to the kit
Open the team panel
In module 3.3, you launched sessions with claude --bg and tracked it through observar.mjs, in another terminal. The panel brings this list into Claude Code. It’s optional.
It shows each background session with its name, status, and minutes, a button Update and a button Stop in the ones that are running. Only your click applies to a session.
In the terminal, from inside the kit folder. Then, in the session, type /painel:
claude --plugin-dir runtime/mods/runtime-painel
To check the mod before using it:
claude plugin validate runtime/mods/runtime-painel claude plugin test runtime/mods/runtime-painel
Result confirmed in CHANGELOG 0.3.0:
validate: passa test: 1 pass
/painel opens a panel with the sessions for claude --bg of this folder and the Update and Stop buttons.How to read the diagram: is an illustration, not a screenshot. The line r4-revisor · done · 7 it’s the same session as the observar.mjs showed in module 3.3. The red button only appears for sessions that are still running.
| observar.mjs | /painel | |
|---|---|---|
| Where it runs | another terminal | inside the Claude session |
| End session | you type claude stop <id> | Stop button |
| Needs to be installed | no, it comes with the kit | load the mod with --plugin-dir |
What to look for in the table: both read the same session list. Choose whichever feels more comfortable, not based on functionality.
the new command
read it again
only with your click
mod test
Read the code before installing a mod
Mods and plugins run with the same Claude Code permissions. A hook can read your files, run commands, and access the network without asking. That's why it protects so well, and why a malicious mod can do so much damage.
The rule in Recipe R7: read the code of any third-party mod before installing it. You don't need to program for this. Ask the agent to read and explain it without running anything.
Open claude in the kit folder and paste (for a third-party mod, replace the paths):
Read runtime/mods/runtime-guarda/.claude-plugin/plugin.json, runtime/mods/runtime-guarda/hooks/hooks.json, colisao.mjs, and raio.mjs. Explain in plain language: when each hook runs, what it reads, what it writes, and whether it accesses the network. Do not install or run anything.
toques.json; neither one accesses the network.✓ Signs of a healthy mod
- ✓
plugin.jsonwith the code's author, license, and address - ✓
hooks.jsonshort: you can see each hook - ✓ Writes only to a known location
- ✓ Ask instead of deciding on your own
✗ Warning signs
- ✗ Obfuscated code that no one can read
- ✗ Reads credentials, tokens, or another tool’s configuration folder
- ✗ Sends data to an internet address
- ✗ Approves permissions on its own
Quick test (optional): the guard finds a risk in an edit. What does it do?
those from Claude Code
every third-party mod
without running anything
the key question
🎓 Module summary
Next module:
4.4 — Lab and final project