• Verdict: Wait on third-party Mods; use self-written or Anthropic-sourced ones after reading their hooks.
• Anthropic's documentation states mods are not sandboxed, and a process a mod starts runs outside the Bash sandbox.
• A mod can read environment variables and settings files, including API keys, and can approve a tool call before the user is asked.
• You can inspect a mod's declared events and calls with `claude plugin validate` before installing it, and administrators can restrict which mods load.
• The permission prompt itself cannot be restyled by a mod, so it remains the one interface element a mod cannot alter.

Anthropic has added Mods to Claude Code: plugins written as JavaScript or TypeScript event handlers that run inside the tool, according to Anthropic's documentation and The Decoder's report. Our call is Wait for third-party mods and Use for ones you wrote or have read. The reason is stated in Anthropic's own docs: a mod is code that runs with your permissions and is not sandboxed. We read the documentation and did not run any mods ourselves.

What Mods actually do

Mods run inside Claude Code rather than beside it. Anthropic's documentation says a handler can observe an event, rewrite it, or answer it so the usual behavior does not run. Documented uses include drawing a pane beside the transcript, replacing a tool call's row or the spinner, holding a tool call to ask the user a question, and adding a slash command that runs without a Claude turn. Settings hooks, skills and MCP servers cannot draw in the interface.

The trust model is the story

Anthropic's documentation lists what a loaded mod can reach: files anywhere the user account can, programs it can start, network requests, environment variables and settings files including API keys, every prompt and tool call, and the user's model usage. It also states that mods are not sandboxed. With sandboxing on, only the Bash commands Claude runs are isolated, and a process started by a mod runs outside it.

A mod can approve before you are asked

The most consequential documented capability is approval. Anthropic says a mod that approves tool calls can approve one that an ask rule would prompt for, or one that a user's own PreToolUse hook blocked. The documentation points to a separate permissions page for when such a mod can approve a call that a deny rule refuses; we did not read that page, so we do not characterize the deny-rule case.

What protects you, and what is unverified

Anthropic documents three controls. Running `claude plugin validate` on a cloned plugin lists the events it handles and the calls it requests, without running it. Users can disable mods per plugin, per session with `--safe-mode`, or globally with `disableAllHooks`. Administrators can limit which mods load through managed settings. The permission prompt is the exception: a mod can restyle much of the interface but, per the documentation, not what that prompt shows. We have not tested whether the validate listing is complete for obfuscated code.

Who should use it and who should not

Individuals who write or fully read their own mods get a real capability that settings hooks lack, such as a confirmation pane before a risky shell command; Anthropic's sample `blast-radius` mod does this. Teams that let engineers install marketplace plugins should hold off until administrators enforce an allow-list. Anthropic describes the playground samples as shared as-is without support, so treat them as examples to read, not vetted dependencies.

The bottom line: Wait, Use, or Skip

Verdict: Wait on third-party Mods, Use ones you wrote or fully read, and Skip any you cannot inspect. The deciding fact is Anthropic's own statement that mods are not sandboxed and can approve tool calls before you are asked, so a careless or malicious plugin sits inside your trust boundary. Before installing one, run `claude plugin validate`, read the hooks and calls lines, and confirm your organization's managed settings restrict who can load mods.