Sign in Subscribe
news

2026-10-04 Claude Code Mods - Claude Code is now programmable, and mods aren't sandboxed

Sebastien Dubois

Sebastien Dubois

— 3 min read

Canonical version: 2026-10-04 Claude Code Mods - Claude Code is now programmable, and mods aren't sandboxed.

"You can now mod Claude Code." @ClaudeDevs posted that on 1 October. Claude Code Mods are out of early access, and they're on by default since v2.1.287.

Until now, you could change what Claude Code knows (skills, CLAUDE.md) and what it's allowed to do (permissions, hooks). Mods let you change how it works and how it looks. They also run without a sandbox.

What changed

A mod is a plugin with JavaScript or TypeScript handlers that run inside Claude Code's own process. Each handler receives an event (a tool call, a prompt, a piece of UI being drawn) and can observe it, rewrite it, or answer it without passing it on. Think Express middleware that can also draw panes, bands and buttons in your terminal. A settings hook runs a shell script at a lifecycle event; a mod is a typed function in the middle of the event flow.

You don't need to learn the API. Ask Claude for the mod you want: a built-in skill teaches it how, and it writes, installs and hot reloads the mod in the same session.

Anthropic is moving its own features onto mods. /diff is a mod now, and so is AGENTS.md loading. Morgan Lunt says more built-ins will follow, until Claude Code is a small core and you choose (or replace) everything around it.

Sharing a mod means sharing a plugin: a GitHub repo with a marketplace file, and three commands to install it.

Boris Cherny: "there's no reason why everyone should have an identical Claude experience". I agree. Claude Code should fit the way YOU work.

Mods aren't sandboxed

A mod is code written by its publisher, running on your machine with Claude Code's access. It's NOT sandboxed; the sandbox only isolates the Bash commands Claude runs. A mod can read your secrets, rewrite your prompts, and approve tool calls before you're asked. In auto mode, a call approved by a mod skips the classifier.

Deny rules win over user mods, but a mod's own $.fs and $.process calls bypass them. Deny Read(.env) in your permissions, and a mod can still read it.

Mods from different authors also stack. Say you run a prompt rewrite, a tool intercept and a UI mod from three people, and Claude writes a couple more mid-session. The order they run in changes the result, and today there's no easy way to see which ones ran, in which order, or what each one changed. Commenters under the launch posts raised the same problem. I think provenance and debugging tools are what's missing.

What I'd do

  • Run claude plugin validate ./some-mod before you install anything. It lists what the mod hooks and calls, without running it. Then read the code, like you'd vet an npm package
  • Only install mods from people you'd trust with your terminal. Treat any mod you didn't write like a browser extension with shell access
  • Better yet, write your own first. Ask Claude for it, and you'll know exactly what's running
  • Admins: set allowManagedModsOnly, and add disableSideloadFlags if you also want to block mods Claude writes mid-session. Team and Enterprise machines get the built-in sec-default guard on top; it loads first and can't be disabled
  • The README still says the API can change between releases without notice. Fine for personal mods. For anything your team depends on, plan time for fixes

The full breakdown (API, built-in mods, where they run, admin policies, community mods) is in my Claude Code Mods note.

That's it for today! ✨

References

About Sébastien

Ready to get to the next level?

Found this valuable? Share it with someone who needs it.

Join 6,000+ readers. Get practical systems for knowledge & AI. Free.

Subscribe ✨

Free: Knowledge System Checklist

A clear roadmap to building your own knowledge system. Subscribe and get it straight to your inbox.

6,000+ readers. No spam. Unsubscribe anytime.

Subscribe