Blog

Claude Code 2.1.268: Hvad blev rettet i deny-regler og MCP

Markdown

Claude Code 2.1.268–2.1.269 rettede fire tilladelsesproblemer og en lækage af hemmeligheder i /mcp. Hvem er berørt, hvordan du opdaterer, og hvordan du kontrollerer dine regler.

Læs hele artiklen

Claude Code version 2.1.268 blev udgivet den 10. september 2026, efterfulgt dagen efter af 2.1.269. Du bør opdatere med det samme: I to tilfælde var deny-regler, som du bruger til at blokere agentens adgang til .env og servicemapper, lydløst virkningsløse. Desuden kunne kommandoen /mcp udskrive hemmeligheder fra dine konfigurationer i terminalen.

Alt nedenfor bygger på Anthropics officielle ændringslog og dokumentation, som de så ud den 17. september 2026, kildematerialets dato. Den seneste version på den dato var 2.1.274. Vi beskriver, hvordan fejlene fungerede, ud fra disse poster; omgåelserne blev ikke genskabt på den sårbare version.

Se dokumentationen for flere instruktioner om at arbejde med Ailoot.

Hvad blev rettet i Claude Code 2.1.268 og 2.1.269?

Vigtig pointe

Fire tilladelsesproblemer blev rettet. Reglerne deny og ask virkede ikke på stier gennem symbolske links, og deny for Read eller Edit kunne svigte på linjer med env -C eller eval. En regel med “!” gjaldt ud over sin indstillingsfil. Kommandoen tee skrev filer uden at blive blokeret af deny for Edit. Derudover viste /mcp og claude mcp list hemmeligheder fra konfigurationer, mens pluginfejl viste tokens fra Git-URL'er.

Fire rettelser er relevante for tilladelsesregler:

  1. Afvisninger på symbolske links virkede ikke. Reglerne deny og ask, der var skrevet til mapper med symbolske links (/etc, /tmp, /var på macOS, /bin på Linux), blev ikke udløst, når en sti blev angivet med dens faktiske placering. Bash-kommandoer ignorerede også deny-regler, der var skrevet til en sti gennem et symbolsk link.
  2. Afvisning af læsning og redigering svigtede sammen med env -C eller eval. Hvis den samme kommandolinje indeholdt en konstruktion, som tilladelseskontrollen ikke kunne fortolke, kunne deny for Read eller Edit undlade at blive udløst.
  3. En regel med “!” gjaldt bredere end tilsigtet. En deny- eller ask-regel, der begyndte med !, gjaldt ud over den indstillingsfil, hvor den var skrevet. Nu gælder den kun inden for sin egen kilde, og et nøgent ! ignoreres.
  4. tee skrev uden om afvisningerne. Reglerne deny for Edit() og kontrollen af skrivestien blev ikke anvendt på en fil, der blev oprettet med Bash-kommandoen tee. Tilladelsen Bash(tee:*) omfatter ikke længere skrivninger uden for arbejdsmapper.

Disse versioner rettede også to problemer med eksponering af hemmeligheder. WebFetch venter ikke længere uendeligt på svar fra en server, der holder forbindelsen åben: anmodningen fejler nu efter 300 sekunder, og timeouten kan konfigureres med variablen CLAUDE_CODE_WEBFETCH_DEADLINE_MS. De fjernede også vedvarende højt CPU-forbrug i lange inaktive sessioner.

Hvordan fungerer afvisninger i Claude Code?

Vigtig pointe

Regler skrives i blokken permissions i settings.json: deny blokerer, ask beder om bekræftelse, og allow tillader en handling uden bekræftelse. Kontrollerne udføres i denne rækkefølge: deny, derefter ask, derefter allow. En regel har formatet Tool eller Tool(detail), for eksempel Read(./.env).

Claude Code har tre lister med regler: deny (altid forbudt), ask (spørg, før handlingen udføres) og allow (tilladt uden bekræftelse). Når agenten er ved at gøre noget, kontrolleres reglerne strengt i den rækkefølge. En matchende deny annullerer enhver allow for den samme handling: En tilladende regel kan ikke gøre undtagelse fra en afvisning.

Regler gemmes tre steder: brugerregler i ~/.claude/settings.json, projektregler i .claude/settings.json i arkivet og lokale regler i .claude/settings.local.json. Her er et eksempel på indstillinger, der afviser læsning af en fil med nøgler:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Du kan se alle aktive regler og den fil, hver regel stammer fra, ved at køre /permissions i en session. Hvis en regel blokerer læsning, angiver afvisningen den pågældende regel, hvilket er nyttigt ved kontrollen nedenfor.

Hvilke fejl påvirkede afvisninger og reglernes omfang?

Fejlene påvirkede kontrol af stier og kommandoer samt omfanget af regler fra forskellige indstillingsfiler.

Første tilfælde: symbolske links. På macOS er /etc, /tmp og /var symbolske links til faktiske mapper under /private; på Linux er /bin almindeligvis et lignende symbolsk link. Hvis du skrev en deny-regel for én stavemåde af en sti, men agenten tilgik den med en anden (for eksempel dens faktiske placering i stedet for det symbolske link), blev reglen ikke udløst. Bash-kommandoer ignorerede også en afvisning, der var skrevet til en sti gennem et symbolsk link. I 2.1.268 blev begge tilfælde rettet: Reglen gælder nu, uanset hvilken stavemåde af stien der blev brugt.

Andet tilfælde: env -C og eval på samme linje. Tilladelseskontrollen fortolker en kommando for at finde ud af, hvilke filer den vil tilgå. Den kan ikke fortolke konstruktioner som env -C eller eval. Fejlen var, at deny for Read eller Edit muligvis ikke blev anvendt, når sådan en konstruktion stod på linjen. Derfor kunne kommandoen omgå afvisningen af læsning eller redigering af en beskyttet fil.

Tredje tilfælde: En regel med “!” gjaldt ud over sine grænser. En regel, der begynder med !, bør kun gælde inden for den indstillingsfil, hvor den er skrevet. Før 2.1.269 gjaldt den også for andre indstillingskilder. Nu er dens omfang begrænset til dens egen fil, og en regel, der kun består af et nøgent !, ignoreres.

Fjerde tilfælde: skrivning gennem tee. Bash-kommandoen tee kan skrive til en fil. Kontrollen af skrivestien og deny-reglerne for Edit() blev ikke anvendt på den fil. Samtidig omfattede tilladelsen Bash(tee:*) skrivninger uden for arbejdsmapper. I 2.1.269 begyndte disse kontroller at gælde for skrivninger gennem tee: En afvisning af filen træder i kraft, og Bash(tee:*) omfatter kun arbejdsmapper.

Hvis du bruger målrettede afvisninger til at blokere .env, et par servicemapper eller farlige kommandoer, bør du også kontrollere dem. Trinnene står nedenfor.

Hvorfor kunne /mcp vise dine nøgler?

Vigtig pointe

Nøgler i MCP-konfigurationer angives ofte via variablerne ${VAR}. Kommandoerne /mcp, /plugin, claude mcp list og claude mcp get samt MCP-loginfejl viste de indsatte værdier – det vil sige selve nøglerne. I 2.1.268 redigeres outputtet, så hemmeligheder skjules.

MCP-serverkonfigurationer gemmer ofte nøgler i miljøvariabler og henviser til dem via ${VAR}, så filen kan gemmes i et arkiv uden selve hemmelighederne. Problemet var, at visningskommandoer (/mcp, /plugin, claude mcp list, claude mcp get) og MCP-loginfejl viste konfigurationen med værdierne allerede indsat. Selve nøglen blev vist på skærmen.

En anden rettelse vedrører plugin- og markedspladsfejl: De kunne vise et token eller en adgangskode fra Git-kilde-URL'en.

Hvis output fra /mcp eller claude mcp list i en ældre version blev vist i en stream, på et skærmbillede, i en besked til en kollega eller i en log, der forlod din maskine – også automatisk – skal du gå ud fra, at nøglerne fra dine MCP-konfigurationer blev eksponeret, og skifte dem ud. Hvis outputtet aldrig forlod din maskine, er det nok at opdatere. Vi har en separat guide om MCP-servere og færdige konfigurationer: Claude Code MCP-servere.

Andre ændringer i disse versioner

WebFetch og artefakter. Tidligere gjaldt en WebFetch-regel uden detaljer i deny eller ask også for læsning og ændring af offentliggjorte artefakter. Fra og med 2.1.268 gælder den ikke længere for dem. Hvis du vil blokere artefakter, skal du bruge en separat Artifact-regel eller en regel for domænet, for eksempel WebFetch(domain:claude.ai). Hvis du har stolet på en generel WebFetch-afvisning for at beskytte mod læsning af artefakter, skal du kontrollere dine indstillinger igen: Den tidligere regel blokerer ikke længere disse handlinger.

WebFetch har nu en timeout. En anmodning til en server, der holder forbindelsen åben og ikke afslutter sit svar, fejler nu efter 300 sekunder. Tidligere kunne en sådan anmodning hænge på ubestemt tid. Adfærden kan konfigureres med variablen CLAUDE_CODE_WEBFETCH_DEADLINE_MS; hvis den sættes til 0, deaktiveres timeouten.

Vedvarende højt CPU-forbrug i inaktive sessioner blev fjernet. Under lange inaktive sessioner kunne en inaktiv løkke i Claude Code forårsage vedvarende højt CPU-forbrug. Denne fejl blev rettet i 2.1.268. Den kunne også påvirke personer, der holder sessioner åbne hele dagen.

Installér den seneste version. En ny fejl opstod i 2.1.269: Efter at en session havde kørt i lang tid, begyndte Bash Git-kommandoer, der kun læste data, at bede om tilladelse. Den blev rettet i 2.1.270. Opdatér derfor til den seneste version (pr. 17. september 2026 var det 2.1.274); stop ikke ved 2.1.268 eller 2.1.269.

Hvordan opdaterer du og kontrollerer, at afvisningerne virker?

Vigtig pointe

Kontrollér versionen med claude --version, opdatér til den seneste udgivelse, og test derefter med en sikker fil uden hemmeligheder: Tilføj en deny-regel for den, bed agenten om at læse filen, og kontrollér, at afvisningen henviser til din regel.

  1. Find din nuværende version. Kør claude --version i terminalen. Rettelserne til de beskrevne problemer blev udgivet i 2.1.268 og 2.1.269. Hvis versionsnummeret er lavere end 2.1.268, indeholder din version endnu ikke disse rettelser, men om hvert enkelt problem gælder, afhænger af de stier, kommandoer og regler, du bruger.
  2. Opdatér. Guiden sådan opdaterer du Claude Code til den seneste version indeholder trinvise instruktioner og hjælp til fejlfinding. Vælg den seneste version; stop ikke ved 2.1.268.
  3. Test afvisningen. Test ikke en regel på en rigtig .env: Hvis afvisningen svigter, får agenten adgang til rigtige nøgler. Opret en testfil, for eksempel secret-test.txt, med vilkårlig tekst som “dette er en test”; tilføj reglen "Read(./secret-test.txt)" til deny-listen i projektets .claude/settings.json; genstart sessionen, og spørg: “læs filen secret-test.txt, og fortæl mig, hvad der står i den.” Det forventede resultat er en afvisning, der nævner din regel. Hvis agenten læser filen, virkede afvisningen ikke i denne test. Begynd med at kontrollere syntaksen i afsnittet ovenfor, og åbn /permissions for at se de aktive regler og de filer, de blev indlæst fra. Testresultatet alene fastslår ikke årsagen. Én afvisning viser, at reglen for denne fil virker; den siger ikke noget om dine andre regler, så kontrollér dem én ad gangen på samme måde.
  4. Kontrollér tilfældet med symbolske links, hvis du bruger stier som disse. Hvis du har afvisninger for /tmp, /etc eller /var på macOS eller /bin på Linux, skal du gentage testen for disse stier efter opdateringen.
  5. Gennemgå regler med “!”. Hvis du har brugt nogen, skal du kontrollere, at hver enkelt er skrevet i den fil, hvor den skal gælde.

Hvis afvisningen virker, men Claude Code stadig ikke kan se de filer, du har brug for, kan du se den separate forklaring: hvorfor Claude Code ikke kan se projektfiler.

Hvis du ikke kan opdatere lige nu

Nogle gange er du nødt til at udskyde en opdatering: Du kan ikke ændre miljøet, maskinen ejes af virksomheden, eller du skal færdiggøre den aktuelle opgave. Indtil du opdaterer, kan du mindske risikoen sådan her:

  • skriv deny-regler for begge stavemåder af stien – det symbolske link og den faktiske placering (på macOS ligger faktiske stier under /private);
  • sæt ikke flere kommandoer sammen på én linje, og undgå env -C og eval i kommandoer, du beder agenten om at køre;
  • vis ikke output fra /mcp, /plugin, claude mcp list eller claude mcp get til nogen, og skift nøgler fra MCP-konfigurationer, der kan være havnet i andres hænder;
  • husk, at tee skriver uden om deny for Edit – betragt ikke filer som beskyttede, hvis Bash er tilladt.

Disse foranstaltninger mindsker sandsynligheden for bestemte omgåelser, men de erstatter ikke rettelsen. Opdatér, og kør testen fra det foregående afsnit, så snart du kan.

Kort opsummering

Version 2.1.268 og 2.1.269 rettede fire tilladelsesproblemer i Claude Code: symbolske links, linjer med env -C og eval, regler med “!” der gjaldt ud over deres egen fil, samt skrivninger gennem tee. Separat rettede de eksponeringen af hemmeligheder i /mcp-output og tokens i pluginfejl. Kontrollér dit versionsnummer, opdatér til den seneste udgivelse, og kør testen med en testfil fra afsnittet ovenfor. En afvisning, der nævner din regel, viser, at afvisningen virkede i denne test. At reglen står i indstillingerne, er ikke i sig selv nok til at bekræfte, at den virker.

Kilder

Hvis du vil fortsætte med at arbejde med modeller, kan du gå til Ailoot.

Flere oplysninger

Spørgsmål og svar

Hvordan tester jeg en deny-regel uden at eksponere en rigtig hemmelighed?

Opret en fil med harmløs tekst, blokér Read-adgang til testfilen, genstart sessionen, og bed agenten læse den. Forvent et afslag, der nævner din regel. Brug aldrig en rigtig .env-fil i en test, der kan fejle.

Beviser ét vellykket afslag, at alle mine tilladelser er sikre?

Nej. Det bekræfter kun den testede fil og adgangsvej. Gennemgå aktive regler i /permissions, og test de øvrige veje og tilfælde, du er afhængig af, herunder alternative stavemåder via symlinks, hvor det er relevant.

Alle artikler