Ik synchroniseer mijn skills in twee richtingen. Wat ik in Claude Code schrijf, bundel ik en plak ik in Claude Chat; wat daar goed werkt komt terug. Dat staat zo in mijn eigen instructies en ik doe het al maanden zonder erover na te denken.
In release 2.1.228 staat één regel die dat opeens iets anders maakt. En vier regels lager staat er nog een, die precies de andere kant op beweegt.
De twee regels
Letterlijk, uit de 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
En:
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
Twee zinnen in een lijst van vijftig. De eerste doet een deur dicht, de tweede zet er een open.
Wat er dicht ging
Een skill is een tekstbestand met instructies dat Claude laadt als het denkt dat het relevant is. Synchroniseer je die vanaf claude.ai naar je machine, dan komt er dus tekst van buiten binnen op de plek waar jouw instructies staan. Tot deze release kon die tekst vier dingen die hij nu niet meer kan.
Een lokaal commando overschaduwen. Heette een gesynchroniseerde skill hetzelfde als jouw eigen slash-command, dan won die van jou. Je typt wat je altijd typt en er draait iets anders. Datzelfde gold voor MCP-prompts.
Ongefilterd in de beschrijving staan. De description van een skill is het stukje dat Claude leest om te bepalen of hij hem oppakt. Die staat dus altijd in het contextvenster, ook als je de skill nooit gebruikt. Nu wordt hij gesanitiseerd en gelabeld, zodat zichtbaar is dat de tekst van buiten komt.
Shell-commando’s uitvoeren. Een !-regel in de body van een skill draaide op jouw machine. Nu niet meer, voor gesynchroniseerde skills.
Bestanden binnenhalen. Een @-verwijzing haalde de inhoud van dat bestand erbij. Ook dat is eruit.
Zet die vier op een rij en je ziet wat het was: een skill die je van een gedeelde omgeving ophaalt kon je lokale commando’s kapen, ongelezen tekst in je context zetten, shell draaien en bestanden lezen. Dat is een injectie-oppervlak, en het is nu kleiner.
Wat er open ging
De tweede regel gaat over een gewoonte waar ik hier dagelijks op leun. De Edit-tool eist dat een bestand eerst gelezen is voordat het gewijzigd mag worden. Dat is geen formaliteit: het dwingt af dat het model weet wat er staat voordat het iets vervangt.
De Write-tool had diezelfde eis voor bestaande bestanden. Die eis is nu weg, maar alleen voor “nieuwere modellen”. Oudere modellen moeten nog steeds eerst lezen.
| Voor 2.1.228 | Vanaf 2.1.228 | |
|---|---|---|
| Edit op bestaand bestand | eerst lezen | eerst lezen |
| Write op bestaand bestand, nieuwer model | eerst lezen | mag direct |
| Write op bestaand bestand, ouder model | eerst lezen | eerst lezen |
| Write op nieuw bestand | geen eis | geen eis |
Anthropic noemt dit “matching the Edit tool’s rules”, en daar zit een wringende kant aan: de Edit-regel is juist dat je wél moet lezen. Wat hier gelijkgetrokken wordt is niet de eis maar de uitzondering, en dat is iets anders dan de samenvatting suggereert.
Wat er niet bij staat
Drie dingen ontbreken, en die bepalen hoeveel je met dit nieuws kunt.
Welke modellen “nieuwer” zijn, staat er niet. Geen lijst, geen datumgrens, geen manier om het op te zoeken. Het gevolg is dat hetzelfde project zich anders gedraagt afhankelijk van welk model je die dag draait, en dat je dat niet kunt nakijken. Voor een regel die over overschrijven gaat is dat een vervelende vaagheid.
Er staat geen enkel cijfer. Geen aantal betrokken skills, geen meting, niets. Dat is normaal voor een changelog, maar het betekent ook dat er over de omvang van dit alles niets te zeggen valt. Ik heb er geen tweede bron bij kunnen vinden.
Het woord “hardened” impliceert een risico dat niet wordt beschreven. Er staat niet of dit ooit misbruikt is, of het uit een melding kwam, of dat iemand het intern bedacht voordat het misging. Dat is het gebruikelijke patroon bij dit soort regels, en het is precies de informatie waarmee je zou kunnen inschatten hoe hard je zelf moet opruimen.
Wat ik zelf doe
Twee dingen veranderen hier, en ze zijn allebei klein.
Ik ga mijn gesynchroniseerde skills een keer doorlopen. Niet omdat ik verwacht iets te vinden, maar omdat ik tot vandaag niet wist dat een skill van claude.ai een lokaal commando kon overschaduwen. Dat is precies het soort ding dat je niet merkt: je typt /nieuwsartikel, er draait iets, en het ziet er goed uit. Ik heb mijn eigen bundel geschreven en ken de inhoud, dus het risico bij mij is klein. De les zit in de vorm, niet in mijn geval.
De read-before-write-regel laat ik niet los. Die vangrail was er niet voor het model maar voor mij: als er eerst gelezen moet worden, staat er in mijn scherm wat er stond voordat het werd overschreven. Dat is mijn enige kans om te zien dat er iets weggaat wat ik wilde houden. Ik ga dus in mijn eigen instructies opschrijven dat een bestaand bestand eerst gelezen wordt, ongeacht wat het model mag.
Dat klinkt als een omweg om een versoepeling heen, en dat is het ook. Maar een vangrail die per model verschilt is voor mij geen vangrail meer, en dan trek ik hem liever zelf recht.
De kanttekening
De standaard verschuift van “de tool bewaakt het” naar “het model wordt vertrouwd”. De oude regel was mechanisch: geen lezing, geen overschrijving, punt. De nieuwe regel zegt dat het bij nieuwere modellen wel goed komt. Dat zal statistisch kloppen, en het is iets fundamenteel anders dan een grendel. Een grendel is niet afhankelijk van wie ertegenaan duwt.
De verantwoordelijkheid landt bij wie de skills binnenhaalt. De inperking helpt tegen skills die je zelf niet schreef, en dat is precies het scenario dat groeit nu skills gedeeld en verkocht worden. Maar de sanering is beperkt tot wat Claude Code kan afdwingen op jouw machine. Wat er in de tekst van zo’n skill staat blijft tekst die het model leest en volgt, en daar bestaat geen filter voor.
Wat er wegstroomt is de zichtbaarheid van je eigen verandering. Twee gedragsregels die veranderen, allebei in een lijst met tientallen bugfixes. Wie de changelog niet leest, en dat is bijna iedereen, merkt dit pas als er iets misgaat. Bij een versoepeling van een schrijfregel is dat moment een bestand dat weg is.
Veelgestelde vragen
Moet ik nu iets doen aan mijn bestaande skills?
De inperking geldt automatisch vanaf 2.1.228, dus je hoeft niets aan te zetten. Wel de moeite: kijk of een gesynchroniseerde skill dezelfde naam draagt als een lokaal commando van jou. Dat werkte tot nu toe stilzwijgend de verkeerde kant op, en die verwarring verdwijnt niet vanzelf uit je eigen mapstructuur.
Hoe weet ik of ik op een “nieuwer” model zit?
Dat weet je niet. De changelog noemt geen grens en de documentatie ook niet. Wil je zekerheid over het gedrag, dan is de enige betrouwbare route het zelf afdwingen in je projectinstructies in plaats van erop vertrouwen dat de tool het doet.
Is dit een beveiligingslek dat is gedicht?
Dat staat er niet, en ik zou het zo niet noemen. “Hardened” beschrijft dat een oppervlak is verkleind, niet dat er een lek was. Of dit ooit is misbruikt, is niet gepubliceerd.
Geldt de skill-inperking ook voor skills die ik zelf lokaal schrijf?
Nee. De regel gaat expliciet over skills die vanaf claude.ai zijn gesynchroniseerd. Wat jij zelf in je project zet, blijft doen wat het deed, inclusief !-commando’s en @-verwijzingen.
Bronnen
- Claude Code CHANGELOG, release 2.1.228, geraadpleegd 13 augustus 2026 — github.com/anthropics/claude-code
Gecontroleerd op 13 augustus 2026. Beide regels staan letterlijk in de changelog van 2.1.228 en die heb ik zelf gelezen; de citaten hierboven zijn onverkort overgenomen. Wat ik niet heb kunnen verifiëren is alles eromheen: er is geen blogpost, geen documentatiepagina en geen tweede bron die deze twee wijzigingen toelicht. Welke modellen onder “newer models” vallen is nergens gepubliceerd, dus de tabel hierboven kan ik niet met modelnamen invullen. Of de skill-inperking voortkomt uit een gemeld probleem of uit eigen onderzoek staat er evenmin bij. Ten tijde van schrijven staat de changelog al op 2.1.231, dus 2.1.228 is drie releases oud en er is in die tijd niets aan deze twee regels gewijzigd.