Claude Code 2.1.268: Hva ble rettet i deny-regler og MCP

Claude Code versjon 2.1.268 ble utgitt 10. september 2026, etterfulgt av 2.1.269 dagen etter. Du bør oppdatere med en gang: I to tilfeller var deny-regler du bruker til å hindre agenten i å få tilgang til .env og tjenestemapper, virkningsløse uten varsel. I tillegg kunne kommandoen /mcp skrive ut hemmeligheter fra konfigurasjonene dine i terminalen.

Alt nedenfor bygger på Anthropics offisielle endringslogg og dokumentasjon slik de forelå 17. september 2026, datoen for kildematerialet. Den nyeste versjonen på denne datoen var 2.1.274. Vi beskriver hvordan feilene fungerte ut fra disse oppføringene; omgåelsene ble ikke gjenskapt på den sårbare versjonen.

Du finner flere instruksjoner for bruk av Ailoot i dokumentasjonen.

Hva ble rettet i Claude Code 2.1.268 og 2.1.269?#

Fire rettelser er relevante for tillatelsesregler:

1. Avvisninger for symbolske lenker virket ikke. deny- og ask-regler for mapper som nås via symbolske lenker (/etc, /tmp, /var på macOS, /bin på Linux) ble ikke utløst når en sti ble angitt med den faktiske plasseringen. Bash-kommandoer ignorerte også deny-regler for en sti via en symbolsk lenke.
2. Avvisning av lesing og redigering sviktet sammen med env -C eller eval. Hvis samme kommandolinje inneholdt en konstruksjon som tillatelseskontrollen ikke kunne tolke, kunne deny for Read eller Edit unnlate å bli utløst.
3. En regel med «!» fikk større virkeområde enn tiltenkt. En deny- eller ask-regel som begynte med !, fikk virkning utenfor innstillingsfilen der den var skrevet. Nå gjelder den bare innenfor sin egen kilde, og en frittstående negasjon ! ignoreres.
4. tee skrev utenom avvisningene. deny-regler for Edit() og kontrollen av skrivebanen ble ikke brukt på en fil som ble opprettet av Bash-kommandoen tee. Tillatelsen Bash(tee:*) dekker ikke lenger skriving utenfor arbeidsmapper.

Disse versjonene rettet også to problemer knyttet til eksponering av hemmeligheter. WebFetch venter ikke lenger på ubestemt tid på svar fra en server som holder forbindelsen åpen: Forespørselen feiler nå etter 300 sekunder, og tidsavbruddet kan konfigureres med variabelen CLAUDE_CODE_WEBFETCH_DEADLINE_MS. De fjernet også vedvarende høy CPU-bruk i lange inaktive økter.

Hvordan fungerer avvisninger i Claude Code?#

Claude Code har tre lister med regler: deny (alltid forbudt), ask (spør før handlingen utføres) og allow (tillatt uten bekreftelse). Når agenten skal gjøre noe, kontrolleres reglene strengt i denne rekkefølgen. En deny-regel som samsvarer, opphever en allow-regel for samme handling: en regel som tillater noe, kan ikke gjøre unntak fra en avvisning.

Reglene lagres på tre steder: brukerregler i ~/.claude/settings.json, prosjektregler i .claude/settings.json i repositoriet og lokale regler i .claude/settings.local.json. Her er et eksempel på innstillinger som hindrer lesing av en fil med nøkler:

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

Du kan se alle aktive regler og hvilken fil hver av dem kommer fra, ved å kjøre /permissions i en økt. Hvis en regel blokkerer lesing, viser avvisningen navnet på regelen. Det er nyttig for kontrollen nedenfor.

Hvilke feil påvirket avvisninger og reglenes virkeområde?#

Feilene påvirket kontroll av stier og kommandoer, samt virkeområdet til regler fra ulike innstillingsfiler.

Første tilfelle: symbolske lenker. På macOS er /etc, /tmp og /var symbolske lenker til faktiske mapper under /private; på Linux er /bin ofte en lignende symbolsk lenke. Hvis du skrev en deny-regel for én skrivemåte av en sti, men agenten åpnet den med en annen (for eksempel den faktiske plasseringen i stedet for den symbolske lenken), ble regelen ikke utløst. Bash-kommandoer ignorerte også en avvisning for en sti via en symbolsk lenke. I 2.1.268 ble begge tilfellene rettet: Regelen gjelder nå uansett hvilken skrivemåte for stien som ble brukt.

Andre tilfelle: env -C og eval på samme linje. Tillatelseskontrollen analyserer en kommando for å finne ut hvilke filer den vil åpne. Den kan ikke analysere konstruksjoner som env -C eller eval. Feilen var at deny for Read eller Edit kunne utebli når en slik konstruksjon sto på linjen. Dermed kunne kommandoen omgå avvisningen av lesing eller redigering av en beskyttet fil.

Tredje tilfelle: en regel med «!» fikk virkning utenfor grensene sine. En regel som begynner med !, skal bare gjelde i innstillingsfilen der den er skrevet. Før 2.1.269 gjaldt den også andre innstillingskilder. Nå er virkeområdet begrenset til sin egen fil, og en regel som bare består av !, ignoreres.

Fjerde tilfelle: skriving via tee. Bash-kommandoen tee kan skrive til en fil. Kontroll av skrivebanen og deny-regler for Edit() ble ikke brukt på denne filen. Samtidig gjaldt tillatelsen Bash(tee:*) også skriving utenfor arbeidsmapper. I 2.1.269 begynte disse kontrollene å gjelde for skriving via tee: En avvisning for filen trer i kraft, og Bash(tee:*) gjelder bare for arbeidsmapper.

Hvis du bruker målrettede avvisninger for å blokkere .env, et par tjenestemapper eller farlige kommandoer, bør du kontrollere dem også. Fremgangsmåten finner du nedenfor.

Hvorfor kunne /mcp vise nøklene dine?#

MCP-serverkonfigurasjoner lagrer ofte nøkler i miljøvariabler og viser til dem via ${VAR}, slik at filen kan lagres i et repositorium uten selve hemmelighetene. Problemet var at kommandoer for visning (/mcp, /plugin, claude mcp list, claude mcp get) og MCP-påloggingsfeil viste konfigurasjonen med verdiene satt inn. Selve nøkkelen ble vist på skjermen.

En annen rettelse gjelder feil i pluginer og markedsplasser: De kunne vise et token eller passord fra kilde-Git-nettadressen.

Hvis utdata fra /mcp eller claude mcp list på en eldre versjon dukket opp i en strømming, et skjermbilde, en melding til en kollega eller en logg som forlot maskinen din, også automatisk, bør du anta at nøklene fra MCP-konfigurasjonene dine ble eksponert og bytte dem ut. Hvis utdataene aldri forlot maskinen din, er det nok å oppdatere. Vi har en egen guide om MCP-servere og ferdige oppsett: Claude Code MCP-servere.

Andre endringer i disse versjonene#

WebFetch og artefakter. Tidligere gjaldt en WebFetch-regel uten detaljer i deny eller ask også lesing og endring av publiserte artefakter. Fra og med 2.1.268 gjelder den ikke lenger for dem. For å blokkere artefakter trenger du en egen Artifact-regel eller en regel for domenet, for eksempel WebFetch(domain:claude.ai). Hvis du stolte på en generell WebFetch-avvisning for å hindre lesing av artefakter, bør du kontrollere innstillingene på nytt: Den tidligere regelen blokkerer ikke lenger disse handlingene.

WebFetch har nå et tidsavbrudd. En forespørsel til en server som holder forbindelsen åpen og ikke fullfører svaret, feiler nå etter 300 sekunder. Tidligere kunne en slik forespørsel henge på ubestemt tid. Atferden kan konfigureres med variabelen CLAUDE_CODE_WEBFETCH_DEADLINE_MS; hvis den settes til 0, deaktiveres tidsavbruddet.

Vedvarende høy CPU-bruk i inaktive økter er fjernet. I lange inaktive økter kunne en inaktiv løkke i Claude Code føre til vedvarende høy CPU-bruk. Denne feilen ble rettet i 2.1.268. Den kunne også påvirke personer som lar økter stå åpne hele dagen.

Installer den nyeste versjonen. En ny feil oppsto i 2.1.269: Etter at en økt hadde kjørt lenge, begynte Bash Git-kommandoer som bare leste data, å be om tillatelse. Dette ble rettet i 2.1.270. Oppdater derfor til den nyeste versjonen (per 17. september 2026 var det 2.1.274); ikke stopp ved 2.1.268 eller 2.1.269.

Hvordan oppdaterer du og kontrollerer at avvisninger virker?#

1. Finn ut hvilken versjon du har. Kjør claude --version i terminalen. Rettelsene for problemene som er beskrevet ovenfor, ble utgitt i 2.1.268 og 2.1.269. Hvis versjonsnummeret er lavere enn 2.1.268, inneholder versjonen din ennå ikke disse rettelsene, men om hvert enkelt problem gjelder, avhenger av hvilke stier, kommandoer og regler du bruker.
2. Oppdater. Guiden slik oppdaterer du Claude Code til den nyeste versjonen inneholder trinnvise instruksjoner og feilsøking. Velg den nyeste versjonen; ikke stopp ved 2.1.268.
3. Test avvisningen. Ikke test en regel på en ekte .env-fil: Hvis avvisningen svikter, får agenten se ekte nøkler. Opprett en testfil, for eksempel secret-test.txt, med valgfri tekst som «dette er en test»; legg til regelen "Read(./secret-test.txt)" i deny-listen i prosjektets .claude/settings.json; start økten på nytt; og be agenten: «les filen secret-test.txt og fortell meg hva den inneholder.» Forventet resultat er en avvisning som viser til regelen din. Hvis agenten leser filen, virket ikke avvisningen i denne testen. Begynn med å kontrollere syntaksen i delen ovenfor, og åpne /permissions for å se de aktive reglene og hvilke filer de ble lastet fra. Testresultatet alene identifiserer ikke årsaken. Én avvisning viser at regelen for denne filen virker; den sier ingenting om de andre reglene dine, så kontroller dem én om gangen på samme måte.
4. Kontroller tilfellet med symbolske lenker hvis du bruker slike stier. Hvis du har avvisninger for /tmp, /etc eller /var på macOS, eller /bin på Linux, gjentar du testen for disse stiene etter oppdateringen.
5. Gå gjennom regler med «!». Hvis du har brukt noen, kontroller at hver av dem er skrevet i filen den skal gjelde i.

Hvis avvisningen virker, men Claude Code fortsatt ikke kan se filene du trenger, kan du lese den separate forklaringen: hvorfor Claude Code ikke kan se prosjektfiler.

Hvis du ikke kan oppdatere akkurat nå#

Noen ganger må du utsette en oppdatering: Du kan ikke endre miljøet, maskinen eies av bedriften, eller du må fullføre den pågående oppgaven. Inntil du oppdaterer, kan du redusere risikoen slik:

• skriv deny-regler for begge skrivemåtene for stien – den symbolske lenken og den faktiske plasseringen (på macOS ligger faktiske stier under /private);
• ikke kombiner flere kommandoer på én linje, og unngå env -C og eval i kommandoer du ber agenten kjøre;
• ikke vis noen utdataene fra /mcp, /plugin, claude mcp list eller claude mcp get, og bytt ut nøkler fra MCP-konfigurasjoner som kan ha havnet i andres hender;
• husk at tee skriver utenom deny for Edit – ikke regn filer som beskyttet hvis Bash er tillatt.

Disse tiltakene reduserer sannsynligheten for bestemte omgåelser, men erstatter ikke rettelsen. Oppdater og kjør testen fra forrige avsnitt så snart du kan.

Kort oppsummering#

Versjon 2.1.268 og 2.1.269 rettet fire problemer med Claude Code-tillatelser: symbolske lenker, linjer med env -C og eval, regler med «!» som gjaldt utenfor sin egen fil, og skriving via tee. I tillegg ble eksponering av hemmeligheter i /mcp-utdata og token i pluginfeil rettet. Kontroller versjonsnummeret, oppdater til den nyeste utgaven, og kjør testen med en testfil fra avsnittet ovenfor. En avvisning som viser til regelen din, viser at avvisningen virket i denne testen. At regelen finnes i innstillingene, er ikke nok til å bekrefte at den virker.

For å fortsette å arbeide med modeller kan du gå til Ailoot.