Claude Code Is Getting Mods. Here Is What That Actually Changes.

Anthropic spent the last two weeks running a design argument in public about how people should be allowed to modify Claude Code. On September 9 they committed to shipping it, "on the scale of weeks in lieu of days or months," and gave it a name: Claude Mods.¹1Issue 91870 in the anthropics/claude-code repo. The same update published the source for three built-in mods and acknowledged the opt-in flag publicly for the first time.

It already runs. One environment variable, and it's live on the version I'm typing this in.

I spent the afternoon rebuilding two of my own safety rules on top of it. The rebuild answered a question I'd been carrying for a while, which is what a plugin system for an AI coding agent is actually for.

What a mod is, without the jargon

Claude Code already takes a lot of actions on your behalf. It runs shell commands, reads and writes files, calls APIs, spawns sub-agents, decides what to put in front of the model.

A mod sits in the middle of any of those. Your code gets handed the action before it happens and gets to decide: let it through, change it, refuse it, or answer it yourself. Then it passes control to whatever is next in line.

That's the whole idea. Web developers have had this shape for fifteen years, and Anthropic's own write-up points straight at it: this works the way Express does.²2Express is the standard way to build a web server in JavaScript. Its core idea is a chain of small functions, each of which sees a request, does something, and calls the next one. The Claude Code proposal uses the same pattern and the same word for passing control along: next. Each piece is small, they stack, and any one of them can stop the chain.

The reach is what surprised me. There are roughly 85 of these interception points, covering permissions, shell execution, file access, what goes into the model's context, how sub-agents get delegated to, what a session carries across a compaction, cost, and drawing in the terminal.³3Counted off the type declarations Anthropic ships in the repo, on version 2.1.271, on September 14. It's an early-access API and the count can move.

Beyond Tetris

The first thing anyone built with the drawing part was an arcade. Eight playable games in the strip above the prompt, running while Claude works, costing zero tokens.⁴4github.com/sezaakgun/cc-arcade. The author's notes on what they hit building it are more useful than the games: the band is about half the terminal height and redraws roughly ten times a second.

Which is funny, and I'd have done the same thing. It's also the only proof that mattered. A plugin can now draw a live interactive surface inside the terminal, and it works.

So what would you actually put there? On a long agent session, the things I currently find out too late:

What this session has cost so far. I read that afterwards today. A number in the corner while there's still time to stop is a different tool entirely.

Is the background work still alive? A long job on a remote machine either finishes or silently stops, and the difference is invisible until somebody goes looking.

Whether the agent is working from a stale plan. My sessions hand off through a cursor file. When the files in the working directory are newer than the cursor, the agent is acting on an out-of-date picture, and nothing today says so.

None of that is a game. All of it is a gauge, and a gauge is how you catch a problem while it's still cheap.

Agent harnesses got here first

Here's the part I didn't expect to find in my own setup.

I run a second agent system alongside Claude Code, built on the pi coding agent. It has had this architecture for months: fifteen TypeScript extensions hooking the engine's events, including one that enforces the same dangerous-command rules Claude Code enforces with Python scripts. A bridge keeps the two in sync.

So Claude Code isn't inventing a shape. It's adopting one that agent harnesses converged on independently, because anyone running an autonomous agent past a certain point needs the same four things. Intercept what it does. Shape what it reads. Then put a cap on the spending and a window on the behaviour, because neither is visible by default.

Which made the next bit worth doing. I had one rule implemented twice, in two systems, kept in sync by a generator. So I ran both against the same set of shell commands. Nine of them, and the split:

Command	prime-agent	the rebuilt version
kill -9 -1234	blocked	refused
kill -9 -2345	allowed	refused
kill -- -2345	allowed	refused
ssh host "kill -9 -2345"	allowed	refused
sudo kill -9 -$PGID	blocked	refused
kill -9 1234	allowed	allowed
pkill -f filler	allowed	allowed
echo "kill -9 -1234"	blocked	allowed
grep -R "rm -rf" ~/config	blocked	allowed

Three misses and two false alarms, in one rule, at the same time.

The cause is worth understanding even if you never touch a shell. The generator syncs the list of dangerous patterns and not the logic for recognising them. On the pi side that logic is nothing more than "does this command contain any of these strings," and one of the strings is kill -9 -1. Which catches kill -9 -1234 purely by accident, because it happens to be a prefix of it. Change one digit and it sails through. Meanwhile any command that merely mentions a dangerous string gets blocked, so searching my own config files for the text rm -rf stops the agent dead. And that system runs unattended, so a block is a hard stop with nobody there to approve it.

Two systems, one rule, no way to see the drift until both sides spoke the same language. That's the argument for mods that has nothing to do with Claude Code specifically. Shared safety logic can now be one shared module. A module brings its tests along with it; a synced list of strings brings nothing at all, and you find that out on the day it matters.

What I rebuilt, and what it bought

My two hardest rules are both shell guards. One refuses a command that would kill an entire group of processes at once, which sounds narrow until it takes down a shared machine, which is how I came to own the rule. The other asks for confirmation when a command has the shape of an injected instruction trying to run remote code or send a credential somewhere.

Both were Python scripts, and both already had controls. I wrote those in August, the second time one of these guards blocked something it shouldn't have, and they run in both directions over real traffic. So the rebuild didn't rescue anything. It's a fair test of what the new shape adds when the old one was already in decent health.

It adds four things, and the first three are about friction.

The tests live with the code and run in one command. Nine of them, both directions, in about a quarter of a second. The Python controls are standalone scripts sitting beside the guards, which means somebody has to remember them. These run through the agent's own test runner against a simulated engine, so they run when anything else runs. Same coverage, no memory required.

The guard stops being a process. Every one of my Python hooks launches a separate program on every single tool call, reads a blob of JSON on standard input and answers with an exit code. As a mod it's a function that receives a typed object. That's a smaller thing than it sounds until you count 19 registered hooks and multiply.

The false-alarm rate is still measured on real traffic, and it should be. I replayed 4,000 actual shell commands from my own session logs through both guards. Zero wrongful blocks. Five confirmation prompts, and every one of the five is asking about something it should be asking about. I also broke each guard deliberately to watch the suite go red, 5 of 9 for one and 3 of 9 for the other, because a test suite nobody has watched fail isn't a control, it's a decoration. None of that discipline is new. What's new is that it costs nothing to keep.

The fourth thing is the one I didn't plan.

Five things this changes in a real setup

This is where it stops being a language feature. My harness is 19 registered Python hook scripts, 22 rules files, a spending tracker, a delegation policy and a session-continuity system. Four of those five have a weakness that mods close.

One. Safety rules consolidate. Nineteen scripts, each spawning a process on every single tool call, about half of them carrying controls, collapse into one typed module with a suite that runs in under a second. And because the old-style hooks are themselves exposed as an interception point, you move one rule at a time instead of rewriting everything in a weekend.

Two. Context becomes conditional, and this is the big one. Every rule and instruction file I've written loads into every session, on every machine, whether or not it's relevant. Today there's exactly one way to make that conditional: match on file type. Two of my 22 files can use it. The rest load in full, always, which is why they're written as short stubs pointing at longer reference documents nobody reads at the right moment.

With a mod, what goes into the model's context is a decision your code makes. Deployment rules arrive when the session touches deployment. Writing rules arrive when the turn is producing prose. The expensive reference document shows up at the moment somebody needs it, instead of a lossy summary of it sitting there at all times. Every organisation running agents at scale is paying for the whole instruction set on every request, and mostly solving it by deleting instructions.

Three. Spend becomes visible while you can still act on it. The cost data exists today. It's a report you read afterwards. A live number in the terminal is the difference between a post-mortem and a decision.

Four. Delegation limits get enforced instead of documented. I cap how many parallel calls go to two model providers, because past a certain number they start rejecting requests. Those caps live in a rules file, and a reminder script fires after the wrong thing has already been set up. Wrapped around the delegation step itself, a cap becomes the thing that holds. That difference, between a documented limit and an enforced one, is most of what separates a demo harness from one you'd leave running unattended.

Five. Session handoffs stop laundering stale assumptions. When a long session runs out of room it compacts itself and carries a summary forward. If the plan file it carries is out of date, the next session inherits a wrong picture with full confidence, and so does the one after that. A mod can check the file's timestamp against the work and refuse to carry it. That's a failure I've watched propagate through three sessions in a row, and it's a few lines of code away from being caught.

Where this actually stands

Built, tested, committed, and turned off.

The API is early access and can change between releases without notice, which is a real reason not to move anything load-carrying yet. Turning it on where I work means a flag that replicates to four machines in about ten seconds. That makes it an estate decision.

And I haven't answered the obvious operational question. During a changeover, do both sets of rules run at once? Two refusals are no worse than one refusal. Two confirmation prompts on the same command is one extra click, on exactly the path where clicking through by reflex is the failure the guard exists to prevent. I'd rather have a plan for that before flipping a switch across an estate, and it's the same question any team hits the week this ships.

Related reading

Related reading on this site: Making Claude Code More AgenticshippedAI Development & Agents·Jan 9, 2026Making Claude Code More Agentic: Parallel Execution, Model Routing, and Custom AgentsHow to configure Claude Code to use more subagents, run operations in parallel, and behave more like the multi-agent systems we've come to expect from tools like OpenCode. for the hook-and-skill layer these mods are set to replace, Claude Code Best PracticesshippedAI Development & Agents·Apr 20, 2025Claude Code Best Practices: Setup, Commands, and the Defaults Worth ChangingThe Claude Code setup, skills, subagents, and hooks I run in production, plus the defaults worth changing first. Updated for the 2026 feature set. for the baseline setup a mod sits on top of, Building Claude Code Skills: The Dossier PatternshippedAI Development & Agents·May 18, 2026Building Claude Code Skills by Conversation: The Dossier PatternHow a 30-minute brainstorm with Claude turned a recurring annoyance (cool company names dropped in your lap, marketing sites that say nothing) into a production Claude Code skill that decodes AI companies, surfaces 3+1 alternatives, and writes prep questions sharp enough to expose the gap in 90 seconds. The meta-point is the conversational pattern that produced it. for how far you can get before reaching for code at all, Inventory Your Harness for the audit that tells you which of your own rules are load-carrying enough to move first, and Pruning Your AI Agent Skills LibraryshippedAI Development & Agents·Jan 10, 2026Pruning Your AI Agent Skills Library: A Practical Guide to Skill ConsolidationLearn how to audit, consolidate, and optimize your AI agent's skills library using practical patterns that reduce overlap and improve reliability. for the other half of that job, which is deciding what not to carry across at all.