I sync my skills in both directions. What I write in Claude Code gets bundled and pasted into Claude Chat; whatever works well there comes back. That is written into my own instructions and I have done it for months without thinking about it.
Release 2.1.228 holds one line that makes that slightly different. And four lines below it sits another, moving the opposite way.
The two lines
Verbatim, from the changelog:
Hardened skills synced from claude.ai: they no longer shadow local commands or MCP prompts, their descriptions are sanitized and labeled, and on your machine their bodies don’t run
!commands or expand@files
And:
Changed the Write tool so newer models can overwrite an existing file they haven’t read this session, matching the Edit tool’s rules; older models still require the read first
Two sentences in a list of fifty. The first shuts a door, the second opens one.
What closed
A skill is a text file of instructions that Claude loads when it thinks it is relevant. Sync one from claude.ai to your machine and text from outside lands in the same place your own instructions live. Until this release that text could do four things it can no longer do.
Shadow a local command. If a synced skill shared a name with your own slash command, the synced one won. You type what you always type and something else runs. The same held for MCP prompts.
Sit unfiltered in the description. A skill’s description is the part Claude reads to decide whether to pick it up, which means it is always in the context window, even for a skill you never use. It is now sanitized and labeled, so it is visible that the text came from elsewhere.
Run shell commands. A ! line in a skill body executed on your machine. Not any more, for synced skills.
Pull in files. An @ reference dragged that file’s contents along. That is gone too.
Line those four up and you see what it was: a skill fetched from a shared environment could hijack your local commands, put unread text in your context, run shell and read files. That is an injection surface, and it is now smaller.
What opened
The second line touches a habit I lean on here daily. The Edit tool requires that a file has been read before it may be changed. That is not a formality: it forces the model to know what is there before it replaces anything.
The Write tool carried the same requirement for existing files. That requirement is now gone, but only for “newer models”. Older models still have to read first.
| Before 2.1.228 | From 2.1.228 | |
|---|---|---|
| Edit on an existing file | read first | read first |
| Write on an existing file, newer model | read first | allowed straight away |
| Write on an existing file, older model | read first | read first |
| Write on a new file | no requirement | no requirement |
Anthropic calls this “matching the Edit tool’s rules”, and there is friction in that phrasing: the Edit rule is precisely that you do have to read. What is being aligned here is not the requirement but the exception, and that is a different thing from what the summary suggests.
What is missing
Three things are absent, and they decide how much you can do with this news.
Which models count as “newer” is not stated. No list, no cutoff date, no way to look it up. The result is that the same project behaves differently depending on which model you are running that day, and you cannot check which. For a rule about overwriting, that vagueness stings.
There is not a single number. No count of affected skills, no measurement, nothing. That is normal for a changelog, but it also means nothing can be said about the scale of any of this. I could not find a second source.
The word “hardened” implies a risk that is never described. It does not say whether this was ever exploited, whether it came from a report, or whether someone thought of it internally before anything went wrong. That is the usual pattern for lines like this, and it is exactly the information you would need to judge how hard to clean your own house.
What I actually do
Two things change here, and both are small.
I am going to walk through my synced skills once. Not because I expect to find anything, but because until today I did not know that a skill from claude.ai could shadow a local command. That is precisely the kind of thing you do not notice: you type /nieuwsartikel, something runs, and it looks fine. I wrote my own bundle and know its contents, so the risk in my case is small. The lesson is in the shape, not in my situation.
I am not letting go of read-before-write. That guardrail was never there for the model, it was there for me: if a read has to happen first, then what was in the file appears on my screen before it gets overwritten. That is my only chance to notice something leaving that I wanted to keep. So I am writing into my own instructions that an existing file gets read first, regardless of what the model is allowed to do.
That sounds like a detour around a relaxation, and it is. But a guardrail that varies by model is not a guardrail to me, and I would rather straighten it myself.
The caveat
The default shifts from “the tool enforces it” to “the model is trusted”. The old rule was mechanical: no read, no overwrite, end of story. The new rule says it will be fine with newer models. That is probably true statistically, and it is fundamentally different from a bolt. A bolt does not depend on who leans against it.
Responsibility lands with whoever imports the skills. The fencing helps against skills you did not write yourself, which is exactly the scenario growing now that skills are shared and sold. But the cleanup is limited to what Claude Code can enforce on your machine. Whatever is written inside such a skill remains text the model reads and follows, and there is no filter for that.
What drains away is visibility of your own change. Two behavioural rules altered, both inside a list of dozens of bug fixes. Anyone who does not read the changelog, which is almost everyone, finds out when something goes wrong. With a relaxed write rule, that moment is a file that is gone.
Frequently asked questions
Do I need to do anything to my existing skills?
The fencing applies automatically from 2.1.228, so there is nothing to switch on. Worth doing anyway: check whether a synced skill carries the same name as a local command of yours. That silently resolved the wrong way until now, and the confusion will not leave your own folder structure on its own.
How do I know whether I am on a “newer” model?
You do not. The changelog gives no cutoff and neither does the documentation. If you want certainty about the behaviour, the only reliable route is enforcing it in your project instructions rather than trusting the tool to do it.
Is this a security hole that got patched?
It does not say so, and I would not call it that. “Hardened” describes a surface being reduced, not a hole being closed. Whether this was ever exploited has not been published.
Does the skill fencing also apply to skills I write locally?
No. The rule is explicitly about skills synced from claude.ai. Whatever you put in your own project keeps doing what it did, including ! commands and @ references.
Sources
- Claude Code CHANGELOG, release 2.1.228, accessed 13 August 2026 — github.com/anthropics/claude-code
Checked on 13 August 2026. Both lines appear verbatim in the 2.1.228 changelog, which I read myself; the quotes above are unabridged. What I could not verify is everything around them: there is no blog post, no documentation page and no second source explaining these two changes. Which models fall under “newer models” is published nowhere, so I cannot fill the table above with model names. Whether the skill fencing came from a reported problem or from internal work is not stated either. At the time of writing the changelog already sits at 2.1.231, so 2.1.228 is three releases old and nothing about these two lines has changed since.