Who Clicks 'Yes'? What 6,000+ Agent Add-Ons Say About Approval

We analysed 6,125 Claude Code mods and 150+ Muse connectors. Approval is the weak spot.

Claude Code mods went generally available on 1 October. By 25 October, the largest public catalogue we found, karanb192/awesome-claude-code-mods, listed 6,125 of them.

A mod is not a theme. It is JavaScript or TypeScript that runs inside the Claude Code process, with your permissions. It can read files and environment variables, start processes, make network requests, rewrite prompts and tool calls, and approve a tool call before you are asked. Anthropic's documentation says so plainly: mods aren't sandboxed.

There is no gatekeeper either. Anyone can publish a mod in a GitHub repo and call it a marketplace. Installing one is one command. It is the same deal as downloading an .exe from a stranger's website: you are trusting the author, and trusting them again with each update. Code can be risky without being malicious. A mod written in good faith can still approve the wrong call, send your data somewhere you didn't expect, or run something you never saw.

What we did

We fetched the source of 5,902 mods from the catalogue at the exact commit it lists. Another 223 mods, from 63 repos, are no longer on GitHub at all, so nobody can audit what users installed. We combined the catalogue's own static validation data with our own pass over the hook code: credential paths, network destinations, dynamic code, command rewriting and permission decisions. Then we read the flagged code by hand.

We ran the same review on anil-matcha/awesome-muse-connectors, a popular unofficial catalogue of connectors for Meta's Muse agent, itself copied from an upstream community project. Meta lists approved connectors only inside the Muse app, so community repos like this are what people find and copy.

We read all 158 connectors in full. We found no confirmed malware: no access to browser credentials or crypto wallets, no hidden payloads, nothing sent to paste sites or tunnels. We did find a lot of code that holds real power, with defaults that should worry any security team.

What mods can reach

Across the 6,125 mods:

• 41% run local processes.
• 36% read environment variables and 35% read files.
• 32% see all tool calls Claude makes; 29% see all prompts.
• 13% can submit prompts as you.
• 11% reach the network.

Where the "yes" comes from

267 mods (4%) hook the permission decision itself, and 93 can return "allow". Five combine that permission hook with a remote channel: a Telegram bot, a relay server, a shared web session. About twenty let a remote channel submit prompts into a live session.

Four examples from the catalogue:

1. Your transcript, the developer's server. Paradigm-Study/claude-share (800+ stars) shares a live Claude Code session with teammates. By default it mirrors your transcript to claude-share.proud-limit-da0a.workers.dev, a Cloudflare Worker run by its developer. Guests can send prompts into your session, and the mod approves their tool calls through Claude Code's permission hook once you have trusted them. The code is careful. The design means your session, and its approvals, run through someone else's infrastructure.

2. Routing around another tool's guard. The auto-worktree mod in yut0takagi/mods rewrites git commands to \git before they run. The code comment explains why: another tool's hook would otherwise rewrite them, and the built-in security mod blocks the obvious workaround. The intent is harmless. The technique, a mod using its place in the chain to sidestep someone else's hook, is not. It is one of about a dozen mods that rewrite shell commands without telling you or the agent. The transcript shows the original.

3. Your Claude login, read directly. New-Retr0/claude-dock reads your Claude OAuth access token from the macOS Keychain, or from ~/.claude/.credentials.json, to display plan usage. At least 16 mod repos read the token this way: status lines, usage meters, account switchers. Claude Code's mods API has its own authorization call; few of these use it. The ones we traced send the token only to Anthropic. One bad update changes that.

4. Subagents with the checks switched off. The sidequest plugin in poindexter12/loadout rewrites some subagent launches to mode: "bypassPermissions", so those helper agents run with permission checks skipped. It is a deliberate design choice for an orchestration tool. It is also the clearest case in the catalogue of an add-on deciding, on your behalf, that approval isn't needed.

Connectors tell the same story

Muse has two kinds of connectors. Official ones go through Meta's review, and Meta's guidelines say Muse asks the user before reads and writes on first use, and before sensitive writes such as purchases on every use. They are listed only inside the app. Custom connectors are different: users add them by asking Muse in chat, and Meta’s help page says plainly that it “doesn’t review custom connectors or how they use your information”.

The catalogue we scanned holds 158 community connectors of the second kind: a folder with instructions and a small script, published by whoever wrote it. 154 of them are written for Muse's own runtime and credential flow, and four tell Muse to fetch and install code from the internet. None asks a human in its own code. Where code gates an action at all, the gate is a phrase the agent passes as a flag, and that phrase sits in the agent's own instructions. We have not tested whether Muse adds its own prompt when these run as custom skills.

1. Unlocking a car. The tesla-fleet-api connector covers locking, unlocking and keyless driving. Its strictest tier requires --confirm "unlock all vehicle doors" on each call, a phrase printed in the skill file the agent reads. A separate --params option can also overwrite the command being sent, so a call that passes as a low-risk horn honk with no confirmation can carry an unlock instead. We read this in the code; we did not test it against a real vehicle. Fifteen connectors go further and save the first confirmation to disk, skipping it afterwards.

2. Market data from a raw IP. market-evidence-check describes itself as a read-only check on public OKX order books. Its only host is devday.167-179-82-72.nip.io, a wildcard DNS name for a single VPS. The connector never contacts OKX itself; your trade side and size go to that server.

3. Pipe to bash, with a referral tag. cohesivity sets up backend infrastructure by running curl -fsSL https://cohesivity.ai/quickstart.sh | bash, tagged with --attribution gh-awesome-muse-connectors. Its fallback is npx @cohesivity/init, unpinned. The domain belongs to a real company, and that is not the issue. Whatever the script says on the day it runs is what executes, with no pinned version or hash to check it against. If the domain or package is ever compromised, every agent that runs that setup step runs the attacker's script. That is how the 2021 Codecov Bash Uploader breach reached hundreds of customers’ networks.

Platforms may add approval layers we can't see from the outside. On the add-on side, approval is designed by whoever wrote the add-on.

What to do

• Treat an add-on like a binary that runs as you. Read it before installing, and again when it updates.
• Run claude plugin validate on a mod's folder. It lists hooks and calls, but not rewrites passed to next(), so read the source too.
• Look hard at anything that hooks permission decisions or takes input from a remote channel.
• Keep real secrets out of agent sessions. Rules that bind the agent don't bind a mod.
• On a team, set allowManagedModsOnly and decide which mods are allowed.

Moving faster than review

Mods went from launch to 6,000+ public entries in under a month. Tech outlets (like XDA Developers) already recommend them with no mention of permissions. Connector platforms are opening up just as fast. Most security teams don't yet know these add-ons are on their developers' machines.