# Claude Code 2.1.268: Vad åtgärdades i deny-regler och MCP
> Claude Code 2.1.268–2.1.269 åtgärdade fyra behörighetsproblem och en läcka av hemligheter i /mcp. Vem påverkas, hur du uppdaterar och hur du kontrollerar dina regler.
Source: https://ailoot.ai/blog/sv/claude-code-2-1-268-fixes/
Canonical: https://ailoot.ai/blog/sv/claude-code-2-1-268-fixes/
Language: sv
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-040
Revision: sha256-ca1616f1906a6b864539a07edd0c266e6e04d64d51a6e7d75dfe0dbcdbeb481f
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](https://ailoot.ai/docs/).
## Vad åtgärdades i Claude Code 2.1.268 och 2.1.269?
Det viktigaste
Fyra behörighetsproblem åtgärdades. Reglerna deny och ask fungerade inte för sökvägar via symboliska länkar, och deny för Read eller Edit kunde misslyckas på rader som innehöll `env -C` eller `eval`. En regel med ”!” gällde utanför sin inställningsfil. Kommandot `tee` skrev filer utan att blockeras av deny för Edit. Dessutom visade `/mcp` och `claude mcp list` hemligheter från konfigurationer, medan pluginfel visade token från Git-URL:er.
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?
Det viktigaste
Regler skrivs i blocket `permissions` i `settings.json`: deny blockerar, ask begär bekräftelse och allow tillåter en åtgärd utan bekräftelse. Kontrollerna körs i den här ordningen: deny, sedan ask, sedan allow. En regel har formatet `Tool` eller `Tool(detail)`, till exempel `Read(./.env)`.
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:
```json
{
"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?
Det viktigaste
Nycklar i MCP-konfigurationer anges ofta via variablerna `${VAR}`. Kommandona `/mcp`, `/plugin`, `claude mcp list` och `claude mcp get`, samt MCP-inloggningsfel, visade de insatta värdena – det vill säga själva nycklarna. I 2.1.268 maskeras utdata.
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](https://ailoot.ai/blog/sv/mcp-servers-claude-code/).
## Ö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?
Det viktigaste
Kontrollera versionen med `claude --version`, uppdatera till den senaste utgåvan och testa sedan med en säker fil utan hemligheter: lägg till en deny-regel för den, be agenten läsa filen och kontrollera att nekandet hänvisar till din regel.
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](https://ailoot.ai/blog/sv/update-claude-code/) 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](https://ailoot.ai/blog/sv/claude-code-cant-see-project-files/).
## 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.
### Källor
- Claude Code, officiell ändringslogg (poster för 2.1.268, 2.1.269, 2.1.270):
- Claude Code, versionsdatum på npm:
- Claude Code, dokumentation om behörigheter (syntax för deny/ask/allow):
- Claude Code, utgåvor på GitHub:
För att fortsätta arbeta med modeller kan du gå till [Ailoot](https://ailoot.ai/).
## Frågor om den här guiden: Claude Code 2.1.268: Vad åtgärdades i deny-regler och MCP
### Hur testar jag en deny-regel utan att exponera en riktig hemlighet?
Skapa en fil med ofarlig text, neka Read-åtkomst till testfilen, starta om sessionen och be agenten läsa den. Förvänta dig ett avslag som hänvisar till din regel. Använd aldrig en riktig .env-fil i ett test som kan misslyckas.
### Bevisar ett lyckat avslag att alla mina behörigheter är säkra?
Nej. Det verifierar bara den testade filen och åtkomstvägen. Granska aktiva regler i /permissions och testa sedan de andra vägar och fall du är beroende av, inklusive alternativa sökvägar via symboliska länkar när det är relevant.
## Ailoot · Företaget och dess projektportfölj
Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll.
Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder.
Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.