Eind 2024 deed Apple iets ongebruikelijks. Zonder keynote, zonder persbericht, zonder de fanfare die doorgaans gepaard gaat met Apple-platformfeatures, leverden ze native Linux-containerondersteuning in macOS. Het project werd open-source op GitHub gezet onder de naam "container" — kleine letters, geen branding, geen marketing. Gewoon een Swift-binary die OCI-compatibele Linux-containers draait op Apple Silicon met bijna-native prestaties.
De meeste ontwikkelaars merkten het niet op. Docker Desktop domineert nog steeds het macOS-containerverhaal, en de weinigen die het wel opmerkten namen aan dat het een interne tool was die per ongeluk openbaar was geworden. Maar voor iedereen die software bouwt die lichtgewicht, veilige isolatie op macOS nodig heeft, is Apple Container stilletjes revolutionair — en NanoClaw was een van de eerste projecten die erop bouwde.
Waarom Docker niet genoeg was
Om te begrijpen waarom Apple Container belangrijk is voor AI-agents, moet je begrijpen wat Docker eigenlijk doet op macOS. Docker Desktop draait containers niet native — het draait een Linux virtuele machine, en draait vervolgens containers binnen die VM. Elke Docker-container op je Mac draait eigenlijk in een verborgen Linux-VM die beheerd wordt door Docker Desktop. Dit werkt, maar het brengt overhead met zich mee: de VM heeft RAM nodig (standaard 2-4GB), het voegt latentie toe aan elke containeroperatie, en het vereist dat Docker Desktop als achtergrondservice draait. Voor een webontwikkelaar die af en toe een Postgres-container opstart, is deze overhead onzichtbaar. Voor NanoClaw, dat een nieuwe container start voor elke gespreksturn en deze afbreekt wanneer het antwoord compleet is, is de overhead de bottleneck. Een container die 2 seconden nodig heeft om te starten vanwege VM-overhead maakt van een vlotte AI-assistent een trage. Gebruikers merken het wanneer hun WhatsApp-bericht 3 seconden langer duurt dan het zou moeten.
Apple Container elimineert de VM-laag volledig. Het gebruikt Apple's Virtualization.framework om een lichtgewicht Linux-kernel rechtstreeks op de hardware te draaien, waarbij containers die kernel delen in plaats van elk hun eigen VM te draaien. Het resultaat is opstarttijden van containers gemeten in milliseconden in plaats van seconden, geheugenoverhead gemeten in megabytes in plaats van gigabytes, en I/O-prestaties die dicht bij native liggen.
Hoe NanoClaw het gebruikt
NanoClaw's containermodel is eenvoudig maar doordacht. Wanneer een bericht binnenkomt op WhatsApp, start NanoClaw een container met een specifieke set mounts: de projectbroncode (read-only), het CLAUDE.md-geheugenbestand van de groep (read-write) en een beschrijfbare werkruimte afgebakend voor die groep. De API-key wordt via stdin als JSON-payload doorgegeven — deze raakt nooit het bestandssysteem of omgevingsvariabelen binnen de container.
Op macOS detecteert NanoClaw Apple Container en gebruikt het standaard. Op Linux valt het terug op Docker. De agentcode binnen de container is in beide gevallen identiek — het is een Claude Code-sessie met de Agent SDK, draaiend in een Linux-omgeving ongeacht het host-OS. De containerimage bevat Chromium en agent-browser voor webtoegang, waardoor de agent het web kan doorzoeken en pagina's kan bekijken zonder dat er een browser op de host draait.
Het praktische verschil op macOS is snelheid. De opstarttijd van containers met Apple Container is ruwweg 200-400ms — snel genoeg dat gebruikers geen vertraging waarnemen buiten de normale AI-responstijd. Met Docker Desktop duurt dezelfde operatie 1,5-3 seconden, wat merkbaar is. Over tientallen berichten per dag telt dat verschil op tot een wezenlijk andere gebruikerservaring.
Het beveiligingsmodel
Apple Container erft de beveiligingsprimitieven van macOS op manieren die Docker Desktop niet kan. De container draait onder Apple's sandbox-framework, wat betekent dat het onderworpen is aan dezelfde beveiligingsregels als elke andere gesandboxte macOS-applicatie. Bestandstoegang buiten de expliciet gemounte paden wordt niet alleen geweigerd door de container-runtime — het wordt geweigerd door het besturingssysteem zelf.
Dit is specifiek belangrijk voor AI-agents vanwege prompt-injection. Als een kwaadaardige prompt de agent ertoe verleidt ~/.ssh/id_rsa of ~/Documents/belastingaangiften.pdf te lezen, faalt de poging op OS-niveau, niet op applicatieniveau. Er is geen bug in NanoClaw's mount-validatiecode die misbruikt kan worden om de beperking te omzeilen, omdat de beperking wordt afgedwongen door de kernel van macOS, niet door NanoClaw.
De netwerkisolatie is even belangrijk. Elke container krijgt zijn eigen netwerknamespace, wat betekent dat een agent het lokale netwerk niet kan scannen, geen andere services op localhost kan benaderen en niet kan communiceren met andere agent-containers. De enige netwerktoegang is uitgaand HTTPS naar de AI-provider en naar websites die de agent bekijkt. Dit is een zinvolle verdediging tegen de klasse van aanvallen waarbij een gecompromitteerde agent probeert te pivotten naar andere services op dezelfde machine. ## Wat dit betekent voor Mac-gebruikers
Als je NanoClaw op een Mac draait — wat de meest voorkomende deployment is voor persoonlijk gebruik — geeft Apple Container je Docker-niveau isolatie zonder Docker Desktop. Geen achtergrond-VM die 2-4GB RAM opeet. Geen Docker Desktop-licentie om te beheren. Geen Docker-daemon die moet draaien voordat NanoClaw kan starten.
De setup is minimaal. NanoClaw's bootstrap-script detecteert macOS, controleert op Apple Container en configureert zichzelf automatisch. Als Apple Container niet geïnstalleerd is, valt het terug op Docker. Als geen van beide beschikbaar is, draait het zonder containerisolatie (met een waarschuwing). Het doel is dat containerisolatie de standaard is, niet een opt-in feature die extra setup vereist.
Voor teams die NanoClaw evalueren voor deployment op een mix van macOS- en Linux-machines, betekent de containerabstractie dat dezelfde configuratie overal werkt. Het agentgedrag is identiek ongeacht of Apple Container of Docker de isolatie levert. Het enige verschil is prestatie — en op die maatstaf is Apple Container op Apple Silicon moeilijk te verslaan.
Apple bouwde Container niet voor AI-agents. Ze bouwden het voor hun eigen interne tooling en voor ontwikkelaars die lichtgewicht Linux-omgevingen op macOS nodig hebben. Maar de eigenschappen die het goed maken voor die use cases — snelle opstart, lage overhead, sterke isolatie, native prestaties — zijn precies de eigenschappen die AI-agent-sandboxing nodig heeft. Soms is de beste tool voor een klus er een die voor een heel andere klus gebouwd is.