Pod koniec 2024 roku Apple zrobił coś nietypowego. Bez keynote'a, bez komunikatu prasowego, bez żadnej fanfary typowo towarzyszącej funkcjom platformy Apple, dostarczyli natywne wsparcie kontenerów Linux w macOS. Projekt został udostępniony jako open source na GitHub pod nazwą „container" — małymi literami, bez brandingu, bez marketingu. Po prostu binarny plik Swift, który uruchamia kontenery Linux kompatybilne z OCI na Apple Silicon z niemal natywną wydajnością.
Większość deweloperów nie zauważyła. Docker Desktop wciąż dominuje w historii kontenerów na macOS, a nieliczni, którzy zauważyli, założyli, że to wewnętrzne narzędzie, które wyciekło na zewnątrz. Ale dla każdego, kto buduje oprogramowanie wymagające lekkiej, bezpiecznej izolacji na macOS, Apple Container jest po cichu rewolucyjny — a NanoClaw był jednym z pierwszych projektów, które na nim zbudowały.
Dlaczego Docker nie wystarczał
Żeby zrozumieć, dlaczego Apple Container ma znaczenie dla agentów AI, trzeba zrozumieć, co Docker tak naprawdę robi na macOS. Docker Desktop nie uruchamia kontenerów natywnie — uruchamia maszynę wirtualną Linux, a potem uruchamia kontenery wewnątrz tej VM. Każdy kontener Docker na Twoim Macu tak naprawdę działa wewnątrz ukrytej VM Linux zarządzanej przez Docker Desktop. To działa, ale niesie ze sobą narzut: VM potrzebuje RAM-u (zwykle 2-4GB domyślnie), dodaje opóźnienie do każdej operacji kontenerowej i wymaga, by Docker Desktop działał jako usługa w tle.
Dla web dewelopera, który od czasu do czasu uruchamia kontener Postgres, ten narzut jest niewidoczny. Dla NanoClaw, który tworzy nowy kontener dla każdej tury rozmowy i niszczy go po zakończeniu odpowiedzi, narzut jest wąskim gardłem. Kontener, który startuje 2 sekundy z powodu narzutu VM, zamienia szybkiego asystenta AI w ociężałego. Użytkownicy zauważają, kiedy ich wiadomość WhatsApp trwa 3 sekundy dłużej niż powinna.
Apple Container eliminuje warstwę VM całkowicie. Używa Virtualization.framework od Apple do uruchamiania lekkiego jądra Linux bezpośrednio na sprzęcie, z kontenerami współdzielącymi to jądro zamiast uruchamiania każdego we własnej VM. Rezultat to czasy startu kontenerów mierzone w milisekundach zamiast sekund, narzut pamięci mierzony w megabajtach zamiast gigabajtów i wydajność I/O bliska natywnej.
Jak NanoClaw tego używa
Model kontenerowy NanoClaw jest prosty, ale przemyślany. Kiedy wiadomość przychodzi na WhatsApp, NanoClaw tworzy kontener z określonym zestawem montowań: kod źródłowy projektu (tylko do odczytu), plik pamięci CLAUDE.md grupy (do odczytu i zapisu) oraz zapisywalna przestrzeń robocza ograniczona do tej grupy. Klucz API jest przekazywany przez stdin jako ładunek JSON — nigdy nie dotyka systemu plików ani zmiennych środowiskowych wewnątrz kontenera.
Na macOS NanoClaw wykrywa Apple Container i używa go domyślnie. Na Linux przełącza się na Docker. Kod agenta wewnątrz kontenera jest identyczny w obu przypadkach — to sesja Claude Code z Agent SDK, działająca w środowisku Linux niezależnie od systemu operacyjnego hosta. Obraz kontenera zawiera Chromium i agent-browser do dostępu webowego, dając agentowi możliwość przeszukiwania internetu i przeglądania stron bez żadnej przeglądarki działającej na hoście.
Praktyczna różnica na macOS to szybkość. Czas tworzenia kontenera z Apple Container to około 200-400ms — wystarczająco szybko, by użytkownicy nie odczuwali żadnego opóźnienia poza normalnym czasem odpowiedzi AI. Z Docker Desktop ta sama operacja trwa 1,5-3 sekundy, co jest zauważalne. Przez dziesiątki wiadomości dziennie ta różnica kumuluje się w znacząco inne doświadczenie użytkownika.
Model bezpieczeństwa
Apple Container dziedziczy prymitywy bezpieczeństwa macOS w sposób, w jaki Docker Desktop nie może. Kontener działa pod frameworkiem sandbox Apple, co oznacza, że podlega tym samym politykom bezpieczeństwa co każda inna aplikacja macOS w sandboxie. Dostęp do plików poza jawnie zamontowanymi ścieżkami nie jest tylko odrzucany przez środowisko uruchomieniowe kontenera — jest odrzucany przez sam system operacyjny.
Ma to znaczenie dla agentów AI konkretnie z powodu prompt injection. Jeśli złośliwy prompt nakłoni agenta do próby odczytania ~/.ssh/id_rsa lub ~/Documents/tax-returns.pdf, próba kończy się niepowodzeniem na poziomie systemu operacyjnego, nie na poziomie aplikacji. Nie ma buga w kodzie walidacji montowań NanoClaw, który mógłby zostać wykorzystany do obejścia ograniczenia, bo ograniczenie jest wymuszane przez jądro macOS, nie przez NanoClaw.
Izolacja sieciowa jest równie ważna. Każdy kontener dostaje własną przestrzeń nazw sieciowych, co oznacza, że agent nie może skanować sieci lokalnej, nie może uzyskać dostępu do innych usług działających na localhost i nie może komunikować się z innymi kontenerami agentów. Jedyny dostęp sieciowy to wychodzący HTTPS do dostawcy AI i do stron, które agent przegląda. To znacząca obrona przed klasą ataków, w których skompromitowany agent próbuje przeskoczyć na inne usługi na tej samej maszynie.
Co to oznacza dla użytkowników Mac
Jeśli uruchamiasz NanoClaw na Macu — co jest najczęstszym wdrożeniem do użytku osobistego — Apple Container daje Ci izolację na poziomie Docker bez Docker Desktop. Żadnej VM w tle zjadającej 2-4GB RAM-u. Żadnej licencji Docker Desktop do zarządzania. Żadnego demona Docker, który musi działać, zanim NanoClaw może wystartować.
Konfiguracja jest minimalna. Skrypt bootstrap NanoClaw wykrywa macOS, sprawdza Apple Container i konfiguruje się automatycznie. Jeśli Apple Container nie jest zainstalowany, przełącza się na Docker. Jeśli żaden nie jest dostępny, działa bez izolacji kontenerowej (z ostrzeżeniem). Celem jest, by izolacja kontenerowa była domyślna, a nie opcjonalną funkcją wymagającą dodatkowej konfiguracji.
Dla zespołów oceniających NanoClaw do wdrożenia na mieszance maszyn macOS i Linux, abstrakcja kontenerowa oznacza, że ta sama konfiguracja działa wszędzie. Zachowanie agenta jest identyczne niezależnie od tego, czy izolację zapewnia Apple Container czy Docker. Jedyna różnica to wydajność — a w tej metryce Apple Container na Apple Silicon trudno pobić.
Apple nie zbudował Container dla agentów AI. Zbudowali go dla własnych wewnętrznych narzędzi i dla deweloperów potrzebujących lekkich środowisk Linux na macOS. Ale właściwości, które czynią go dobrym dla tych zastosowań — szybki start, niski narzut, silna izolacja, natywna wydajność — to dokładnie właściwości, których potrzebuje sandboxing agentów AI. Czasem najlepsze narzędzie do zadania to takie, które zostało zbudowane do zupełnie innego zadania.