Claude Code mods: early favourites and a few words of caution

Anthropic gave Claude Code mods at the start of October, and I've been doing what everyone does with a new plugin system: installing far too many of them, then quietly uninstalling most.

It's early days, and the API is still moving. But not quite two weeks in, a few things are clear: which mods have earned a place in my setup (and what they have in common, which wasn't what I expected), what's stopping me using another, and what anyone running an engineering team should think about before their developers start installing them. This is what I know so far.

What a mod actually is

A mod is a small piece of JavaScript or TypeScript that runs inside Claude Code itself. Every time Claude Code does something (calls a tool, takes your prompt, draws part of the screen) it fires an event. A mod can watch that event, change it, or take it over entirely.

Claude Code already had hooks, which run a script when something happens. The difference is that hooks work from the outside. Mods work from the inside, so they can do things hooks can't: draw a pane beside the conversation, restyle parts of the interface, add buttons, or hold a tool call while they ask you a question.

Anthropic seems serious about this. Some of Claude Code's own features, such as /diff, are now built as mods, and the plan is to move more over time. You can also ask Claude Code to write a mod for you, which is a slightly dizzying thought.

The three I've kept

mission-control shows subagents, their tool calls and the files they touch, live, in a pane next to the chat. Files go blue while Claude reads them, orange while it writes, and green when it's done. When Claude farms work out to several subagents at once, this is the difference between trusting it and knowing what it did.

scratchpad gives me somewhere to jot notes beside the conversation, so half-formed thoughts and things to check later don't end up cluttering the prompt. It's tiny, and I use it constantly.

human-in-the-loop fixes a small but real annoyance. Claude often needs something only you can do: a key in your .env file, a decision, a command on your own machine. Normally it says so mid-reply, and while you're busy steering the next thing, the ask scrolls away. This mod turns those asks into tasks that wait in a pane until you've dealt with them, while Claude carries on with everything else. It's also thoughtful about secrets: it asks you to put a key where it belongs and press Done, rather than pasting it into the chat.

Looking at that list, all three are about keeping up with Claude: seeing what it's doing, and catching the things only I can do. I'd assumed the fun would be in bolting on new capabilities. In practice the bottleneck is me, and the better these agents get, the more that seems to matter.

The one I can't use yet

claude-image-view shows thumbnails of the screenshots you paste, instead of a bare [Image #1] tag. If you paste a lot of screenshots (and I do), that's lovely.

It works perfectly in the kitty terminal. The trouble is that I live in VS Code's integrated terminal, and there it shows a tile with the tag in it, or a grid of blue placeholder characters if you force the issue. VS Code does support some of the graphics protocol kitty uses, but apparently not the part Claude Code relies on to position images. I've written up what I found in case it saves someone else an afternoon.

It's a useful reminder that mods are only as portable as the terminal underneath them. Something that looks brilliant in a demo may need a particular setup to work at all.

Mods aren't sandboxed

This is the part I'd want every developer to read before they install anything. A mod runs with your permissions, inside Claude Code. According to Anthropic's own documentation, once it loads it can:

• read and write any file your account can, start programs and make network requests
• read your environment variables and settings files, including any API keys kept there
• see every prompt you send and every tool call Claude makes
• rewrite prompts and tool calls, or approve a tool call before you're asked
• call a model on your plan or API key

Even if you've turned on Claude Code's sandboxing, that only covers the commands Claude runs. A process a mod starts runs outside it. On a personal machine without managed settings, a mod can even approve calls your permission rules would normally stop.

None of this is unusual for a plugin system. A VS Code extension has much the same reach. But these mods are barely two weeks old, mostly written by individuals, and the catalogues are filling up fast. A few habits help:

• Look before you load. Run claude plugin validate on a mod's folder before installing it. It lists the events the mod hooks into and what it asks Claude Code to do, such as writing files or making network requests, without running anything. A scratchpad that wants network access deserves a closer look.
• Read the code (or at least have Claude read it). Most of these mods are a few hundred lines. Asking Claude Code to review one for anything that sends data elsewhere takes a minute.
• Check again when it updates. A mod you vetted last week isn't necessarily the mod you're running today.
• Know the off switch. claude --safe-mode starts a session with installed mods turned off, which is handy when something behaves oddly.

If you run a team

Mods are on by default. If your organisation hasn't touched its Claude Code settings, your developers can install a mod from any marketplace, load one from a folder, or ask Claude to write one mid-session. That isn't necessarily a problem, but it should be a decision rather than an accident.

The good news is that Anthropic has thought about this, and the admin documentation is unusually clear. The short version:

• There's a built-in guard. On Team and Enterprise plans, and on any machine with managed settings, a mod called sec-default loads ahead of everything else. It stops users' mods from tampering with the things you manage centrally, and from approving tool calls your deny rules refuse. Its source is public. It's worth knowing what it doesn't do, though: it doesn't stop a mod reading or writing files, starting programs or making network requests with the user's own access.
• You can turn users' mods off. A single managed setting, allowManagedModsOnly, stops any mod a user brings from loading, while leaving their other customisations alone.
• Existing plugin controls apply. Mods ship inside plugins, so if you already restrict which marketplaces people can install from, that covers mods too.
• You can run your own. An organisation can deploy its own mods to every machine and run them first. Anthropic's examples include a mod that refuses any other mod wanting to start processes, and one that keeps an audit log of every tool call. Rules about touching production config, or showing your CI status beside the conversation, are both fair game.

For a small team, I'd start with conversation rather than controls. The admin settings are there if you need them, but small organisations aren't just smaller versions of big ones, and a handful of developers can usually sort this out over a coffee. Ask everyone to spend a little time reading about mods (this post included, naturally), then get together and share what's caught their eye and the due diligence they've done on it. You'll come away with a shared sense of what's worth installing, and a team that knows how to check a mod for itself, which will outlast any approved list.

It's still worth a line in your AI policy. "Which plugins can run on a developer's machine with full access" is exactly the kind of question it should already answer.

What we don't know yet

Two weeks isn't long, and a few things are still unclear.

• How stable the API is. Mod authors are already noting that things can change between releases. A mod that works today may need fixing next month, which is another reason to keep your list short.
• How the catalogue settles. There are already collections of fifty-odd mods, some useful, some for playing Snake while Claude works. Anthropic has a directory for vetted plugins, but most of the interesting mods currently live in individual GitHub repos.
• How far Anthropic takes it. The stated plan is to move more of Claude Code's built-in features into mods, so you can pare it back to a small core and add only what you want. If that happens, choosing mods stops being a hobby and becomes part of how a team configures its tools.
• Where the interface goes. Right now the visual side of mods only appears in the terminal and the Desktop app. Plenty of developers work in the VS Code extension, where mods run but can't draw. I'd expect that to change, but I don't know when.

Where I've landed (for now)

Mods are the most interesting thing to happen to Claude Code in a while, mostly because they let you shape the tool around how you work. For me, so far, that's been less about giving Claude more to do and more about helping me keep up with what it's already doing. My advice is the same as for any new tool: start small, keep what earns its place, and know exactly what you've installed.

If you've found a mod you'd recommend, or you're working out what your team's policy should be, I'd love to hear about it.