Claude Code 2.1.295: hooks kunnen nu 'fail-closed'

In het kort

• Wat: Claude Code 2.1.295 geeft hooks een nieuwe instelling, onFailure: "block". Een hook die deze instelling heeft, blokkeert de actie die hij bewaakt zodra de hook zelf niet start, een time-out krijgt of met een onverwachte exitcode stopt.
• Waarom relevant: Tot nu toe lieten veel hooks de actie gewoon doorgaan als de check zelf stukliep. Een beveiligings- of beleidscheck die faalt, gaf dan een vals gevoel van veiligheid. onFailure: "block" draait dat om: faalt de check, dan stopt de actie.
• Wat je ermee kunt: Wie Claude Code gebruikt om met code of gevoelige data te werken, kan een controle nu echt afdwingen in plaats van hopen dat hij werkt. Dat verlaagt het risico dat een kapotte check ongemerkt wordt overgeslagen.

Wat is een hook ook alweer?

Claude Code is de versie van Claude die rechtstreeks in de ontwikkelomgeving van je team werkt: hij leest, schrijft en wijzigt code en kan opdrachten uitvoeren. Een hook is een klein eigen scriptje dat automatisch meedraait op bepaalde momenten. Bijvoorbeeld: vlak voordat Claude een bestand opslaat, of zodra iemand een opdracht intypt.

Teams gebruiken hooks als een soort poortwachter. Denk aan een check die controleert of er geen wachtwoord of geheime sleutel per ongeluk in de code belandt, of een regel die zegt: productiedata mag niet worden aangeraakt. De hook kijkt mee en kan de actie tegenhouden.

Het probleem zat in wat er gebeurde als de poortwachter zelf uitviel. Volgens de analyse van Classmethod gold voor veel hook-gebeurtenissen dat alleen exitcode 2 de actie blokkeerde. Een hook die bijvoorbeeld met code 1 en zonder uitvoer stopte, werd behandeld als een niet-blokkerende fout: de actie ging gewoon door. Een bewakingscheck die crasht, hield dus niets tegen.

Wat verandert er in 2.1.295?

Met onFailure: "block" kun je per hook aangeven: als jij faalt, blokkeer dan de actie. De instelling werkt voor zogeheten command- en HTTP-hooks. Hij grijpt in bij drie situaties:

• de hook kan niet opstarten;
• de hook loopt in een time-out;
• de hook stopt met een onverwachte exitcode.

In vaktermen heet dit fail-closed: als er twijfel is, gaat de deur dicht in plaats van open. Dat is precies wat je wilt bij een beveiligings- of beleidscheck.

Classmethod testte dit met een hook die bij het intypen van een opdracht bewust faalde (exit 1). Zónder de nieuwe instelling reageerde Claude gewoon met "OK" en ging verder. Mét onFailure: "block" werd de opdracht tegengehouden, met een melding dat de actie was geblokkeerd. Een duidelijk verschil.

Eén technisch aandachtspunt: bij het aansturen via de opdrachtregel bleef de exitcode in beide gevallen 0, ook als er geblokkeerd werd. Wie dit automatiseert, moet dus naar de uitvoer kijken, niet naar de exitcode, om te zien of er iets is tegengehouden.

De release was onderdeel van een groot pakket wijzigingen — 2.1.295 bevatte er volgens dezelfde bron 143, waaronder een reeks beveiligingsfixes. Deze hook-verandering springt eruit omdat hij direct raakt aan hoe veilig je je geautomatiseerde werk inricht. Het past in een bredere lijn van kleine, gerichte verbeteringen; zie bijvoorbeeld de effort-parameter voor de Agent-tool uit een eerdere versie.

Wat betekent dit concreet voor het Nederlandse MKB?

Veel MKB-bedrijven laten Claude Code inmiddels meedraaien bij softwarewerk, of overwegen dat. Juist dan is dit relevant, ook als je zelf niet programmeert maar wel eindverantwoordelijk bent.

Stel: je laat een hook controleren dat er geen klantgegevens of inloggegevens per ongeluk in een openbare map belanden. Vóór deze update kon zo'n controle stilletjes falen — door een foutje in het script, een ontbrekend onderdeel of een trage reactie — en ging het werk gewoon door. Je dacht dat je beschermd was, maar dat was je niet. Met onFailure: "block" stopt de actie juist als de controle niet netjes draait.

Voor een ondernemer betekent dat vooral één ding: je afspraken over veiligheid en compliance worden beter afdwingbaar. Dat scheelt risico, en het maakt uitlegbaar aan een accountant, auditor of klant dat een controle niet zomaar overgeslagen kan worden.

Wel een nuchtere kanttekening. Classmethod waarschuwt dat een fout in je eigen script of een ontbrekende afhankelijkheid nu óók de boel kan blokkeren. Zet deze instelling dus op checks die stabiel en betrouwbaar draaien, niet op iets wat zelf wankel is. Anders ruil je een vals gevoel van veiligheid in voor onverwachte blokkades midden in het werk. En let op: op het moment van schrijven stond onFailure nog niet in de officiële documentatie, dus controleer de exacte schrijfwijze in de actuele docs voordat je erop bouwt.

Hoe pak je dit verstandig aan?

De truc zit niet in het aanzetten van één knop, maar in het bepalen welke controles je wilt afdwingen en hoe betrouwbaar ze zijn. Dat is bij uitstek werk waar ervaring helpt: welke poortwachters horen fail-closed, en welke laat je juist soepel?

Heb je geen technisch team in huis, dan hoeft dat geen drempel te zijn. Je kunt deze keuzes laten begeleiden door iemand die Claude Code dagelijks inzet. Wil je sparren over een veilige inrichting, vind een Claude-specialist via onze community.

Ten slotte: deze update draait om controle en risico, en dat raakt ook aan het bredere gebruiksbeleid van Claude. Wie zich daarin wil verdiepen, leest ook onze uitleg over de bijgewerkte Usage Policy.

Benieuwd wat Claude Code veilig voor jouw bedrijf kan betekenen? Plan een gratis kennismaking via [email protected] — we denken graag vrijblijvend met je mee.

Santa Claude is een onafhankelijke Nederlandse community van Claude-specialisten en niet gelieerd aan Anthropic.