Claude Code sandboxen in 2026: stapsgewijze bestandssysteem- en netwerkisolatie

De sandbox van Claude Code is een grens die het besturingssysteem afdwingt rond de shell-commando's die Claude uitvoert, en die beperkt welke bestanden en netwerkhosts die commando's kunnen bereiken. Je schakelt hem in met /sandbox of door sandbox.enabled op true te zetten in een instellingenbestand, en zodra hij aanstaat kan Claude Code gesandboxte commando's uitvoeren zonder telkens te stoppen om je toestemming te vragen voor elk commando. Dat is de echte aantrekkingskracht: minder toestemmingsprompts zonder dat je een autonome agent een open shell op je laptop geeft.

Deze gids behandelt wat de sandbox daadwerkelijk beperkt, hoe je hem inschakelt op macOS, Linux en WSL2, de twee goedkeuringsmodi, en de onderdelen die buiten de grens draaien — het gat dat eerder dit jaar uitmondde in een echte data-exfiltratiebug. Wij draaien Claude Code in headless automatisering om deze site te publiceren, dus de shell-grens goed krijgen is voor ons geen theoretische kwestie.

Wat is de Claude Code-sandbox?

De sandbox is ingebouwd in Claude Code en omsluit elk Bash-, PowerShell- en Monitor-commando plus de onderliggende processen die die commando's starten. Hij trekt twee grenzen tegelijk: wat een commando op schijf mag aanraken, en wat het via het netwerk kan bereiken. Beide worden door het OS afgedwongen terwijl het commando draait, en daarom kan een gesandboxt commando automatisch worden goedgekeurd — het is de kernel die de grens bewaakt, niet een prompt.

Standaard staat hij uit. Op macOS gebruikt hij het ingebouwde Seatbelt-raamwerk, dus er valt niets te installeren. Op Linux en WSL2 steunt hij op bubblewrap voor bestandssysteemisolatie en op socat om netwerkverkeer via een lokale proxy door te sturen; het /sandbox-paneel vertelt je of een van beide ontbreekt. Op native Windows is er helemaal geen sandbox — commando's draaien ongesandboxt tenzij je Claude Code binnen een WSL2-distributie draait. Onder de motorkap draait het op het opensource-pakket @anthropic-ai/sandbox-runtime.

Hoe bestandssysteem- en netwerkisolatie werken

De twee grenzen hebben verschillende standaardinstellingen, en je verruimt of versmalt ze elk onafhankelijk. De tabel hieronder toont de begintoestand en de instellingen die daar verandering in brengen.

Toegang	Standaardgedrag	Wijzig je met
Schrijven	Werkmap, een tijdelijke map per gebruiker, en alle mappen die je hebt toegevoegd met --add-dir. Beschermde paden blijven schrijfvrij	filesystem.allowWrite, filesystem.denyWrite
Lezen	Vrijwel de hele machine — inclusief inlogbestanden zoals ~/.ssh en ~/.aws/credentials	filesystem.denyRead, credentials
Netwerk	Geen directe route naar buiten; elke verbinding loopt via een lokale proxy die de host controleert tegen je toegestane domeinen, die leeg beginnen	network.allowedDomains, network.deniedDomains

De asymmetrie die het waard is om te onthouden: schrijven zit standaard op slot, maar lezen staat wagenwijd open. Een gesandboxt commando kan niets buiten je project wegkrabbelen, maar het kan nog altijd je SSH-sleutels en cloud-credentials lezen tenzij je een denyRead-regel toevoegt of de credentials-bescherming gebruikt. Aan de netwerkkant is het precies omgekeerd — standaard weigeren, met een toegestane lijst die je opbouwt naarmate commando's specifieke hosts nodig hebben.

De Claude Code-sandbox inschakelen

De snelste weg is interactief:

• Voer /sandbox uit in een sessie. Het paneel heeft een Mode-tab, een Overrides-tab (de allowUnsandboxedCommands-terugval) en een Config-tab die de opgeloste instellingen toont. Op Linux verschijnt er een Dependencies-tab als bubblewrap, socat of ripgrep ontbreekt.
• Kies een modus (hieronder besproken) en vraag Claude om een build of testsuite te draaien. Het selecteren van een modus schrijft die weg naar de .claude/settings.local.json van het project.
• Schakel hem overal in door sandbox.enabled op true te zetten in ~/.claude/settings.json, of dwing hem voor een heel team af met beheerde instellingen.

Voor één enkele sessie zonder een instellingenbestand aan te raken, geef je hem mee op de CLI:

claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'

Om te verifiëren dat hij actief is, vraag je Claude om touch ~/sandbox-probe te draaien (zou moeten falen met Operation not permitted of Read-only file system) en curl --noproxy '*' https://example.com (zou moeten falen met Could not resolve host). Als je wilt dat de agent hard stopt wanneer de sandbox niet kan starten — in plaats van stilletjes terug te vallen op ongesandboxt — zet dan sandbox.failIfUnavailable op true. Die instelling is het verschil tussen "de sandbox is een gemak" en "de sandbox is een beveiligingspoort."

Sandbox-modi: auto-allow versus reguliere permissies

Beide modi dwingen exact dezelfde bestandssysteem- en netwerkgrenzen af. Het enige verschil is de goedkeuring.

• Auto-allow-modus draait gesandboxte commando's zonder prompt. Hier zit de winst tegen promptmoeheid: een commando dat alleen binnen de grens schrijft, draait gewoon, zelfs in handmatige modus. Weigerregels worden nog altijd gerespecteerd, rm tegen een kritiek pad vraagt nog steeds om toestemming, en op inhoud gerichte ask-regels zoals Bash(git push *) dwingen nog steeds een prompt af.
• Reguliere-permissiemodus stuurt elk Bash-commando door de normale permissiestroom, zelfs wanneer het gesandboxt is — meer controle, meer klikken.

De eerste keer dat een commando een nieuw netwerkdomein nodig heeft, vraagt Claude Code je om het aan de toegestane lijst toe te voegen. In auto-modus declareert het model in plaats daarvan de hosts die een commando nodig heeft op het commando zelf, en een classifier aan de serverkant beoordeelt ze. Let op: plan-modus erft auto-allow niet — die blijft commando's afschermen terwijl je plant.

Wat er buiten de sandbox draait (het stuk dat men over het hoofd ziet)

De sandbox omsluit shell-commando's. Hij omsluit niet alles, en dit is het meest misverstane eraan. Buiten de grens draaien:

• Ingebouwde bestands- en webtools — Read, Edit, Write, WebFetch, WebSearch volgen in plaats daarvan permissieregels. Een denyRead-vermelding houdt de Read-tool niet tegen, en allowedDomains beperkt WebFetch niet.
• MCP-servers en hooks — beide draaien ongesandboxt.
• Commando's die je intypt bij de !-shellprompt, alles wat overeenkomt met excludedCommands, en elke ongesandboxte poging opnieuw, waarbij Claude een mislukt commando opnieuw draait met dangerouslyDisableSandbox.

Dus een denyRead op ~/.aws/credentials blokkeert een gesandboxte cat, maar niet de Read-tool of een MCP-server die hetzelfde bestand bereikt. Als je één grens rond dat alles wilt, is de sandbox de verkeerde laag — draai dan het hele Claude Code-proces binnen een container of VM. Dit speelt het sterkst wanneer je Claude Code headless draait in CI, waar geen mens is om een ongesandboxte nieuwe poging te weigeren.

Een sandbox is geen cel: de les van de egress-bypass

Behandel de toegestane netwerklijst als verdediging-in-de-diepte, niet als een kluis. Beveiligingsonderzoekers maakten een netwerk-egress-bypass in de sandbox van Claude Code openbaar die versies 2.0.24 tot en met 2.1.89 trof — ruwweg 130 releases — waarbij een SOCKS5-nulbyte-hostnaamtruc commando's geblokkeerde domeinen liet bereiken en API-sleutels, tokens en broncode liet exfiltreren. Een geprepareerde hostnaam zoals attacker.com\x00.google.com kwam langs de allowlist-controle van JavaScript (die zag het .google.com-achtervoegsel), terwijl de OS-resolver bij de nulbyte afkapte en verbinding maakte met de aanvaller. Anthropic leverde strengere hostnaamvalidatie in v2.1.90 op 1 april 2026, naar verluidt zonder CVE of changelog-notitie.

De praktische conclusies: houd Claude Code bijgewerkt, houd allowedDomains zo kort als de taak toelaat, zet sandbox.failIfUnavailable waar de sandbox een echte controle is, en isoleer voor alles wat met productiegeheimen werkt het hele proces — niet alleen zijn shell. De sandbox verhoogt de kosten van een fout of een prompt-injectie betekenisvol, maar hij is één laag, en lagen hebben gaten gehad.

Veelgestelde vragen

Staat de Claude Code-sandbox standaard aan?

Nee. Hij staat uit totdat je /sandbox uitvoert of sandbox.enabled op true zet in een instellingenbestand. Op native Windows draait hij helemaal niet tenzij je WSL2 gebruikt.

Verhindert de sandbox dat Claude mijn credentials leest?

Niet standaard. Gesandboxte commando's kunnen vrijwel de hele machine lezen, inclusief ~/.ssh en ~/.aws/credentials. Voeg een filesystem.denyRead-regel toe of gebruik de credentials-bescherming, en onthoud dat de Read-tool en MCP-servers volledig buiten de sandbox vallen.

Wat moet ik installeren op Linux?

bubblewrap en socat zijn vereist; ripgrep wordt met de native binary meegeleverd, en een optioneel seccomp-filter (uit @anthropic-ai/sandbox-runtime) voegt Unix-socketblokkering toe. De Dependencies-tab van /sandbox toont wat er ontbreekt.

Zal de sandbox toestemmingsprompts verminderen?

Ja, in auto-allow-modus — gesandboxte commando's draaien zonder te vragen, omdat het OS de grens afdwingt. Weigerregels, rm op een kritiek pad, en op inhoud gerichte ask-regels vragen nog steeds om toestemming.

Is de sandbox genoeg om een agent veilig op productiegegevens te draaien?

Behandel hem als één laag. Hij beperkt shell-commando's, maar niet bestandstools, MCP-servers of hooks, en hij heeft ten minste één egress-bypass-bug gehad. Draai voor productiegeheimen het hele proces in een container of VM.

Bronnen

• Claude Code-documentatie — De gesandboxte Bash-tool configureren: wat de sandbox beperkt, instellingssleutels, modi, afhankelijkheden, en wat er buiten draait.
• GBHackers — Sandbox-fout in Claude Code kan gebruikersgeheimen compromitteren: de SOCKS5-nulbyte-egress-bypass, getroffen versies 2.0.24–2.1.89, en de fix in v2.1.90.
• anthropics/sandbox-runtime (GitHub): het opensource-pakket waarop de ingebouwde sandbox is gebouwd.