# Claude Code 2.1.268: wat is opgelost in deny-regels en MCP > Claude Code 2.1.268–2.1.269 lost vier permissieproblemen en een lek van geheimen in /mcp op. Wie wordt getroffen, hoe je bijwerkt en hoe je je regels controleert. Source: https://ailoot.ai/blog/nl/claude-code-2-1-268-fixes/ Canonical: https://ailoot.ai/blog/nl/claude-code-2-1-268-fixes/ Language: nl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-040 Revision: sha256-837070a916bf1c7563b828addc3ad1b556dee4562902b858501307bd1d43d77e Claude Code-versie 2.1.268 werd uitgebracht op 10 september 2026, gevolgd door 2.1.269 de volgende dag. Je moet meteen bijwerken: in twee gevallen waren deny-regels die je gebruikt om te voorkomen dat de agent toegang krijgt tot `.env` en servicefolders stilzwijgend ineffectief. Daarnaast kon de opdracht `/mcp` geheimen uit je configuraties in de terminal afdrukken. Alles hieronder is gebaseerd op de officiële changelog en documentatie van Anthropic zoals die waren op 17 september 2026, de datum van het bronmateriaal. De nieuwste versie op die datum was 2.1.274. We beschrijven op basis van die vermeldingen hoe de fouten werkten; de omzeilingen zijn niet opnieuw uitgevoerd op de kwetsbare versie. Zie de [documentatie](https://ailoot.ai/docs/) voor aanvullende instructies over werken met Ailoot. ## Wat is er opgelost in Claude Code 2.1.268 en 2.1.269?
Belangrijkste conclusie Vier permissieproblemen zijn opgelost. De deny- en ask-regels werkten niet voor paden via symlinks, en deny voor Read of Edit kon mislukken op regels met `env -C` of `eval`. Een regel met “!” gold ook buiten het instellingenbestand. De opdracht `tee` schreef bestanden zonder dat dit door deny voor Edit werd geblokkeerd. Daarnaast toonden `/mcp` en `claude mcp list` geheimen uit configuraties, terwijl pluginfouten tokens uit Git-URL’s toonden.
Vier oplossingen zijn relevant voor permissieregels: 1. **Weigeringen voor symlinks werkten niet.** Deny- en ask-regels voor mappen die via een symlink bereikbaar zijn (`/etc`, `/tmp`, `/var` op macOS, `/bin` op Linux) werden niet geactiveerd wanneer een pad met de echte locatie werd opgegeven. Bash-opdrachten negeerden ook deny-regels voor een pad via een symlink. 2. **Weigeren van lezen en bewerken mislukte in combinatie met `env -C` of `eval`.** Als dezelfde opdrachtregel een constructie bevatte die de permissiecontrole niet kon parseren, kon deny voor Read of Edit niet worden geactiveerd. 3. **Een regel met “!” gold ruimer dan bedoeld.** Een deny- of ask-regel die met `!` begon, gold ook buiten het instellingenbestand waarin die was geschreven. Nu geldt de regel alleen binnen de eigen bron, en een losse negatie `!` wordt genegeerd. 4. **`tee` schreef langs de weigeringen heen.** Deny-regels voor `Edit()` en de controle van het schrijfpad werden niet toegepast op een bestand dat met de Bash-opdracht `tee` was aangemaakt. De permissie `Bash(tee:*)` geldt niet langer voor schrijven buiten werkmappen. Deze versies hebben ook twee problemen met het blootleggen van geheimen opgelost. WebFetch wacht niet langer onbeperkt op een antwoord van een server die de verbinding openhoudt: het verzoek mislukt nu na 300 seconden, en de time-out kan worden ingesteld met de variabele `CLAUDE_CODE_WEBFETCH_DEADLINE_MS`. Ook is het aanhoudende hoge CPU-gebruik tijdens lange inactieve sessies verholpen. ## Hoe werken weigeringen in Claude Code?
Belangrijkste conclusie Regels staan in het blok `permissions` van `settings.json`: deny blokkeert, ask vraagt om bevestiging en allow staat een actie zonder bevestiging toe. Controles worden in deze volgorde uitgevoerd: deny, dan ask, dan allow. Een regel heeft de vorm `Tool` of `Tool(detail)`, bijvoorbeeld `Read(./.env)`.
Claude Code heeft drie lijsten met regels: **deny** (altijd verboden), **ask** (eerst om bevestiging vragen) en **allow** (toegestaan zonder bevestiging). Wanneer de agent iets gaat doen, worden de regels strikt in die volgorde gecontroleerd. Een overeenkomende deny-regel annuleert een allow-regel voor dezelfde actie: een regel die iets toestaat kan geen uitzondering op een weigering maken. Regels worden op drie plaatsen opgeslagen: gebruikersregels in `~/.claude/settings.json`, projectregels in `.claude/settings.json` in de repository en lokale regels in `.claude/settings.local.json`. Hier is een voorbeeld van instellingen die het lezen van een bestand met sleutels weigeren: ```json { "permissions": { "deny": [ "Read(./.env)", "Read(./secrets/**)", "Bash(rm *)" ] } } ``` Je kunt alle actieve regels en het bestand waar elke regel vandaan komt bekijken door in een sessie `/permissions` uit te voeren. Als een regel het lezen blokkeert, vermeldt de weigering die regel; dat is handig voor de controle hieronder. ## Welke fouten hadden invloed op weigeringen en het bereik van regels? De fouten hadden invloed op pad- en opdrachtcontroles, en op het bereik van regels uit verschillende instellingenbestanden. **Eerste geval: symlinks.** Op macOS zijn `/etc`, `/tmp` en `/var` symlinks naar echte mappen onder `/private`; op Linux is `/bin` vaak een vergelijkbare symlink. Als je een deny-regel voor één schrijfwijze van een pad had ingesteld, maar de agent het via een andere schrijfwijze benaderde (bijvoorbeeld de echte locatie in plaats van de symlink), werd de regel niet geactiveerd. Bash-opdrachten negeerden ook een weigering voor een pad via een symlink. In 2.1.268 zijn beide gevallen opgelost: de regel geldt nu ongeacht welke schrijfwijze van het pad wordt gebruikt. **Tweede geval: `env -C` en `eval` op dezelfde regel.** De permissiecontrole parseert een opdracht om te bepalen welke bestanden deze zal benaderen. Constructies als `env -C` of `eval` kan de controle niet parseren. De bug was dat deny voor Read of Edit mogelijk niet werd toegepast wanneer zo’n constructie op de regel stond. Daardoor kon de opdracht de weigering voor het lezen of bewerken van een beschermd bestand omzeilen. **Derde geval: een regel met “!” gold buiten de eigen grenzen.** Een regel die begint met `!` hoort alleen te gelden binnen het instellingenbestand waarin die is geschreven. Vóór 2.1.269 gold die ook voor andere instellingenbronnen. Nu is het bereik beperkt tot het eigen bestand, en een regel die alleen uit `!` bestaat, wordt genegeerd. **Vierde geval: schrijven via `tee`.** De Bash-opdracht `tee` kan naar een bestand schrijven. De controle van het schrijfpad en deny-regels voor `Edit()` golden niet voor dat bestand. Tegelijkertijd gold de permissie `Bash(tee:*)` ook voor schrijven buiten werkmappen. In 2.1.269 werden deze controles ook toegepast op schrijven via `tee`: een weigering voor het bestand wordt van kracht, en `Bash(tee:*)` geldt alleen voor werkmappen. Als je gerichte weigeringen gebruikt om `.env`, enkele servicefolders of gevaarlijke opdrachten te blokkeren, moet je die ook controleren. De stappen staan hieronder. ## Waarom kon /mcp je sleutels tonen?
Belangrijkste conclusie Sleutels in MCP-configuraties worden vaak opgegeven via `${VAR}`-variabelen. De opdrachten `/mcp`, `/plugin`, `claude mcp list` en `claude mcp get`, evenals MCP-aanmeldfouten, toonden de ingevulde waarden — dus de sleutels zelf. In 2.1.268 wordt de uitvoer geredigeerd.
In MCP-serverconfiguraties worden sleutels vaak in omgevingsvariabelen bewaard en via `${VAR}` gebruikt, zodat het bestand zonder de geheimen zelf in een repository kan worden opgeslagen. Het probleem was dat opdrachten om configuraties te bekijken (`/mcp`, `/plugin`, `claude mcp list`, `claude mcp get`) en foutmeldingen bij MCP-aanmeldingen de configuratie met de ingevulde waarden toonden. De sleutel zelf verscheen op het scherm. Een andere oplossing betreft fouten in plugins en marketplaces: daarin kon een token of wachtwoord uit de bron-Git-URL worden getoond. Als de uitvoer van `/mcp` of `claude mcp list` op een oudere versie in een stream, screenshot, bericht aan een collega of logbestand verscheen dat je machine heeft verlaten, ook automatisch, ga er dan van uit dat de sleutels uit je MCP-configuraties zijn blootgesteld en vervang ze. Als de uitvoer je machine nooit heeft verlaten, volstaat bijwerken. We hebben een aparte gids over MCP-servers en kant-en-klare configuraties: [Claude Code MCP-servers](https://ailoot.ai/blog/nl/mcp-servers-claude-code/). ## Andere wijzigingen in deze versies **WebFetch en artefacten.** Voorheen gold een `WebFetch`-regel zonder details in deny of ask ook voor het lezen en wijzigen van gepubliceerde artefacten. Vanaf 2.1.268 geldt die regel daar niet meer voor. Om artefacten te blokkeren, heb je een aparte `Artifact`-regel nodig of een regel voor het domein, zoals `WebFetch(domain:claude.ai)`. Als je vertrouwde op een algemene WebFetch-weigering om het lezen van artefacten te voorkomen, controleer dan je instellingen opnieuw: de eerdere regel blokkeert deze acties niet langer. **WebFetch heeft nu een time-out.** Een verzoek aan een server die de verbinding openhoudt en het antwoord niet afrondt, mislukt nu na 300 seconden. Voorheen kon zo’n verzoek onbeperkt blijven hangen. Je kunt dit gedrag instellen met de variabele `CLAUDE_CODE_WEBFETCH_DEADLINE_MS`; stel die in op 0 om de time-out uit te schakelen. **Aanhoudend hoog CPU-gebruik tijdens inactieve sessies is verholpen.** Tijdens lange inactieve sessies kon een inactieve lus in Claude Code aanhoudend hoog CPU-gebruik veroorzaken. Deze bug is opgelost in 2.1.268. Ook mensen die sessies de hele dag open laten staan, konden er last van hebben. **Installeer de nieuwste versie.** In 2.1.269 ontstond een nieuwe bug: nadat een sessie lange tijd had gedraaid, begonnen Bash Git-opdrachten die alleen gegevens lazen om toestemming te vragen. Dit is opgelost in 2.1.270. Werk daarom bij naar de nieuwste versie (op 17 september 2026 was dat 2.1.274); blijf niet steken op 2.1.268 of 2.1.269. ## Hoe werk je bij en controleer je of weigeringen werken?
Belangrijkste conclusie Controleer de versie met `claude --version`, werk bij naar de nieuwste release en test daarna met een veilig bestand zonder geheimen: voeg er een deny-regel voor toe, vraag de agent het bestand te lezen en controleer of de weigering naar jouw regel verwijst.
1. **Controleer je huidige versie.** Voer `claude --version` uit in de terminal. De oplossingen voor de hierboven beschreven problemen zijn uitgebracht in 2.1.268 en 2.1.269. Als het versienummer lager is dan 2.1.268, bevat je versie deze oplossingen nog niet. Of elk probleem op jou van toepassing is, hangt af van de paden, opdrachten en regels die je gebruikt. 2. **Werk bij.** De gids [Claude Code bijwerken naar de nieuwste versie](https://ailoot.ai/blog/nl/update-claude-code/) bevat stapsgewijze instructies en hulp bij problemen. Kies de nieuwste versie; blijf niet steken op 2.1.268. 3. **Test de weigering.** Test een regel niet op een echte `.env`: als de weigering faalt, ziet de agent echte sleutels. Maak een testbestand, bijvoorbeeld `secret-test.txt`, met willekeurige tekst zoals “dit is een test”; voeg de regel `"Read(./secret-test.txt)"` toe aan de deny-lijst in het `.claude/settings.json`-bestand van het project; start de sessie opnieuw; en vraag: “lees het bestand secret-test.txt en vertel me wat erin staat.” Het verwachte gedrag is een weigering waarin jouw regel wordt genoemd. Als de agent het bestand leest, werkte de weigering niet in deze test. Controleer eerst de syntaxis in de bovenstaande sectie en open `/permissions` om de actieve regels te zien en uit welke bestanden ze zijn geladen. Alleen de testuitslag vertelt niet wat de oorzaak is. Eén weigering toont aan dat de regel voor dit bestand werkt; ze zegt niets over je andere regels. Controleer die daarom een voor een op dezelfde manier. 4. **Controleer het geval met symlinks als je zulke paden gebruikt.** Als je weigeringen hebt voor `/tmp`, `/etc` of `/var` op macOS, of voor `/bin` op Linux, herhaal dan na het bijwerken de test voor deze paden. 5. **Controleer regels met “!”.** Als je die hebt gebruikt, controleer dan of elke regel in het bestand staat waarin die hoort te gelden. Als de weigering werkt, maar Claude Code de bestanden die je nodig hebt nog steeds niet kan zien, bekijk dan de aparte uitleg: [waarom Claude Code projectbestanden niet kan zien](https://ailoot.ai/blog/nl/claude-code-cant-see-project-files/). ## Als je nu niet kunt bijwerken Soms moet je een update uitstellen: je kunt de omgeving niet aanpassen, de machine is eigendom van je bedrijf of je moet de huidige taak eerst afronden. Tot je bijwerkt, kun je het risico als volgt beperken: - schrijf deny-regels voor beide schrijfwijzen van het pad: de symlink en de echte locatie (op macOS staan echte paden onder `/private`); - combineer niet meerdere opdrachten op één regel en vermijd `env -C` en `eval` in opdrachten die je de agent vraagt uit te voeren; - laat niemand de uitvoer van `/mcp`, `/plugin`, `claude mcp list` of `claude mcp get` zien en vervang sleutels uit MCP-configuraties die mogelijk in handen van iemand anders zijn gevallen; - houd er rekening mee dat `tee` langs deny voor Edit heen schrijft — ga er niet van uit dat bestanden beschermd zijn als Bash is toegestaan. Deze maatregelen verkleinen de kans op specifieke omzeilingen, maar vervangen de oplossing niet. Werk bij en voer de test uit de vorige sectie uit zodra dat kan. ## Korte samenvatting Versies 2.1.268 en 2.1.269 hebben vier Claude Code-permissieproblemen opgelost: symlinks, regels met `env -C` en `eval`, regels met “!” die buiten hun eigen bestand golden, en schrijven via `tee`. Daarnaast zijn het blootleggen van geheimen in `/mcp`-uitvoer en tokens in pluginfouten opgelost. Controleer je versienummer, werk bij naar de nieuwste release en voer de test met een testbestand uit de bovenstaande sectie uit. Een weigering waarin de regel wordt genoemd, toont aan dat de weigering in deze test werkte. Alleen de aanwezigheid van een regel in de instellingen is geen voldoende controle.
### Bronnen - Claude Code, officiële changelog (vermeldingen voor 2.1.268, 2.1.269, 2.1.270): - Claude Code, releasedatums van versies op npm: - Claude Code, documentatie over permissies (syntaxis van deny/ask/allow): - Claude Code, releases op GitHub:
Om verder met modellen te werken, kun je naar [Ailoot](https://ailoot.ai/) gaan. ## Vragen en antwoorden ### Hoe test ik een deny-regel zonder een echt geheim bloot te stellen? Maak een bestand met onschadelijke tekst, verbied Read-toegang tot dat testbestand, herstart de sessie en vraag de agent het te lezen. Verwacht een weigering die jouw regel noemt. Gebruik nooit een echt .env-bestand voor een test die kan mislukken. ### Bewijst één geslaagde weigering dat al mijn machtigingen veilig zijn? Nee. Daarmee controleer je alleen het geteste bestand en toegangspad. Bekijk de actieve regels in /permissions en test vervolgens de andere paden en gevallen waarop je vertrouwt, inclusief verschillende schrijfwijzen via symbolische koppelingen als die van toepassing zijn. ## Ailoot · Het bedrijf en zijn projectenportefeuille Ailoot bouwt op opgebouwde operationele ervaring, een groot klantenbestand, een stabiele dienst en doorlopende KPI-controle. Het bedrijf en zijn projectenportefeuille: miljoenen klanten; maandelijkse verkopen in de miljarden. Ailoot gebruikt die operationele ervaring voor API-toegang tot AI-functies in klantproducten, agents, applicaties en automatiseringen.