Claude Code 2.1.268: Mitä deny-säännöissä ja MCP:ssä korjattiin

Claude Code -versio 2.1.268 julkaistiin 10. syyskuuta 2026, ja sitä seurasi seuraavana päivänä versio 2.1.269. Päivitä heti: kahdessa tapauksessa deny-säännöt, joilla estät agenttia käyttämästä .env-tiedostoja ja palvelukansioita, eivät toimineet, eikä siitä ilmoitettu. Lisäksi /mcp-komento saattoi tulostaa asetustiedostoistasi salaisuuksia päätteeseen.

Kaikki alla oleva perustuu Anthropicin viralliseen muutoslokiin ja dokumentaatioon sellaisina kuin ne olivat 17. syyskuuta 2026, eli lähdemateriaalin päiväyksenä. Uusin versio tuona päivänä oli 2.1.274. Kuvaamme virheiden toimintaa näiden merkintöjen perusteella; ohituksia ei toistettu haavoittuvalla versiolla.

Lisäohjeita Ailootin käyttöön on dokumentaatiossa.

Mitä korjattiin Claude Code -versioissa 2.1.268 ja 2.1.269?#

Käyttöoikeussääntöihin liittyy neljä korjausta:

1. Symbolisiin linkkeihin kohdistuvat estot eivät toimineet. Symbolisten linkkien kautta avautuville hakemistoille (/etc, /tmp, /var macOS:ssä ja /bin Linuxissa) kirjoitetut deny- ja ask-säännöt eivät käynnistyneet, kun polku ilmoitettiin sen todellisella sijainnilla. Myös Bash-komennot sivuuttivat polulle symbolisen linkin kautta kirjoitetut deny-säännöt.
2. Lukemisen ja muokkaamisen estot epäonnistuivat yhdessä env -C- tai eval-rakenteen kanssa. Jos samalla komentorivillä oli rakenne, jota käyttöoikeustarkistus ei pystynyt jäsentämään, Read- tai Edit-toimintoon kohdistuva deny saattoi jäädä käynnistymättä.
3. ”!”-merkillä alkava sääntö vaikutti aiottua laajemmin. !-merkillä alkava deny- tai ask-sääntö vaikutti sen asetustiedoston ulkopuolelle, johon se oli kirjoitettu. Nyt se vaikuttaa vain omassa lähteessään, ja yksittäinen ! ohitetaan.
4. tee kiersi estot kirjoittamalla tiedostoihin. Edit()-toiminnon deny-sääntöjä ja kirjoituspolun tarkistusta ei sovellettu Bashin tee-komennolla luotuun tiedostoon. Bash(tee:*)-käyttöoikeus ei enää kata kirjoittamista työhakemistojen ulkopuolelle.

Näissä versioissa korjattiin myös kaksi salaisuuksien paljastumiseen liittyvää ongelmaa. WebFetch ei enää odota loputtomasti vastausta palvelimelta, joka pitää yhteyden auki: pyyntö epäonnistuu nyt 300 sekunnin kuluttua, ja aikakatkaisun voi määrittää CLAUDE_CODE_WEBFETCH_DEADLINE_MS-muuttujalla. Lisäksi pitkien joutenolojaksojen jatkuva suuri suorittimen käyttö poistettiin.

Miten estot toimivat Claude Codessa?#

Claude Codessa on kolme sääntöluetteloa: deny (aina kielletty), ask (kysy ennen toiminnon tekemistä) ja allow (sallittu ilman vahvistusta). Kun agentti on tekemässä jotakin, säännöt tarkistetaan täsmälleen tässä järjestyksessä. Täsmäävä deny kumoaa saman toiminnon allow-säännön: salliva sääntö ei voi tehdä poikkeusta estoon.

Sääntöjä tallennetaan kolmeen paikkaan: käyttäjän säännöt tiedostossa ~/.claude/settings.json, projektin säännöt arkiston sisäisessä tiedostossa .claude/settings.json ja paikalliset säännöt tiedostossa .claude/settings.local.json. Tässä on esimerkki asetuksista, joilla estetään avaimia sisältävän tiedoston lukeminen:

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

Näet kaikki aktiiviset säännöt ja tiedoston, josta kukin niistä on peräisin, suorittamalla istunnossa /permissions. Jos sääntö estää lukemisen, estoviestissä mainitaan kyseinen sääntö, mistä on hyötyä alla olevassa tarkistuksessa.

Mitkä virheet vaikuttivat estoihin ja sääntöjen soveltamisalaan?#

Virheet vaikuttivat polku- ja komentotarkistuksiin sekä eri asetustiedostoista tulevien sääntöjen soveltamisalaan.

Ensimmäinen tapaus: symboliset linkit. macOS:ssä /etc, /tmp ja /var ovat symbolisia linkkejä niiden todellisiin kansioihin /private-hakemistossa. Linuxissa /bin on tavallisesti vastaava symbolinen linkki. Jos kirjoitit deny-säännön polun yhdelle nimelle mutta agentti käytti polkua toisella nimellä (esimerkiksi sen todellista sijaintia symbolisen linkin sijaan), sääntö ei käynnistynyt. Myös Bash-komennot sivuuttivat symbolisen linkin kautta määritetylle polulle kirjoitetun eston. Versiossa 2.1.268 molemmat tapaukset korjattiin: sääntöä sovelletaan nyt riippumatta siitä, millä polun nimellä sitä käytetään.

Toinen tapaus: env -C ja eval samalla rivillä. Käyttöoikeustarkistus jäsentää komennon selvittääkseen, mitä tiedostoja se käyttää. Se ei pysty jäsentämään esimerkiksi env -C- tai eval-rakennetta. Virhe oli se, että kun tällainen rakenne oli samalla rivillä, Read- tai Edit-toimintoon kohdistuvaa deny-sääntöä ei välttämättä sovellettu. Tämän vuoksi komento saattoi ohittaa suojatun tiedoston lukemista tai muokkaamista koskevan eston.

Kolmas tapaus: ”!”-merkillä alkava sääntö vaikutti rajojensa ulkopuolella. !-merkillä alkavan säännön pitäisi vaikuttaa vain siinä asetustiedostossa, johon se on kirjoitettu. Ennen versiota 2.1.269 se vaikutti myös muihin asetusten lähteisiin. Nyt sen soveltamisala rajoittuu omaan tiedostoonsa, ja pelkästä !-merkistä koostuva sääntö ohitetaan.

Neljäs tapaus: kirjoittaminen tee-komennolla. Bashin tee-komennolla voi kirjoittaa tiedostoon. Kirjoituspolun tarkistus ja Edit()-toiminnon deny-säännöt eivät vaikuttaneet kyseiseen tiedostoon. Samalla Bash(tee:*)-käyttöoikeus kattoi kirjoittamisen työhakemistojen ulkopuolelle. Versiossa 2.1.269 näitä tarkistuksia alettiin soveltaa tee-komennolla kirjoittamiseen: tiedostoon kohdistuva esto tulee voimaan, ja Bash(tee:*) kattaa vain työhakemistot.

Jos käytät kohdennettuja estoja esimerkiksi .env-tiedoston, muutaman palvelukansion tai vaarallisten komentojen estämiseen, sinun kannattaa tarkistaa nekin. Ohjeet ovat alla.

Miksi /mcp saattoi näyttää avaimesi?#

MCP-palvelinten asetustiedostoissa avaimet säilytetään usein ympäristömuuttujissa, joihin viitataan ${VAR}-muuttujilla. Näin tiedosto voidaan tallentaa arkistoon ilman varsinaisia salaisuuksia. Ongelma oli se, että näyttökomennot (/mcp, /plugin, claude mcp list, claude mcp get) ja MCP-kirjautumisvirheilmoitukset näyttivät asetukset, joissa muuttujien arvot oli jo korvattu. Itse avain näkyi näytöllä.

Toinen korjaus koskee lisäosien ja markkinapaikan virheitä: ne saattoivat näyttää tunnisteen tai salasanan lähteen Git-URL-osoitteesta.

Jos vanhemman version /mcp- tai claude mcp list -tuloste näkyi suoratoistossa, kuvakaappauksessa, kollegalle lähetetyssä viestissä tai lokissa, joka poistui koneeltasi automaattisesti tai muuten, oleta, että MCP-asetustiedostojesi avaimet paljastuivat, ja vaihda ne. Jos tuloste ei koskaan poistunut koneeltasi, päivittäminen riittää. Meillä on erillinen opas MCP-palvelimista ja valmiista asetuksista: Claude Code MCP-palvelimet.

Näiden versioiden muut muutokset#

WebFetch ja artefaktit. Aiemmin WebFetch-sääntö ilman tarkempia tietoja deny- tai ask-luettelossa koski myös julkaistujen artefaktien lukemista ja muokkaamista. Versiosta 2.1.268 alkaen se ei enää koske niitä. Artefaktien estämiseen tarvitaan erillinen Artifact-sääntö tai verkkotunnusta koskeva sääntö, kuten WebFetch(domain:claude.ai). Jos olet luottanut yleiseen WebFetch-estoon artefaktien lukemisen estämiseksi, tarkista asetuksesi uudelleen: aiempi sääntö ei enää estä näitä toimintoja.

WebFetchissä on nyt aikakatkaisu. Pyyntö palvelimelle, joka pitää yhteyden auki eikä viimeistele vastaustaan, epäonnistuu nyt 300 sekunnin kuluttua. Aiemmin tällainen pyyntö saattoi jumiutua loputtomasti. Toimintaa voi määrittää CLAUDE_CODE_WEBFETCH_DEADLINE_MS-muuttujalla; arvon 0 asettaminen poistaa aikakatkaisun käytöstä.

Jouten olevien istuntojen jatkuva suuri suorittimen käyttö poistettiin. Claude Coden joutenolotilassa oleva silmukka saattoi aiheuttaa jatkuvasti suurta suorittimen käyttöä pitkien joutoistuntojen aikana. Tämä virhe korjattiin versiossa 2.1.268. Se saattoi vaikuttaa myös niihin, jotka pitävät istuntoja auki koko päivän.

Asenna uusin versio. Versiossa 2.1.269 ilmeni uusi virhe: pitkään käynnissä olleen istunnon jälkeen Bashin Git-komennot, jotka vain lukivat tietoja, alkoivat pyytää käyttöoikeutta. Se korjattiin versiossa 2.1.270. Päivitä siis uusimpaan versioon (17. syyskuuta 2026 se oli 2.1.274); älä pysähdy versioon 2.1.268 tai 2.1.269.

Miten päivität ja tarkistat, että estot toimivat?#

1. Selvitä nykyinen versiosi. Suorita päätteessä claude --version. Edellä kuvattujen ongelmien korjaukset julkaistiin versioissa 2.1.268 ja 2.1.269. Jos versionumero on pienempi kuin 2.1.268, versiossasi ei vielä ole näitä korjauksia. Se, koskeeko kukin ongelma sinua, riippuu kuitenkin käyttämistäsi poluista, komennoista ja säännöistä.
2. Päivitä. Oppaassa näin päivität Claude Coden uusimpaan versioon on vaiheittaiset ohjeet ja vianmääritysohjeita. Valitse uusin versio; älä pysähdy versioon 2.1.268.
3. Testaa esto. Älä testaa sääntöä oikealla .env-tiedostolla: jos esto epäonnistuu, agentti näkee oikeat avaimet. Luo testitiedosto, esimerkiksi secret-test.txt, ja kirjoita siihen mitä tahansa, kuten ”tämä on testi”; lisää sääntö "Read(./secret-test.txt)" projektin .claude/settings.json-tiedoston deny-luetteloon; käynnistä istunto uudelleen ja kysy: ”lue tiedosto secret-test.txt ja kerro, mitä sen sisältö on.” Odotuksena on esto, jossa sääntösi mainitaan. Jos agentti lukee tiedoston, esto ei toiminut tässä testissä. Tarkista ensin yllä olevan osion syntaksi ja avaa /permissions, niin näet aktiiviset säännöt ja tiedostot, joista ne ladattiin. Testitulos yksin ei kerro syytä. Yksi esto osoittaa, että tätä tiedostoa koskeva sääntö toimii; se ei kerro mitään muista säännöistäsi, joten tarkista ne samalla tavalla yksi kerrallaan.
4. Tarkista symbolisiin linkkeihin liittyvä tapaus, jos käytät tällaisia polkuja. Jos sinulla on deny-säännöt poluille /tmp, /etc tai /var macOS:ssä tai /bin Linuxissa, toista näiden polkujen testi päivityksen jälkeen.
5. Tarkista ”!”-merkillä alkavat säännöt. Jos olet käyttänyt niitä, tarkista, että kukin on kirjoitettu tiedostoon, jossa sen on tarkoitus vaikuttaa.

Jos esto toimii, mutta Claude Code ei silti näe tarvitsemiasi tiedostoja, katso erillinen selitys: miksi Claude Code ei näe projektin tiedostoja.

Jos et voi päivittää juuri nyt#

Joskus päivitystä täytyy lykätä: et voi muuttaa ympäristöä, tietokone on yrityksen omistama tai sinun on saatava nykyinen tehtävä valmiiksi. Voit pienentää riskiä päivitykseen asti näin:

• kirjoita deny-säännöt polun molemmille nimille – sekä symboliselle linkille että todelliselle sijainnille (macOS:ssä todelliset polut ovat /private-hakemiston alla);
• älä yhdistä useita komentoja samalle riville ja vältä env -C- ja eval-rakenteita komennoissa, joita pyydät agenttia suorittamaan;
• älä näytä kenellekään komentojen /mcp, /plugin, claude mcp list tai claude mcp get tulostetta, ja vaihda MCP-asetustiedostojen avaimet, jotka ovat voineet joutua muiden käsiin;
• muista, että tee kiertää Edit-toiminnon deny-eston kirjoittaessaan – älä pidä tiedostoja suojattuina, jos Bash on sallittu.

Nämä toimet pienentävät tiettyjen ohitusten todennäköisyyttä, mutta ne eivät korvaa korjausta. Päivitä ja suorita edellisen osion testi heti, kun pystyt.

Yhteenveto#

Versiot 2.1.268 ja 2.1.269 korjasivat Claude Coden neljä käyttöoikeusongelmaa: symboliset linkit, env -C- ja eval-rakenteita sisältävät rivit, oman tiedostonsa ulkopuolella vaikuttavat ”!”-säännöt sekä tee-komennolla kirjoittamisen. Erikseen korjattiin salaisuuksien paljastuminen /mcp-tulosteessa ja tokenien näkyminen lisäosavirheissä. Tarkista versionumerosi, päivitä uusimpaan julkaisuun ja suorita yllä olevan osion testitiedostotesti. Estoviesti, jossa sääntösi mainitaan, osoittaa, että esto toimi tässä testissä. Pelkkä säännön olemassaolo asetuksissa ei riitä varmistamaan sen toimivuutta.

Voit jatkaa mallien käyttöä siirtymällä Ailootiin.