CLAUDE.md plugin overwrite risk: the Edit tool is already on your file, by default

When people say CLAUDE.md plugin overwrite risk, they usually mean one of two things, and both are real. The first is a sanctioned, first-party plugin that already has the Edit tool on the file. The second is the marketplace mechanism that lets a teammate (or a compromised teammate's repo) hand that Edit tool to a different plugin you also installed. Neither requires a malicious actor. Both happen on default installs.

1. Anthropic ships a first-party plugin with Edit on your CLAUDE.md

The plugin is called claude-md-management, the manifest in .claude-plugin/plugin.json lists Anthropic as the author and version 1.0.0, and Anthropic's plugin listing page shows it past 200,000 installs. It ships one skill, claude-md-improver, and one command, /revise-claude-md. The frontmatter is the part that matters:

Two lines do the work. The description field lists the auto-trigger phrases: check, audit, update, improve, fix, CLAUDE.md maintenance, project memory optimization. Saying any of them turns the skill on. The tools field grants it Read, Glob, Grep, Bash, Edit. The first four read the file. The fifth writes to it. The body of SKILL.md confirms the intent in one line: this skill can write to CLAUDE.md files.

The bundled command behaves the same way:

The Phase 5 instruction in the skill body reads "After user approval, apply changes using the Edit tool. Preserve existing content structure." That is the entire guardrail. The whole design rests on the assumption that the user is going to see an Edit confirmation prompt and answer it. The next section is about why that assumption breaks for almost everyone who would install this plugin in the first place.

2. The approval guardrail is one toggle away from disappearing

The reason you installed this plugin is that you live in Claude Code six hours a day. The reason you live in Claude Code six hours a day is that you have already turned off most of the friction. So the audience for this plugin is the same audience that has configured Claude not to ask before writing. Here is what each of those configs does to the per-Edit prompt:

The two rows that bite hardest are acceptEdits and the pre-approved Edit(**) wildcard. Most heavy users have one or both. Boris Cherny's own public Threads post on permissions explicitly recommends adding patterns like Edit(/docs/**) to your team's checked-in settings.json to pre-approve common tools. Once that pattern matches your CLAUDE.md path, the plugin's "ask first" promise is load-bearing on a guardrail that does not fire.

3. Shared marketplaces let a teammate ship Edit-on-CLAUDE.md after the fact

The first failure mode is one specific plugin. The second is a mechanism that applies to every plugin you ever install through a shared marketplace. Three pieces stack into it:

• extraKnownMarketplaces in a repo's checked-in .claude/settings.json auto-registers a team marketplace when you trust the folder. Trust is one-time.
• enabledPlugins with true for each plugin auto-installs them on next session start.
• Plugin sources pinned to ref:main with no explicit version in plugin.json resolve the version from the git SHA. Per the official marketplaces docs: every new commit is treated as a new version. This is the simplest setup for internal or actively-developed plugins.

Put together: a teammate pushes a commit to the plugin repo that adds Edit to a previously read-only skill's tools field, ships it to main, and you pick it up on your next session start. No re-trust prompt. Settings.json never changed. Your CLAUDE.md is now in the blast radius of a plugin you already approved months ago. PromptArmor wrote up the worst-case malicious version of this at promptarmor.com; the non-malicious version (a well-meaning teammate refactor) is the one you will actually see.

What an unsafe and a safe settings.json look like

The unsafe shape is the one most teams land on by default, because it removes friction in the order the friction shows up.

Three problems on one page. Wildcard Edit(**) covers your CLAUDE.md. Marketplace pinned to ref:main accepts every new commit as a new version. Plugin enabled by default. Anyone with push access to your-org/claude-plugins can ship a plugin update that picks up Edit on your CLAUDE.md and you will not see a prompt.

The safe shape inverts each piece:

Deny rules win over allow rules and win over permission modes, which makes Edit(CLAUDE.md) in the deny list the one thing that holds even when acceptEdits is on. The marketplace pinned to a tag instead of main means a new teammate commit does not auto-flow into your machine. You explicitly bump the ref when you want the update, after reading the diff.

If it already happened, here is how to undo it

The git case is easy. The .claude.local.md case is the one that has no safety net, because it is gitignored by convention.

The recovery step that nobody writes down: snapshot .claude.local.md to a directory outside the repo every time you change it. The plugin treats it as a first-class target alongside CLAUDE.md (the discovery step explicitly searches for all three patterns), and a bad edit to a gitignored file is permanent.

Related on ccmd

The structural analysis of the official setup plugin lives at claude-code-setup token cost, which measures the same plugin family from the cost-per-turn angle. If you are also reading subagent state in here, subagent CLAUDE.md inheritance covers why every subagent re-reads the file you just protected.