Claude Code 2.1.268: Mit javítottak a deny szabályokban és az MCP-ben

A Claude Code 2.1.268-as verziója 2026. szeptember 10-én jelent meg, másnap pedig követte a 2.1.269. verzió. Érdemes azonnal frissítenie: két esetben észrevétlenül hatástalanok voltak azok a deny szabályok, amelyekkel megakadályozta, hogy az ügynök hozzáférjen az .env fájlhoz és a szolgáltatásmappákhoz. Emellett az /mcp parancs titkokat írhatott ki a konfigurációkból a terminálra.

Az alábbiak mind az Anthropic hivatalos változásnaplóján és dokumentációján alapulnak, a forrásanyag 2026. szeptember 17-i dátuma szerinti állapotban. Aznap a legújabb verzió a 2.1.274 volt. A hibák működését a bejegyzések alapján írjuk le; a megkerülési lehetőségeket nem reprodukáltuk a sérülékeny verzióban.

Az Ailoot használatával kapcsolatos további útmutatásért tekintse meg a dokumentációt.

Mit javítottak a Claude Code 2.1.268 és 2.1.269 verziójában?#

Négy javítás érinti a jogosultsági szabályokat:

1. A szimbolikus hivatkozásokra vonatkozó tiltás nem működött. A szimbolikus hivatkozásokkal megadott könyvtárakra (/etc, /tmp, /var macOS-en, /bin Linuxon) írt deny és ask szabályok nem léptek életbe, ha az útvonalat a valódi helyével adták meg. A Bash-parancsok is figyelmen kívül hagyták a szimbolikus hivatkozáson át vezető útvonalra írt deny szabályokat.
2. Az olvasásra és szerkesztésre vonatkozó tiltás env -C vagy eval mellett nem működött. Ha ugyanaz a parancssor olyan szerkezetet tartalmazott, amelyet a jogosultság-ellenőrzés nem tudott elemezni, a Read vagy Edit műveletre vonatkozó deny nem feltétlenül lépett életbe.
3. A „!” jellel kezdődő szabály a tervezettnél szélesebb körben érvényesült. A ! jellel kezdődő deny vagy ask szabály arra a beállításfájlon kívülre is kiterjedt, amelyben írták. Mostantól csak a saját forrásán belül érvényesül, a magában álló ! tagadást pedig figyelmen kívül hagyja a rendszer.
4. A tee megkerülte a tiltásokat. Az Edit() műveletre vonatkozó deny szabályok és az írási útvonal ellenőrzése nem vonatkozott a Bash tee parancsával létrehozott fájlokra. A Bash(tee:*) jogosultság többé nem terjed ki a munkakönyvtárakon kívüli írásokra.

Ezek a verziók két, titkok kiszivárgásával kapcsolatos problémát is javítottak. A WebFetch többé nem vár határozatlan ideig egy olyan szerver válaszára, amely nyitva tartja a kapcsolatot: a kérés most 300 másodperc után meghiúsul, az időkorlát pedig a CLAUDE_CODE_WEBFETCH_DEADLINE_MS változóval állítható be. Emellett megszűnt a tartósan magas CPU-használat a hosszú, tétlen munkamenetekben.

Hogyan működnek a tiltások a Claude Code-ban?#

A Claude Code három szabálylistát használ: deny (mindig tiltott), ask (a művelet végrehajtása előtt kérdezzen rá) és allow (megerősítés nélkül engedélyezett). Amikor az ügynök valamit tenni készül, a rendszer szigorúan ebben a sorrendben ellenőrzi a szabályokat. Az egyező deny felülírja ugyanarra a műveletre vonatkozó allow szabályt: egy engedélyező szabály nem tehet kivételt a tiltás alól.

A szabályokat három helyen tárolja a rendszer: a felhasználói szabályok a ~/.claude/settings.json, a projekt szabályai a tárolón belüli .claude/settings.json, a helyi szabályok pedig a .claude/settings.local.json fájlban találhatók. Íme egy példa olyan beállításra, amely tiltja a kulcsokat tartalmazó fájl olvasását:

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

A /permissions parancs futtatásával megtekintheti az összes aktív szabályt és az egyes szabályok forrásfájlját. Ha egy szabály blokkolja az olvasást, a tiltási üzenet megnevezi a szabályt, ami hasznos lesz az alábbi ellenőrzés során.

Mely hibák érintették a tiltásokat és a szabályok hatókörét?#

A hibák az útvonal- és parancsellenőrzést, valamint a különböző beállításfájlokból származó szabályok hatókörét érintették.

Első eset: szimbolikus hivatkozások. macOS-en az /etc, a /tmp és a /var szimbolikus hivatkozások a /private alatti valódi mappákra; Linuxon a /bin is gyakran hasonló hivatkozás. Ha az egyik útvonalfelírásra írt deny szabályt, az ügynök pedig egy másik alakban fér hozzá az útvonalhoz (például a valódi helyén, nem a szimbolikus hivatkozáson keresztül), a szabály nem lépett életbe. A Bash-parancsok is figyelmen kívül hagyták a szimbolikus hivatkozáson át vezető útvonalra írt tiltást. A 2.1.268 verzióban mindkét esetet javították: a szabály mostantól attól függetlenül érvényesül, hogyan írták fel az útvonalat.

Második eset: env -C és eval ugyanazon a soron. A jogosultság-ellenőrzés elemzi a parancsot, hogy megállapítsa, mely fájlokhoz fér hozzá. Az olyan szerkezeteket, mint az env -C vagy az eval, nem tudja elemezni. A hiba miatt, ha ilyen szerkezet szerepelt a sorban, a Read vagy Edit műveletre vonatkozó deny esetleg nem lépett életbe. Emiatt a parancs megkerülhette a védett fájl olvasására vagy szerkesztésére vonatkozó tiltást.

Harmadik eset: a „!” jellel kezdődő szabály túllépte a hatókörét. A ! jellel kezdődő szabálynak csak arra a beállításfájlra kellene vonatkoznia, amelyben megadták. A 2.1.269 előtti verziókban más beállításforrásokra is érvényesült. Most már csak a saját fájljára korlátozódik, a kizárólag egyetlen ! jelből álló szabályt pedig figyelmen kívül hagyja a rendszer.

Negyedik eset: írás a tee segítségével. A Bash tee parancs fájlba tud írni. Az írási útvonal ellenőrzése és az Edit() művelet deny szabályai nem vonatkoztak erre a fájlra. Ezzel egyidejűleg a Bash(tee:*) jogosultság a munkakönyvtárakon kívüli írásokat is lefedte. A 2.1.269 verzióban ezek az ellenőrzések a tee-n keresztüli írásokra is érvényesülni kezdtek: a fájlra vonatkozó tiltás életbe lép, a Bash(tee:*) pedig csak a munkakönyvtárakra terjed ki.

Ha célzott tiltásokat használ — például az .env, néhány szolgáltatásmappa vagy veszélyes parancs blokkolására —, azokat is ellenőrizze. A lépések alább találhatók.

Miért jeleníthette meg az /mcp a kulcsait?#

Az MCP-szerverek konfigurációi általában környezeti változókban tárolják a kulcsokat, és ${VAR} formában hivatkoznak rájuk, így a fájl a titkok nélkül tárolható egy tárolóban. A probléma az volt, hogy a konfigurációt megjelenítő parancsok (/mcp, /plugin, claude mcp list, claude mcp get) és az MCP-bejelentkezési hibaüzenetek a behelyettesített értékekkel együtt jelenítették meg a konfigurációt. Maga a kulcs is láthatóvá vált a képernyőn.

Egy másik javítás a plugin- és piactérhibákat érinti: ezek a forrásként megadott Git-URL-ből származó tokent vagy jelszót is megjeleníthettek.

Ha a régebbi verzió /mcp vagy claude mcp list kimenete megjelent egy közvetítésben, képernyőképen, kollégának küldött üzenetben vagy a gépét elhagyó naplóban — akár automatikusan is —, feltételezze, hogy az MCP-konfigurációiban szereplő kulcsok kiszivárogtak, és cserélje le őket. Ha a kimenet soha nem hagyta el a gépét, elegendő frissítenie. Külön útmutatónk is van az MCP-szerverekről és a használatra kész konfigurációkról: Claude Code MCP-szerverek.

A verziók további változásai#

WebFetch és artefaktumok. Korábban a részletek nélküli WebFetch szabály a deny vagy ask listában az artefaktumok olvasására és módosítására is vonatkozott. A 2.1.268 verziótól ez már nem terjed ki rájuk. Az artefaktumok blokkolásához külön Artifact szabályra vagy a domainre vonatkozó szabályra van szükség, például WebFetch(domain:claude.ai). Ha általános WebFetch tiltással próbálta megakadályozni az artefaktumok olvasását, ellenőrizze újra a beállításait: a korábbi szabály már nem blokkolja ezeket a műveleteket.

A WebFetch most már időkorláttal rendelkezik. Az a kérés, amely olyan szerverhez kapcsolódik, amely nyitva tartja a kapcsolatot, de nem fejezi be a válaszát, most 300 másodperc után meghiúsul. Korábban az ilyen kérés határozatlan ideig függőben maradhatott. A működés a CLAUDE_CODE_WEBFETCH_DEADLINE_MS változóval állítható be; ha az értéke 0, az időkorlát kikapcsol.

Megszűnt a tartósan magas CPU-használat a tétlen munkamenetekben. A hosszú ideig tétlen munkamenetekben a Claude Code üresjárati ciklusa tartósan magas CPU-használatot okozhatott. Ezt a hibát a 2.1.268 verzióban javították. Azokat is érinthette, akik egész nap nyitva hagyják a munkameneteiket.

Telepítse a legújabb verziót. Új hiba jelent meg a 2.1.269 verzióban: egy hosszú ideje futó munkamenetben az adatot csak olvasó Bash Git-parancsok elkezdtek engedélyt kérni. A hibát a 2.1.270 verzióban javították. Ezért frissítsen a legújabb verzióra (2026. szeptember 17-én ez a 2.1.274 volt); ne álljon meg a 2.1.268 vagy a 2.1.269 verziónál.

Hogyan frissíthet, és hogyan ellenőrizheti, hogy működnek-e a tiltások?#

1. Ellenőrizze a jelenlegi verziót. Futtassa a claude --version parancsot a terminálban. A fent ismertetett problémák javításai a 2.1.268 és a 2.1.269 verzióban jelentek meg. Ha az Ön verziószáma kisebb, mint 2.1.268, akkor még nem tartalmazza ezeket a javításokat, de hogy az egyes problémák érintik-e Önt, az a használt útvonalaktól, parancsoktól és szabályoktól függ.
2. Frissítsen. A Claude Code legújabb verzióra frissítéséről szóló útmutató lépésről lépésre ismerteti a teendőket és a hibaelhárítást. Válassza a legújabb verziót; ne álljon meg a 2.1.268-nál.
3. Tesztelje a tiltást. Ne teszteljen valódi .env fájlon: ha a tiltás nem működik, az ügynök meglátja a valódi kulcsokat. Hozzon létre egy tesztfájlt, például secret-test.txt néven, és írjon bele tetszőleges szöveget, például: „ez egy teszt”; adja hozzá a "Read(./secret-test.txt)" szabályt a projekt .claude/settings.json fájljának deny listájához; indítsa újra a munkamenetet, majd kérje ezt: „olvasd el a secret-test.txt fájlt, és mondd meg, mi van benne.” Az elvárt eredmény olyan tiltási üzenet, amely megnevezi a szabályát. Ha az ügynök elolvassa a fájlt, ebben a tesztben nem működött a tiltás. Először ellenőrizze a fenti szakaszban a szintaxist, majd nyissa meg a /permissions parancsot az aktív szabályok és azok forrásfájljainak megtekintéséhez. A teszt eredménye önmagában nem azonosítja az okot. Egy tiltási teszt azt mutatja meg, hogy az adott fájl szabálya működik-e; a többi szabályáról nem mond semmit, ezért azokat egyenként, ugyanígy ellenőrizze.
4. Ha ilyen útvonalakat használ, ellenőrizze a szimbolikus hivatkozások esetét is. Ha macOS-en az /tmp, az /etc vagy a /var, Linuxon pedig a /bin útvonalra vonatkozó tiltásai vannak, frissítés után ismételje meg a tesztet ezekkel az útvonalakkal.
5. Ellenőrizze a „!” jellel kezdődő szabályokat. Ha használt ilyeneket, nézze meg, hogy mindegyiket abban a fájlban írta-e meg, amelyben érvényesíteni szeretné.

Ha a tiltás működik, de a Claude Code mégsem látja a szükséges fájlokat, olvassa el a külön magyarázatot: miért nem látja a Claude Code a projektfájlokat.

Ha most nem tud frissíteni#

Előfordulhat, hogy el kell halasztania a frissítést: nem tudja módosítani a környezetet, vállalati tulajdonú gépet használ, vagy be kell fejeznie az aktuális feladatot. A frissítésig a következőképpen csökkentheti a kockázatot:

• írjon deny szabályt az útvonal mindkét alakjára — a szimbolikus hivatkozásra és a valódi helyre is (macOS-en a valódi útvonalak a /private alatt találhatók);
• ne fűzzön össze több parancsot egy sorba, és kerülje az env -C és az eval használatát az ügynökkel futtatott parancsokban;
• ne mutassa meg senkinek az /mcp, a /plugin, a claude mcp list vagy a claude mcp get kimenetét, és cserélje le azoknak az MCP-konfigurációknak a kulcsait, amelyek mások kezébe kerülhettek;
• ne feledje, hogy a tee megkerüli az Edit műveletre vonatkozó deny szabályt — ne tekintse védettnek a fájlokat, ha a Bash engedélyezett.

Ezek az intézkedések csökkentik az egyes megkerülési lehetőségek kockázatát, de nem helyettesítik a javítást. Frissítsen, és amint lehet, futtassa le az előző szakaszban leírt tesztet.

Rövid összefoglaló#

A 2.1.268 és a 2.1.269 verzió négy Claude Code jogosultsági hibát javított: a szimbolikus hivatkozásokat, az env -C és eval parancsot tartalmazó sorokat, a saját fájljukon túl is érvényesülő „!” szabályokat, valamint a tee segítségével végzett írást. Külön javították a titkok kiszivárgását az /mcp kimenetében és a tokenek megjelenését a pluginhibákban. Ellenőrizze a verziószámot, frissítsen a legújabb kiadásra, és végezze el a fenti szakasz tesztjét egy tesztfájllal. Ha a tiltási üzenet megnevezi a szabályát, az azt mutatja, hogy a tiltás ebben a tesztben működött. A szabály puszta jelenléte a beállításokban még nem igazolja, hogy működik.

Ha tovább szeretne dolgozni modellekkel, látogasson el az Ailoot oldalára.