Claude Code oikeudet ja asetukset: näin päätät, mitä Claude saa tehdä

Ensimmäisen tunnin jälkeen Claude Coden kanssa moni huomaa painavansa Enteriä samoihin kyselyihin yhä uudestaan. Saako ajaa npm test? Saako muokata tiedostoa? Saako hakea sivun netistä? Kyselyt ovat hyödyllisiä, mutta kymmenennellä kerralla niitä ei enää lue.

Toinen ääripää on vielä huonompi: annetaan kaikki vapaaksi, ja jonain päivänä Claude ajaa komennon, jota et olisi halunnut. Tässä oppaassa käydään läpi, miten Claude Coden oikeudet oikeasti toimivat ja miten saat kyselyt vähemmiksi niin, että vaaralliset asiat pysyvät lukossa.

Mitä Claude Coden oikeudet ovat?

Claude Code päättää jokaisen työkalukutsun kohdalla, ajetaanko se suoraan, kysytäänkö sinulta vai estetäänkö se. Päätökseen vaikuttaa kolme kerrosta:

1. Permission mode eli oikeustila asettaa pohjan koko sessiolle.
2. Säännöt (allow, ask, deny) tarkentavat pohjaa työkalu- ja komentotasolla.
3. Sandbox rajaa käyttöjärjestelmän tasolla, mihin shell-komennot pääsevät käsiksi.

Yksi asia kannattaa sisäistää heti alkuun. Säännöt valvoo Claude Code, ei malli. CLAUDE.md-tiedostoon kirjoitettu "älä koskaan pushaa mainiin" ohjaa sitä, mitä Claude yrittää tehdä, mutta se ei muuta sitä, mitä Claude Code sallii. Jos jokin on oikeasti kiellettävä, siitä tehdään deny-sääntö.

Manual-tilassa lukeminen on helppoa ja muuttaminen vaatii luvan. Tiedostojen lukeminen työhakemiston sisällä ei kysy mitään. Bash-komennot kysyvät, paitsi pieni joukko valmiiksi hyväksyttyjä lukukomentoja. Tiedostojen muokkaus kysyy aina.

Kyselyssä on yleensä vaihtoehto "Yes, and don't ask again". Bash-komennolle tai WebFetch-domainille annettu pysyvä lupa tallentuu sääntönä tiedostoon .claude/settings.local.json repositorion juureen. Tiedoston muokkauslupa taas kestää vain session loppuun.

Ketjutetun komennon kohdalla Claude Code on fiksumpi kuin voisi luulla. Kun hyväksyt pysyvästi komennon git status && npm test, se tallentaa erillisen säännön jokaiselle luvan vaatineelle osalle, tässä tapauksessa komennolle npm test. Yhdestä ketjusta voi tallentua enintään viisi sääntöä.

Kyselyyn voi myös vastata kommentilla. Siirry vaihtoehtoon Yes tai No ja paina Tab, niin saat kentän, johon voi kirjoittaa Claudelle syyn. Kieltävä vastaus perusteluineen on usein nopeampi kuin uusi prompti: "No, käytä pnpm:ää eikä npm:ää" ohjaa Clauden suoraan oikeaan suuntaan.

Työhakemisto ja lisähakemistot

Lukuoikeudet ja sandboxin kirjoitusoikeudet koskevat työhakemistoa, eli kansiota, jossa käynnistit Clauden. Jos Clauden pitää päästä toiseen kansioon, esimerkiksi viereiseen jaettujen komponenttien repositorioon, sen voi lisätä käynnistyksessä lipulla --add-dir, session aikana komennolla /add-dir tai pysyvästi permissions.additionalDirectories-avaimella. Lisähakemisto antaa pääsyn tiedostoihin, mutta sen omat asetukset eivät tule mukaan.

Claude Code permission modet: kuusi tilaa

Tila määrää, mitä Claude saa tehdä kysymättä. Konfiguraatiossa tilat kirjoitetaan alla olevilla nimillä, mutta käyttöliittymässä default näkyy nimellä Manual.

Muutama tarkennus tilojen sisältöön:

acceptEdits hyväksyy tiedostomuokkausten lisäksi komennot mkdir, touch, rm, rmdir, mv, cp ja sed, kunhan polut ovat työhakemiston sisällä. Muut Bash-komennot kysyvät edelleen.

plan on tila, jossa Claude lukee, tutkii ja kirjoittaa suunnitelman mutta ei koske lähdekoodiin. Kun suunnitelma on valmis, voit hyväksyä sen, muokata sitä tai pyytää jatkamaan suunnittelua. Tästä enemmän plan moden oppaassa.

auto antaa erillisen luokittelijamallin tarkistaa toimenpiteet sinun puolestasi. Se estää esimerkiksi toimenpiteet, jotka menevät pyyntösi ohi tai näyttävät luetun sisällön ohjaamilta. Dokumentaatio sanoo itse suoraan, että auto mode vähentää kyselyitä mutta ei takaa turvallisuutta. Uusissa versioissa (v2.1.283 alkaen) auto on interaktiivisten terminaali- ja VS Code -sessioiden oletustila.

dontAsk on CI-tila. Kaikki, mikä muuten kysyisi, estetään suoraan, joten sessio ei koskaan jää odottamaan vastausta. Näin ajetaan Claudea skripteissä, ja siitä kerrotaan lisää headless-oppaassa.

bypassPermissions ohittaa kyselyt. Siitä on oma lukunsa alempana, koska sen kanssa kannattaa olla tarkka.

Miten tilaa vaihdetaan

Terminaalissa tila vaihtuu näppäimillä Shift+Tab. Tilarivillä näkyy aktiivinen tila, esimerkiksi ⏵⏵ accept edits on tai ⏸ plan mode on. Kierto menee Manualista acceptEditsiin ja siitä planiin. Auto tulee mukaan, kun se on käytettävissä.

Käynnistyksessä tilan voi antaa lipulla:

claude --permission-mode plan
claude --permission-mode acceptEdits

Pysyvän oletuksen saat permissions.defaultMode-avaimella. Tämä esimerkki käynnistää kaikki terminaalisessiot Manual-tilassa, kun se on tiedostossa ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

Tässä on yksi kompastuskivi. Jos kirjoitat "auto" tai "bypassPermissions" projektin .claude/settings.json- tai .claude/settings.local.json-tiedostoon, arvo ei tule voimaan. Repositorio ei siis voi omilla asetuksillaan avata itselleen laajimpia tiloja. Ne asetetaan omiin käyttäjäasetuksiin.

settings.json: mihin tiedostoon asetus kuuluu?

Claude Code lukee asetukset JSON-tiedostoista, ja tiedoston sijainti ratkaisee, ketä asetus koskee.

Kun sama avain on useassa paikassa, korkein taso voittaa. Järjestys ylhäältä alas:

1. Managed-asetukset
2. Komentorivin --settings
3. Paikallinen projekti (.claude/settings.local.json)
4. Jaettu projekti (.claude/settings.json)
5. Käyttäjä (~/.claude/settings.json)

Listat käyttäytyvät eri tavalla kuin yksittäiset arvot. Jos permissions.allow on määritelty kolmessa tiedostossa, Claude Code yhdistää listat eikä valitse yhtä. Jokainen taso voi siis lisätä sääntöjä poistamatta muiden sääntöjä.

Oikeuksissa pätee lisäksi oma periaatteensa: jos jokin taso kieltää työkalun, mikään muu taso ei voi sallia sitä. Käyttäjätason deny estää projektitason allow-säännön, ja toisin päin. Managed-tason deny-sääntöä ei kumoa edes komentorivin --allowedTools.

.claude/settings.local.json jää gitin ulkopuolelle, kun Claude Code luo sen itse: se lisää tiedoston globaaliin git excludes -tiedostoosi. Jos teet tiedoston käsin, lisää se itse .gitignore-tiedostoon.

Vielä yksi asia jaetusta projektitiedostosta. Sen permissions.allow-säännöt tulevat voimaan vasta, kun hyväksyt kansion workspace trust -ikkunassa. Ikkuna näyttää säännöt ennen hyväksyntää. Deny- ja ask-säännöt eivät tarvitse hyväksyntää, koska ne vain rajaavat.

Allow, ask ja deny: näin säännöt kirjoitetaan

Säännöt kirjoitetaan muodossa Työkalu tai Työkalu(tarkenne). Kolme listaa tekevät näin:

• allow: työkalu ajetaan kysymättä
• ask: Claude Code kysyy joka kerta
• deny: työkalu estetään

Säännöt käydään läpi järjestyksessä deny, ask, allow, ja ensimmäinen osuma ratkaisee. Tarkempi sääntö ei muuta järjestystä. Jos deny-listassa on Bash(aws *), se estää myös komennon aws s3 ls, vaikka allow-listassa olisi juuri se.

Sääntöjä voi katsoa ja muokata session aikana komennolla /permissions. Ikkuna näyttää kaikki säännöt ja sen tiedoston, josta kukin sääntö tulee.

Bash-säännöt ja tähti

Tähti * korvaa mitä tahansa tekstiä, myös välilyöntejä. Ilman tähteä sääntö osuu vain täsmälleen samaan komentoon.

Välilyönti ennen tähteä on osa sääntöä, ja se on tärkeämpi kuin miltä näyttää. Tähti kannattaa myös laittaa alikomennon jälkeen: Bash(git log *) sallii vain git log -komennot, kun taas Bash(git *) sallii kaikki git-komennot, myös git push --force.

Claude Code tuntee shellin erottimet. Sääntö Bash(npm test *) ei salli komentoa npm test && curl jotain.example, koska ketjun jokaisen osan on oltava sallittu.

Muut työkalut

Tiedostojen säännöt kirjoitetaan Read- ja Edit-työkaluille, ja polut noudattavat gitignore-syntaksia:

• Read(./.env): .env nykyisessä hakemistossa
• Read(./secrets/**): kaikki secrets-kansion alla
• Edit(/src/**/*.ts): polku suhteessa asetustiedoston sijaintiin, projektiasetuksissa projektin juureen
• Read(~/.zshrc): polku kotihakemistosta
• Read(//Users/nimi/salaiset/**): absoluuttinen polku, huomaa kaksi kauttaviivaa

Yksi kauttaviiva alussa ei siis tarkoita absoluuttista polkua. Se on helppo sekoittaa.

Verkkohauissa käytetään domain:-etuliitettä, esimerkiksi WebFetch(domain:docs.example.com). MCP-työkalut nimetään muodossa mcp__palvelin__työkalu, ja mcp__github__* sallii kaikki github-palvelimen työkalut. MCP-oppaassa kerrotaan, miten palvelimet otetaan käyttöön.

Esimerkki: tavallisen web-projektin settings.json

Tässä on lähtökohta Next.js-tyyppiselle projektille, jossa on npm-skriptit, git ja .env-tiedostoja. Tiedosto menee projektin .claude/settings.json-tiedostoon, jotta koko tiimi saa samat säännöt.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "WebFetch(domain:nextjs.org)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)",
      "Bash(curl *)"
    ]
  }
}

Mitä tämä tekee käytännössä:

• Testit, lint, build ja paikalliset git-komennot menevät läpi kysymättä. Näitä Claude ajaa eniten, ja juuri ne kyselyt turhauttavat.
• Push ja pakettien asennus kysyvät aina. Ask-sääntö pakottaa kyselyn jopa auto-tilassa.
• .env-tiedostot ovat kokonaan pois Clauden tiedostotyökaluilta. Read-deny estää samalla myös Edit- ja Write-työkalut samassa polussa.

Rivi $schema antaa editorissa automaattisen täydennyksen ja validoinnin. Dokumentaation mukaan skeema voi laahata uusimpien versioiden perässä, joten varoitus juuri julkaistusta avaimesta ei välttämättä tarkoita virhettä.

Omat poikkeuksesi, esimerkiksi Bash(docker compose *) omalla koneellasi, kuuluvat tiedostoon .claude/settings.local.json. Silloin ne eivät päädy tiimin committeihin.

Bash-sääntö ei ole tietoturvaraja

Tämä on koko aiheen tärkein yksityiskohta, ja sen ohittaa helposti. Bash-sääntö vertaa komennon tekstiä. Se ei vartioi ohjelmaa.

Deny-sääntö Bash(rm *) estää komennon rm -rf build/, mutta ei komentoa /bin/rm -rf build/ eikä komentoa bash -c 'rm -rf build/'. Sääntö Bash(git push *) ei pysäytä muotoa git -C . push origin main. Sama koskee yllä olevan esimerkin Bash(curl *)-sääntöä.

Read-deny toimii samalla tavalla rajatusti. Se koskee Clauden omia tiedostotyökaluja ja tunnettuja komentoja kuten cat, head ja tail. Python- tai Node-skripti, joka avaa tiedoston itse, ei näe sääntöä lainkaan.

Deny-säännöt ovat siis hyvä tapa estää ne komennot, joita Claude tavallisesti kirjoittaa. Jos tarvitset rajan, joka pitää komennon muodosta riippumatta, tarvitset sandboxin. Toinen vaihtoehto on PreToolUse-hook, joka tarkistaa komennon omalla logiikallasi. Hookeista kerrotaan hooks-oppaassa.

Myös .claudeignore-tiedostosta kannattaa tietää: dokumentaation mukaan sillä ei ole vaikutusta. Siirrä sen rivit itse Read-deny-säännöiksi.

Claude Code sandbox: käyttöjärjestelmän raja Bash-komennoille

Sandbox on käyttöjärjestelmän valvoma raja niille shell-komennoille, joita Claude ajaa, ja niiden käynnistämille prosesseille. Koska raja pätee komennon muodosta riippumatta, /bin/rm ja bash -c eivät pääse sen ohi.

Sandbox on oletuksena pois päältä. Sen saa päälle session sisällä komennolla:

/sandbox

Paneelissa valitaan tila:

• Auto-allow: sandboxissa ajetut komennot hyväksytään kysymättä. Deny-säännöt ja tarkat ask-säännöt kuten Bash(git push *) pätevät edelleen.
• Regular permissions: kaikki komennot käyvät normaalin kyselyn läpi, vaikka ne ajetaan sandboxissa.

macOS:llä sandbox käyttää järjestelmän omaa Seatbeltia. Linuxilla ja WSL2:ssa tarvitaan paketit bubblewrap ja socat. Natiivissa Windowsissa sandboxia ei ole, joten Windows-koneella Claude Code ajetaan WSL2:n sisällä, jos sandbox halutaan käyttöön. Tästä lisää Windows-oppaassa.

Mitä sandbox rajaa oletuksena

• Kirjoitus: vain työhakemisto, käyttäjän väliaikaishakemisto ja erikseen lisätyt hakemistot.
• Lukeminen: suurin osa koneesta, myös ~/.ssh ja ~/.aws/credentials. Tämä yllättää monet.
• Verkko: ei suoraa yhteyttä ulos. Yhteydet kulkevat koneella pyörivän välityspalvelimen kautta, ja sallittujen domainien lista on aluksi tyhjä. Kun komento tarvitsee uutta domainia, Claude Code kysyy.

Lukemisen rajaus kannattaa siis tehdä itse. Tämä esimerkki estää koko kotihakemiston lukemisen mutta sallii projektin, sallii kirjoituksen yhteen lisäkansioon ja esihyväksyy npm-rekisterin:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."],
      "allowWrite": ["/tmp/build"]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org"]
    }
  }
}

Tämä tiedosto kuuluu projektin .claude/settings.json-tiedostoon, koska piste . tarkoittaa projektiasetuksissa projektin juurta. Käyttäjäasetuksissa sama piste tarkoittaisi kansiota ~/.claude, ja projektin tiedostot jäisivät estetyiksi.

Huomaa, että sandboxin poluissa yksi kauttaviiva tarkoittaa absoluuttista polkua. Read- ja Edit-säännöissä absoluuttinen polku kirjoitetaan kahdella kauttaviivalla. Kaksi eri käytäntöä samassa tiedostossa, joten tarkkana.

Mitä sandbox ei kata

Sandbox rajaa vain shell-komentoja. Clauden omat tiedostotyökalut, WebFetch, hookit ja paikalliset MCP-palvelimet toimivat sen ulkopuolella ja noudattavat oikeussääntöjä. denyRead ei siis estä Read-työkalua, vaan siihen tarvitaan edelleen Read-deny-sääntö. Siksi esimerkin .env-säännöt kannattaa pitää, vaikka sandbox olisi päällä.

Jos jokin työkalu ei toimi sandboxissa, kuten docker, sen voi nostaa ulos:

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["docker compose *"]
  }
}

Ulos nostettu komento käy taas normaalin kyselyn läpi. Kun komento epäonnistuu sandboxissa, Claude voi pyytää lupaa ajaa sen sandboxin ulkopuolella. Tämän pakotien saa kiinni asetuksella "allowUnsandboxedCommands": false.

bypassPermissions: mitä se oikeasti tarkoittaa

--dangerously-skip-permissions on sama asia kuin --permission-mode bypassPermissions. Lipun nimi kertoo jo aika paljon. Tila ohittaa kyselyt ja turvatarkistukset, myös kirjoitukset suojattuihin polkuihin kuten .git ja .claude.

Muutama asia pysyy silti voimassa:

• Deny-säännöt estävät edelleen. Allow-säännöillä taas ei ole tässä tilassa merkitystä, koska kaikki on jo sallittu.
• Eksplisiittiset ask-säännöt kysyvät edelleen.
• Tunnistetut vaaralliset poistot kriittisistä poluista, kuten rm -rf ~, kysyvät tai estetään.
• Linuxilla ja macOS:llä Claude Code kieltäytyy käynnistymästä tässä tilassa root-käyttäjänä tai sudo:lla.

Dokumentaatio sanoo suoraan, että tilaa käytetään vain eristetyissä ympäristöissä kuten konteissa ja virtuaalikoneissa, mieluiten ilman internetyhteyttä. Tila ei suojaa prompt injectionilta. Jos luet Claudella netistä sisältöä ja ajat samalla kaiken kysymättä omalla koneellasi, mikään ei ole välissä.

Jos haluat vähemmän kyselyitä tavallisessa kehityksessä, järkevämmät vaihtoehdot ovat sandbox auto-allow-tilassa, hyvin kirjoitetut allow-säännöt tai auto mode. Organisaatio voi estää koko tilan asettamalla permissions.disableBypassPermissionsMode-avaimen arvoon "disable". Saman voi tehdä myös omiin käyttäjäasetuksiinsa, jos haluaa lukita itsensä ulos.

Mistä kannattaa aloittaa?

Jos et ole koskaan koskenut Claude Coden oikeuksiin, tämä järjestys toimii:

1. Katso, mitä sinulla jo on. Aja /permissions. Siellä näkyvät kaikki "don't ask again" -vastauksilla tallentuneet säännöt. Siivoa liian laajat pois.
2. Kirjoita projektiin .claude/settings.json. Salli komennot, joita Claude ajaa joka päivä: testit, lint, build ja paikallinen git. Laita push ja asennukset ask-listaan.
3. Estä salaisuudet. Lisää Read(./.env), Read(./.env.*) ja muut salaisuuspolut deny-listaan.
4. Kokeile sandboxia. Aja /sandbox, valitse auto-allow ja katso, mitkä komennot alkavat kysyä verkkoyhteyttä. Lisää ne allowedDomains-listaan.
5. Vaihda tilaa tehtävän mukaan. Uuteen koodiin plan, tuttuun muutokseen acceptEdits, ja Shift+Tab on aina käden ulottuvilla.

Kun oikeudet ovat kunnossa, rinnakkaiset sessiot ja automaatio ovat paljon turvallisempia. Samat säännöt pätevät, kun ajat Claudea git worktreen kautta useana rinnakkaisena istuntona tai CI-putkessa ilman ihmistä. Yleisemmin tekoälyn kanssa koodaamisen riskeistä kerrotaan tietoturvaoppaassa.

Muut Claude Coden asetuksiin ja laajentamiseen liittyvät artikkelit on listattu Claude Code -oppaiden sivulla.