A CLAUDE CODE MOD CAN READ YOUR API KEYS AND APPROVE COMMANDS BEFORE YOU SEE THEM. HERE'S HOW TO CHECK ONE IN 30 SECONDS. not a theory. it's written on Anthropic's own mods page. once a mod loads, it can: → read and write files anywhere your user account can → read your environment variables and settings files, API keys included → see every prompt you send and every tool call Claude makes → rewrite a prompt or a tool call → approve a tool call before you're asked → spend your usage by calling a model mods aren't sandboxed either. sandboxing isolates the Bash commands Claude runs. a process a mod starts runs outside it. the one thing a mod can't touch is the permission prompt. it can't change what that prompt shows you. so here's the 30-second check before installing anything from a stranger: 01. get the files without running them git clone the repo. don't install yet. 02. run the validator claude plugin validate ./the-mod it reads the code without running it and tells you exactly what the mod does. 03. read the "hooks:" line the events it listens to. a theme should be drawing things. if a theme also hooks every tool call, ask why. 04. read the "calls:" line everything it asks Claude Code to do. a skin calling http.fetch is a red flag. a cost tracker writing files outside its own folder is a red flag. anything calling a model is spending your usage. 05. look for "env reads:" if the mod reads environment variables, the validator prints that line. a timer has no reason to read your keys. 06. know your brakes before you need them → one mod: /plugin, Installed tab, disable it → every mod you installed, one session: claude --safe-mode → every mod you installed, every session: "disableAllHooks": true in ~/.claude/settings.json (this also stops your settings hooks and custom status line) one more trap if you write your own guard mod: a hook that throws gets skipped, and the command it was meant to stop runs anyway. give every guard a .catch and test that it actually blocks. good news for the mods Claude writes for you: they only load after you approve hot reload, only in a workspace you've trusted, and never in claude -p where nobody can say yes. mods are the best thing to happen to Claude Code in a long time. just treat them like browser extensions that run as you, because that's what they are. the full safety section, the install order and every command are in the article below.
A CLAUDE CODE MOD CAN READ YOUR API KEYS AND APPROVE COMMANDS BEFORE YOU SEE THE
A CLAUDE CODE MOD CAN READ YOUR API KEYS AND APPROVE COMMANDS BEFORE YOU SEE THEM. HERE'S HOW TO CHECK ONE IN 30 SECONDS.
About this mod
A CLAUDE CODE MOD CAN READ YOUR API KEYS AND APPROVE COMMANDS BEFORE YOU SEE THEM. HERE'S HOW TO CHECK ONE IN 30 SECONDS.
not a theory. it's written on Anthropic's own mods page.
once a mod loads, it can:
→ read and write files anywhere your user account can → read your environment variables and settings files, API keys included → see every prompt you send and every tool call Claude makes → rewrite a prompt or a tool call → approve a tool call before you're asked → spend your usage by calling a model
mods aren't sandboxed either. sandboxing isolates the Bash commands Claude runs. a process a mod starts runs outside it.
the one thing a mod can't touch is the permission prompt. it can't change what that prompt shows you.
so here's the 30-second check before installing anything from a stranger:
- get the files without running them
git clone the repo. don't install yet.
- run the validator
claude plugin validate ./the-mod
it reads the code without running it and tells you exactly what the mod does.
- read the "hooks:" line
the events it listens to. a theme should be drawing things. if a theme also hooks every tool call, ask why.
- read the "calls:" line
everything it asks Claude Code to do. a skin calling http.fetch is a red flag. a cost tracker writing files outside its own folder is a red flag. anything calling a model is spending your usage.
- look for "env reads:"
if the mod reads environment variables, the validator prints that line. a timer has no reason to read your keys.
- know your brakes before you need them
→ one mod: /plugin, Installed tab, disable it → every mod you installed, one session: claude --safe-mode → every mod you installed, every session: "disableAllHooks": true in ~/.claude/settings.json (this also stops your settings hooks and custom status line)
one more trap if you write your own guard mod: a hook that throws gets skipped, and the command it was meant to stop runs anyway. give every guard a .catch and test that it actually blocks.
good news for the mods Claude writes for you: they only load after you approve hot reload, only in a workspace you've trusted, and never in claude -p where nobody can say yes.
mods are the best thing to happen to Claude Code in a long time. just treat them like browser extensions that run as you, because that's what they are.
the full safety section, the install order and every command are in the article below.
Installation
See the original source for installation instructions.
Original text / README
A CLAUDE CODE MOD CAN READ YOUR API KEYS AND APPROVE COMMANDS BEFORE YOU SEE THEM. HERE'S HOW TO CHECK ONE IN 30 SECONDS.
not a theory. it's written on Anthropic's own mods page.
once a mod loads, it can:
→ read and write files anywhere your user account can → read your environment variables and settings files, API keys included → see every prompt you send and every tool call Claude makes → rewrite a prompt or a tool call → approve a tool call before you're asked → spend your usage by calling a model
mods aren't sandboxed either. sandboxing isolates the Bash commands Claude runs. a process a mod starts runs outside it.
the one thing a mod can't touch is the permission prompt. it can't change what that prompt shows you.
so here's the 30-second check before installing anything from a stranger:
- get the files without running them
git clone the repo. don't install yet.
- run the validator
claude plugin validate ./the-mod
it reads the code without running it and tells you exactly what the mod does.
- read the "hooks:" line
the events it listens to. a theme should be drawing things. if a theme also hooks every tool call, ask why.
- read the "calls:" line
everything it asks Claude Code to do. a skin calling http.fetch is a red flag. a cost tracker writing files outside its own folder is a red flag. anything calling a model is spending your usage.
- look for "env reads:"
if the mod reads environment variables, the validator prints that line. a timer has no reason to read your keys.
- know your brakes before you need them
→ one mod: /plugin, Installed tab, disable it → every mod you installed, one session: claude --safe-mode → every mod you installed, every session: "disableAllHooks": true in ~/.claude/settings.json (this also stops your settings hooks and custom status line)
one more trap if you write your own guard mod: a hook that throws gets skipped, and the command it was meant to stop runs anyway. give every guard a .catch and test that it actually blocks.
good news for the mods Claude writes for you: they only load after you approve hot reload, only in a workspace you've trusted, and never in claude -p where nobody can say yes.
mods are the best thing to happen to Claude Code in a long time. just treat them like browser extensions that run as you, because that's what they are.
the full safety section, the install order and every command are in the article below.
