On October 1, Anthropic announced Claude Code Mods. TypeScript functions that modify Claude Code itself. Rewrite prompts, block or retry tool calls, add commands or panels.

The harness post talked about "after using AI well." Mods are that next step shipping as product. Coding-agent competition moves from Model plus Prompt to Model plus Harness plus Plugins plus UI plus Permission Layer.

What mods are: agent middleware

The shape is simple. Every time Claude Code does something, it emits an event. Tool calls, permission asks, screen draws. A mod is a function hooked into one of those events.

Event fires (tool call, permission ask, screen draw)
  → mod runs: before / after / instead / wrapped around
  → result applied

One function can do all of this.

- rewrite prompts before they reach the model
- block, rewrite, or retry tool calls
- approve or deny permission asks
- redact secrets from tool output before Claude reads it
- change the screen: swap tool rows and question dialogs, add buttons and inputs
- register own commands and tools, share state across sessions, call models

The difference from shell hooks matters. A shell hook is a separate process reading JSON and answering with an exit code. A mod runs in-process on typed events and can draw. Ordering is fixed, so stacked mods from different authors compose. The first loaded sees the event first and the result last.

Shipping is settled too. Mods live inside plugins. Install and share with /plugin or the directory. You can even ask Claude Code to "make a mod" and it writes the TypeScript, installs it, and hot reloads. Built-in /diff is a mod now, so you can switch it off. More built-ins move to mods over time toward a small core.

The fine print: mods are not a sandbox

Anthropic's own sentence, carried over directly: mods run with the same machine access as Claude Code itself. They are not sandboxed. Files, processes, and network are reachable. Install only from sources you trust for exactly this reason.

The mods permission model:
- Claude Code = your permissions
- Mods = Claude Code's permissions
→ 1 mod = 1 program running on your machine

Team and enterprise controls exist. A built-in mod called sec-default loads first and stops user-installed mods from risky moves like overriding deny rules. Official team examples: CI/CD status panes, production-command confirmations, audit logging. Admins control marketplaces and load their own mods first.

And v2.1.289 on October 3 fixed permission-rule bypasses through nested shell commands and symlinks. Same direction as step-up re-auth in the MCP permissions post. Features that widen permission borders ship with bypass-closing fixes behind them.

First mod stays small: logging or an approval gate

Take the brief's action as is. Two candidates, not grand automation.

Candidate A: tool-call logging mod
- record every tool call name, args, and result to a file
- a hand-built Activity Trail for your own runs
- effect: auditable agents

Candidate B: production-command approval gate
- confirmation before anything touches production config
- straight from the official example, paired with deny rules
- effect: a safety line for overnight agents

An ecosystem already lists 75 mods. Budget-guard (refuse calls past cost caps), harness-mods (workflow graphs), autotel (OpenTelemetry traces). Install before you build. Build only what is missing.

CodeBridge Mini Lab: install 1 logging mod and watch

1. Install 1 mod (/plugin or the directory):
   - pick: tool-call logging family
2. Run 1 long job (one with tests)
3. Read the log:
   [ ] Does the tool-call order match expectations
   [ ] Any wasteful repeated calls
   [ ] Where did permission asks come from
4. Pick the next mod:
   - repeats visible → approval gate on those calls
   - secrets visible → output redaction
   - cost visible → budget-guard style caps

The verification loop from the harness post and the execution bundling from the observability post become tangible in 1 mod. Measure first, automate second.

Conclusion: moddable tools win

One line to close.

Same models get split by harnesses. Same harnesses get split by moddability.

Mods turn Claude Code from "a tool you use" into "a tool you reshape." One condition: no sandbox. Install only what you trust, keep deny rules with sec-default, start the first mod at logging. Moddability and permission borders ship as a pair.

Further reading

References

Go deeper with a course

To practice reshaping harnesses and stacking verification gates, this course builds CLAUDE.md, skills, hooks, subagents, and MCP in real projects, exactly like the first mod here.