# Claude Code 2.1.268: Mit javítottak a deny szabályokban és az MCP-ben > A Claude Code 2.1.268–2.1.269 négy jogosultsági hibát és egy titokszivárgást javított az /mcp-ben. Kit érint, hogyan frissíthet, és hogyan ellenőrizheti a szabályait. Source: https://ailoot.ai/blog/hu/claude-code-2-1-268-fixes/ Canonical: https://ailoot.ai/blog/hu/claude-code-2-1-268-fixes/ Language: hu Publisher: Ailoot (https://ailoot.ai/) Translation: guide-040 Revision: sha256-9335323d2017d9343be1a87fcb3982f7ba58a8ad077b3b98825d27ba6d610904 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](https://ailoot.ai/docs/). ## Mit javítottak a Claude Code 2.1.268 és 2.1.269 verziójában?
Fő tanulság Négy jogosultsági hibát javítottak. A deny és ask szabályok szimbolikus hivatkozásokon át vezető útvonalak esetén nem működtek, és a Read vagy Edit műveletre vonatkozó deny elmaradhatott az `env -C` vagy `eval` karakterláncot tartalmazó sorokon. A „!” jellel kezdődő szabály a saját beállításfájlján túl is érvényesült. A `tee` parancs fájlokat írt anélkül, hogy az Edit műveletre vonatkozó deny blokkolta volna. Emellett az `/mcp` és a `claude mcp list` titkokat jelenített meg a konfigurációkból, a pluginhibák pedig Git-URL-ekből származó tokeneket.
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?
Fő tanulság A szabályokat a `settings.json` fájl `permissions` blokkjában kell megadni: a deny blokkol, az ask megerősítést kér, az allow pedig megerősítés nélkül engedélyez egy műveletet. Az ellenőrzés sorrendje: deny, majd ask, végül allow. Egy szabály formátuma `Tool` vagy `Tool(detail)`, például `Read(./.env)`.
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: ```json { "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?
Fő tanulság Az MCP-konfigurációk kulcsait gyakran `${VAR}` változókon keresztül adják meg. Az `/mcp`, a `/plugin`, a `claude mcp list` és a `claude mcp get` parancsok, valamint az MCP-bejelentkezési hibák a behelyettesített értékeket, vagyis magukat a kulcsokat jelenítették meg. A 2.1.268 verzióban a kimenet már kitakarja ezeket.
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](https://ailoot.ai/blog/hu/mcp-servers-claude-code/). ## 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?
Fő tanulság Ellenőrizze a verziót a `claude --version` paranccsal, frissítsen a legújabb kiadásra, majd tesztelje egy titkot nem tartalmazó, biztonságos fájllal: adjon meg rá deny szabályt, kérje meg az ügynököt, hogy olvassa el, és győződjön meg arról, hogy a tiltási üzenet az Ön szabályára hivatkozik.
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ó](https://ailoot.ai/blog/hu/update-claude-code/) 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](https://ailoot.ai/blog/hu/claude-code-cant-see-project-files/). ## 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.
### Források - Claude Code, hivatalos változásnapló (bejegyzések a 2.1.268, 2.1.269 és 2.1.270 verzióhoz): - Claude Code, verziókiadási dátumok az npm-en: - Claude Code, jogosultságok dokumentációja (deny/ask/allow szintaxis): - Claude Code, GitHub-kiadások:
Ha tovább szeretne dolgozni modellekkel, látogasson el az [Ailoot oldalára](https://ailoot.ai/). ## Kérdések és válaszok: Claude Code 2.1.268: Mit javítottak a deny szabályokban és az MCP-ben ### Hogyan teszteljek egy deny szabályt valódi titok felfedése nélkül? Hozz létre egy ártalmatlan szöveget tartalmazó fájlt, tiltsd le hozzá a Read-hozzáférést, indítsd újra a munkamenetet, és kérd meg az ügynököt az olvasására. A szabályodat megnevező elutasítást kell kapnod. Soha ne valódi .env fájllal végezz olyan tesztet, amely hibásan is működhet. ### Egy sikeres tiltási teszt bizonyítja az összes jogosultság biztonságát? Nem. Csak a tesztelt fájlt és hozzáférési útvonalat igazolja. A /permissions alatt nézd át az aktív szabályokat, majd próbáld ki a többi olyan útvonalat és esetet is, amelyre támaszkodsz, szükség esetén a szimbolikus hivatkozásokon át történő elérést is. ## Ailoot · A vállalat és projektportfóliója Az Ailoot felhalmozott működési tapasztalatra, széles ügyfélkörre, stabil szolgáltatásra és folyamatos KPI-ellenőrzésre épít. A vállalat és projektportfóliója: ügyfelek milliói; havi értékesítés milliárdos nagyságrendben. Az Ailoot ezt a működési tapasztalatot használja az ügyfelek termékeiben, ágenseiben, alkalmazásaiban és automatizálásaiban elérhető AI-funkciók API-hozzáféréséhez.