Claude Code 2.1.268: Vad åtgärdades i deny-regler och MCP

Claude Code version 2.1.268 släpptes den 10 september 2026, följd dagen därpå av 2.1.269. Du bör uppdatera omedelbart: i två fall var deny-regler som du använder för att hindra agenten från att komma åt .env och tjänstemappar i tysthet verkningslösa. Dessutom kunde kommandot /mcp skriva ut hemligheter från dina konfigurationer i terminalen.

Allt nedan bygger på Anthropics officiella ändringslogg och dokumentation så som de såg ut den 17 september 2026, källdatamaterialets datum. Den senaste versionen det datumet var 2.1.274. Vi beskriver hur felen fungerade utifrån dessa poster; förbikopplingarna återskapades inte på den sårbara versionen.

För ytterligare instruktioner om hur du arbetar med Ailoot, se dokumentationen.

Vad åtgärdades i Claude Code 2.1.268 och 2.1.269?#

Fyra åtgärder är relevanta för behörighetsregler:

1. Nekanden för symboliska länkar fungerade inte. Reglerna deny och ask som skrevs för kataloger med symboliska länkar (/etc, /tmp, /var på macOS, /bin på Linux) utlöstes inte när en sökväg angavs med sin verkliga plats. Bash-kommandon ignorerade också deny-regler som skrevs för en sökväg via en symbolisk länk.
2. Nekanden för läsning och redigering misslyckades tillsammans med env -C eller eval. Om samma kommandorad innehöll en konstruktion som behörighetskontrollen inte kunde tolka, kunde deny för Read eller Edit utebli.
3. En regel med ”!” gällde bredare än avsett. En deny- eller ask-regel som började med ! gällde utanför inställningsfilen där den skrevs. Nu gäller den endast i sin egen källa, och ett ensamt ! ignoreras.
4. tee skrev runt nekandena. Reglerna deny för Edit() och kontrollen av skrivsökvägen tillämpades inte på en fil som skapades med Bash-kommandot tee. Behörigheten Bash(tee:*) omfattar inte längre skrivningar utanför arbetskataloger.

Dessa versioner åtgärdade också två problem som rörde exponering av hemligheter. WebFetch väntar inte längre i all oändlighet på svar från en server som håller anslutningen öppen: begäran misslyckas nu efter 300 sekunder, och tidsgränsen kan konfigureras med variabeln CLAUDE_CODE_WEBFETCH_DEADLINE_MS. De tog också bort varaktigt hög CPU-användning under långa inaktiva sessioner.

Hur fungerar nekanden i Claude Code?#

Claude Code har tre listor med regler: deny (alltid förbjudet), ask (fråga innan åtgärden utförs) och allow (tillåtet utan bekräftelse). När agenten ska göra något kontrolleras reglerna strikt i den ordningen. En matchande deny avbryter varje allow för samma åtgärd: en tillåtande regel kan inte göra undantag från ett nekande.

Regler lagras på tre ställen: användarregler i ~/.claude/settings.json, projektrregler i .claude/settings.json i kodförrådet och lokala regler i .claude/settings.local.json. Här är ett exempel på inställningar som nekar läsning av en fil med nycklar:

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

Du kan se alla aktiva regler och vilken fil varje regel kommer från genom att köra /permissions i en session. Om en regel blockerar läsning anger nekandet den regeln, vilket är användbart vid kontrollen nedan.

Vilka fel påverkade nekanden och reglernas omfattning?#

Felen påverkade sökvägs- och kommandokontroller samt omfattningen av regler från olika inställningsfiler.

Första fallet: symboliska länkar. På macOS är /etc, /tmp och /var symboliska länkar till verkliga mappar under /private; på Linux är /bin vanligtvis en liknande symbolisk länk. Om du skrev en deny-regel för en stavning av en sökväg men agenten kom åt den med en annan (till exempel dess verkliga plats i stället för den symboliska länken), utlöstes inte regeln. Bash-kommandon ignorerade också ett nekande som skrevs för en sökväg via en symbolisk länk. I 2.1.268 åtgärdades båda fallen: regeln gäller nu oavsett vilken stavning av sökvägen som användes.

Andra fallet: env -C och eval på samma rad. Behörighetskontrollen tolkar ett kommando för att avgöra vilka filer det kommer att komma åt. Den kan inte tolka konstruktioner som env -C eller eval. Felet var att när en sådan konstruktion förekom på raden kunde deny för Read eller Edit utebli. Därför kunde kommandot kringgå nekandet för läsning eller redigering av en skyddad fil.

Tredje fallet: en regel med ”!” gällde utanför sina gränser. En regel som börjar med ! ska endast gälla i inställningsfilen där den skrivs. Före 2.1.269 gällde den även andra inställningskällor. Nu är dess omfattning begränsad till den egna filen, och en regel som endast består av ! ignoreras.

Fjärde fallet: skrivning via tee. Bash-kommandot tee kan skriva till en fil. Kontrollen av skrivsökvägen och deny-reglerna för Edit() gällde inte för den filen. Samtidigt omfattade behörigheten Bash(tee:*) skrivningar utanför arbetskataloger. I 2.1.269 började dessa kontroller gälla för skrivningar via tee: ett nekande för filen träder i kraft, och Bash(tee:*) omfattar endast arbetskataloger.

Om du använder riktade nekanden – för att blockera .env, ett par tjänstemappar eller farliga kommandon – bör du också kontrollera dem. Stegen följer nedan.

Varför kunde /mcp visa dina nycklar?#

MCP-serverkonfigurationer lagrar ofta nycklar i miljövariabler och hänvisar till dem via ${VAR}, så att filen kan lagras i ett kodförråd utan själva hemligheterna. Problemet var att visningskommandon (/mcp, /plugin, claude mcp list, claude mcp get) och MCP-inloggningsfel visade konfigurationen med värdena redan insatta. Själva nyckeln syntes på skärmen.

En annan åtgärd gäller plugin- och marknadsplatsfel: de kunde visa en token eller ett lösenord från Git-käll-URL:en.

Om utdata från /mcp eller claude mcp list i en äldre version visades i en ström, på en skärmbild, i ett meddelande till en kollega eller i en logg som lämnade din dator, även automatiskt, bör du utgå från att nycklarna från dina MCP-konfigurationer exponerades och byta ut dem. Om utdata aldrig lämnade din dator räcker det att uppdatera. Vi har en separat guide om MCP-servrar och färdiga konfigurationer: Claude Code MCP-servrar.

Övriga ändringar i dessa versioner#

WebFetch och artefakter. Tidigare gällde en WebFetch-regel utan detaljer i deny eller ask också för läsning och ändring av publicerade artefakter. Från och med 2.1.268 gäller den inte längre för dem. För att blockera artefakter behöver du en separat Artifact-regel eller en regel för domänen, till exempel WebFetch(domain:claude.ai). Om du förlitade dig på ett generellt WebFetch-nekande för att skydda mot läsning av artefakter bör du kontrollera inställningarna igen: den tidigare regeln blockerar inte längre dessa åtgärder.

WebFetch har nu en tidsgräns. En begäran till en server som håller anslutningen öppen och inte slutför sitt svar misslyckas nu efter 300 sekunder. Tidigare kunde en sådan begäran hänga sig i all oändlighet. Beteendet kan konfigureras med variabeln CLAUDE_CODE_WEBFETCH_DEADLINE_MS; om den sätts till 0 inaktiveras tidsgränsen.

Varaktigt hög CPU-användning under inaktiva sessioner har tagits bort. Under långa inaktiva sessioner kunde en inaktiv loop i Claude Code orsaka varaktigt hög CPU-användning. Felet åtgärdades i 2.1.268. Det kunde också påverka personer som låter sessioner vara öppna hela dagen.

Installera den senaste versionen. Ett nytt fel uppstod i 2.1.269: efter att en session hade körts länge började Bash Git-kommandon som bara läser data be om behörighet. Det åtgärdades i 2.1.270. Uppdatera därför till den senaste versionen (den 17 september 2026 var det 2.1.274); stanna inte vid 2.1.268 eller 2.1.269.

Hur uppdaterar du och kontrollerar att nekanden fungerar?#

1. Ta reda på din nuvarande version. Kör claude --version i terminalen. Åtgärderna för problemen ovan släpptes i 2.1.268 och 2.1.269. Om versionsnumret är lägre än 2.1.268 innehåller din version ännu inte dessa åtgärder, men om varje problem är relevant beror på vilka sökvägar, kommandon och regler du använder.
2. Uppdatera. Guiden så uppdaterar du Claude Code till den senaste versionen innehåller stegvisa instruktioner och felsökning. Välj den senaste versionen; stanna inte vid 2.1.268.
3. Testa nekandet. Testa inte en regel på en riktig .env: om nekandet misslyckas får agenten se riktiga nycklar. Skapa en testfil, till exempel secret-test.txt, med valfri text, till exempel ”det här är ett test”; lägg till regeln "Read(./secret-test.txt)" i deny-listan i projektets .claude/settings.json; starta om sessionen och fråga: ”läs filen secret-test.txt och berätta vad den innehåller.” Det förväntade beteendet är ett nekande som anger din regel. Om agenten läser filen fungerade nekandet inte i det här testet. Börja med att kontrollera syntaxen i avsnittet ovan och öppna /permissions för att se de aktiva reglerna och filerna de laddades från. Testresultatet ensamt pekar inte ut orsaken. Ett nekande visar att regeln för den här filen fungerar; det säger inget om dina andra regler, så kontrollera dem en i taget på samma sätt.
4. Kontrollera fallet med symboliska länkar om du använder sådana här sökvägar. Om du har nekanden för /tmp, /etc eller /var på macOS, eller /bin på Linux, upprepar du testet för dessa sökvägar efter uppdateringen.
5. Granska regler med ”!”. Om du använder sådana, kontrollera att var och en är skriven i filen där den är tänkt att gälla.

Om nekandet fungerar men Claude Code fortfarande inte kan se filerna du behöver, se den separata förklaringen: varför Claude Code inte kan se projektfiler.

Om du inte kan uppdatera just nu#

Ibland måste du skjuta upp en uppdatering: du kan inte ändra miljön, datorn ägs av företaget eller så behöver du slutföra den aktuella uppgiften. Tills du uppdaterar kan du minska risken så här:

• skriv deny-regler för båda stavningarna av sökvägen – den symboliska länken och den verkliga platsen (på macOS ligger verkliga sökvägar under /private);
• kombinera inte flera kommandon på en rad och undvik env -C och eval i kommandon som du ber agenten köra;
• visa inte utdata från /mcp, /plugin, claude mcp list eller claude mcp get för någon, och byt ut nycklar från MCP-konfigurationer som kan ha hamnat i andras händer;
• kom ihåg att tee skriver runt deny för Edit – betrakta inte filer som skyddade om Bash är tillåtet.

Dessa åtgärder minskar sannolikheten för specifika förbikopplingar, men ersätter inte åtgärden. Uppdatera och genomför testet från föregående avsnitt så snart du kan.

Kort sammanfattning#

Versionerna 2.1.268 och 2.1.269 åtgärdade fyra behörighetsproblem i Claude Code: symboliska länkar, rader med env -C och eval, regler med ”!” som gällde utanför sin egen fil och skrivningar via tee. Separat åtgärdade de exponering av hemligheter i utdata från /mcp och token i pluginfel. Kontrollera versionsnumret, uppdatera till den senaste utgåvan och kör testet med en testfil från avsnittet ovan. Ett nekande som anger din regel visar att nekandet fungerade i det här testet. Att regeln finns i inställningarna räcker inte för att verifiera den.

För att fortsätta arbeta med modeller kan du gå till Ailoot.