Przestrzeń sandbox dla Claude Code: Izolowane środowiska agentów na laptopie

Kiedy restart wymazuje pamięć roboczą

Załóżmy, że jednocześnie otwarte są sześć lub siedem sesji Claude Code. Kilka z nich działa w terminalach, kilka w VS Code, a jedna w IntelliJ – zespół pracuje bowiem w kilku językach, a każdy ma swój ulubiony edytor. Pracują one z różnymi repozytoriami, różnymi zadaniami oraz różnymi nieukończonymi pomysłami. Następnie laptop się restartuje.

Sam kod nie ma żadnych problemów. Strata dotyczy natomiast pozycji wszystkich elementów: która sesja była w trakcie refaktoryzacji, która czekała na kompilację, a która zawierała pytanie, którego odpowiedzi nigdy nikt nie przeczytał. Dwadzieścia minut trzeba poświęcić na odbudowę pamięci roboczej na podstawie historii shella oraz nieuporządkowanych gałęzi git. W tym momencie zły dzień zaczyna przypominać problem projektowy.

Restart był tylko najgłośniejszym objawem. Rzeczy psuły trzy oddzielne przyczyny konfliktów.

Mieszanie elementów. Uruchomienie agentów jest tanie, ale śledzenie ich kosztuje dużo zasobów. Każdy nowy wymaga kolejnej karty terminala, kolejnego okna edytora, kolejnego miejsca w pamięci. Laptop zamienia się w zbiór okien, a jedyną warstwą integracji jest człowiek. Istniejące narzędzia zakładają jeden agent, jedno zadanie i jedną osobę nadzorującą, co nie odpowiada rzeczywistości pracy.

Dylemat związany z uprawnieniami. Żadna z domyślnych ustawień nie rozwiązuje tego problemu. Claude Code wymaga zatwierdzenia dla każdego wywołania narzędzia, a mimo to może pytać o błahe kwestie, pozostając milczącym wobec wywołań, które mogą spowodować poważne szkody. Zachowanie systemu poprawiło się, ale podstawowy problem pozostał niezmieniony – agent działa jak ty i posiada twoje uprawnienia. Administrator organizacji na GitHubie nie może rozsądnie zatwierdzać każdego wywołania API, ani udawać, że pojedyncze zatwierdzenie jest bezpieczne.

Pozostają dwa rozwiązania. Możesz dalej dopracowywać listę dostępów, aż stanie się ona tak skomplikowana, że żaden kolega nie będzie w stanie jej odczytać, albo możesz włączyć opcję --dangerously-skip-permissions i polegać na szczęściu. Historie grozy pochodzą właśnie od tego drugiego rozwiązania, np. od przypadku, gdy agent chętnie usunął dane z bazy produkcyjnej. Oba rozwiązania zawodzą z jednego powodu: agent przenosi twoją tożsamość, a zatwierdzanie poleceń pojedynczo jest jedynym sposobem, by temu zaradzić.

Zmęczenie instalacjami. W różnych repozytoriach na różnych platformach brakuje JDK, jest niewłaściwy Node, ten SDK, tamta CLI oraz ustawiony pół roku temu pin wersji, którego nikt już nie potrafi wyjaśnić. Każda zmiana kontekstu wiąże się z kosztem w postaci minut spędzonych na obserwowaniu menedżera pakietów. Sytuacja pogarsza się, gdy laptop zostanie zgubiony lub zastąpiony, ponieważ każde środowisko trzeba odbudować narzędzie po narzędziu. Po miesiącach dostosowywania ulubionej CLI do programowania pozostaje otwarte pytanie, czy konfigurację w ogóle da się odtworzyć, czy też trzeba zaczynać od nowa, licząc na to, że zapamięta się najważniejsze elementy.

Swoja własna maszyna dla agenta

Początkowo nie był to projekt platformowy. Capsule stanowił narzędzie osobiste, stworzone po to, by ułatwić życie jednemu inżynierowi w ciągu tygodnia. Założenie było proste: dać agentowi własną maszynę, nie twoją, na której nie może on widzieć twojego systemu plików ani używać twoich danych dostępowych, a w której stwierdzenie „rób to, nie pytaj” nie jest lekkomyślne. Musiał też być na tyle tani, by kilka takich agentów mogło działać równocześnie bez żadnych problemów.

Kolleżanki i koledzy zauważyli to i poprosili o własne instancje, potem zrobili to także inni. Przekroczyło swoje początkowe granice jako narzędzie jednej osoby i teraz co rano otwiera się na ekranach coraz większej liczby inżynierów – od kilku wczesnych użytkowników do kilkudziesięciu, przy czym większość zespołu inżynieryjnego prawdopodobnie dołączy wkrótce. Nikt nie jest zmuszany do jego używania. Ludzie go przyjmują, ponieważ tydzień staje się łatwiejszy, co jest jedynym wiarygodnym wskaźnikiem przyjęcia. Nowy pracownik instaluje Capsule na laptopie i może od pierwszego dnia pracować w pełni samodzielnie.

W jednym zdaniu Capsule dostarcza Claude Code’owi odosobnionego, gotowego środowiska testowego, w którym może samodzielnie pracować nad twoimi repozytoriami, więc nie działa już z pełnym zestawem uprawnień.

Zdjęcie przedstawia stację Capsule Station. Kapsuły są wyświetlone wzdłuż lewej krawędzi, terminal wybranego agenta znajduje się pośrodku, a prośby o przeglądanie pull requestów, które należą do ciebie lub zostały ci przekazane, znajdują się w lewym dolnym rogu, co umożliwia jedno okno dla całej floty.

Jego zakres jest celowo wąski. To nie jest framework do orkiestracji agentów ani produkt wieloagentowy, przynajmniej na razie, chociaż wkrótce może pojawić się pewna forma orkiestracji. Nie jest to IDE, integracja z pluginami ani edytorem, a także nie tworzy odgałęzienia ani nie zastępuje Claude Code – to, co działa wewnątrz, to po prostu Claude Code skonfigurowany w określony sposób. Nie zastępuje on CI/CD, ani nie jest usługą SaaS, ponieważ wszystko odbywa się na twoim laptopie.

To ostatnie założenie okazało się ważniejsze, niż się spodziewano. Brak opłaty za każde miejsce oraz brak konieczności uruchamiania czegokolwiek oznaczają, że dziesiąta kapsuła kosztuje tyle samo co pierwsza, co przekształca pracę równoległą z luksusu w rutynę. Maszyna jest już opłacona, a repozytoria pozostają na sprzęcie, gdzie się znalazły.

Wewnątrz kapsuły Claude działa z flagą --dangerously-skip-permissions i nigdy nie pyta, czy może wykonać daną komendę. Jego jedyne pytania dotyczą intencji, czyli tego, co należy zrobić, a nie uprawnień. Taka rozsądna domyślna konfiguracja istnieje tylko dzięki dwóm podstawowym czynnikom.

Sandbox

Każda kapsuła działa jako pod w klastrze Kubernetes, który OrbStack już dostarcza na Macu. Dzięki temu wszystko pozostaje lokalne – bez dodatkowej infrastruktury i bez rachunków za chmurę. Do systemu plikowego hosta nie można uzyskać dostępu, a dwa zadeklarowane woluminy przechowują dane trwałe: przestrzeń roboczą oraz cache obrazów Dockera. Trzy warstwy kontrolują ruch wyjściowy:

• Zasady iptables jądra blokują bezpośrednie porty wyjściowe 80 i 443 dla identyfikatora użytkownika agenta.
• Polityka sieciowa Kubernetes ogranicza dostęp do DNS, portów 80 i 443.
• To, co przejdzie te blokady, trafia do proxya Squid, który stosuje wyraźną listę domen dozwolonych.

Lista ta obejmuje GitHub, npm, Maven, ECR oraz API Anthropic; wszystkie inne destynacje są domyślnie odrzucane. Agent nie ma łatwego sposobu na dotarcie do dowolnego punktu końcowego i przesłanie swojego kodu, a osiągnięcie tego wymagałoby dużej pomysłowości.

Trzy warstwy blokują dostęp, zanim cokolwiek zostanie wysłane: reguły jądra, następnie polityka sieciowa, a potem proxy z listą dopuszczalnych połączeń.

Udostępnienia o minimalnych uprawnieniach

Tutaj kryje się prawdziwa wartość. Autoryzacja odbywa się na hostzie pod twoim własnym nazwiskiem, z wszystkimi rolami, które zwykle posiadasz. Te role pozostają w kluczu macOS i nigdy nie trafiają do kapsuły. Zamiast tego host tworzy token o wąskim zakresie i krótkim czasie trwania oraz wprowadza go do systemu:

• tymczasowe uprawnienia AWS STS ograniczone do roli odczytu wyłącznie w środowisku produkcyjnym
• token GitHub, którego zakresy są weryfikowane przed jego wprowadzeniem
• konto usługowe BigQuery odczytu wyłącznie, które agent symuluje, dzięki czemu twoje własne dane nie są używane

Jeśli dostarczy się coś szerszego, np. rolę administracyjną typu SSO lub token z dodatkowymi uprawnieniami, host odrzuca jej użycie. Obrona jest standardem, a z wewnątrz agent nie ma możliwości ponownego uwierzytelnienia ani uzyskania szerszych uprawnień. Tożsamość zostaje zachowana, więc dziennik audytowy nadal przypisuje zapytanie tobie, ale to, co może zostać uszkodzone, ogranicza się do role i nie dotyczy ciebie.

Logujesz się na hostingu jako sam siebie, a agent otrzymuje jedynie wąski, krótkotrwały token wygenerowany na tej podstawie. To rozwiązanie umożliwia poprawne funkcjonowanie wszystkich elementów. Pozwolenie agentowi na działanie bez nadzoru nie opiera się na większym zaufaniu do niego, lecz na uczynieniu najgorszego scenariusza mniej problematycznym.

Usuwanie przeszkód

Bezpieczeństwo daje możliwość działania samodzielnie, ale nie zapewnia dobrej jakości użytkowania. Większość wysiłków poświęcono na usunięcie przeszkód.

Podstawowy obraz, z którego uruchamiają się kapsuły, zawiera już zamontowane wersje zestawów narzędzi: Go, Rust, Node, JDK, Maven, sbt oraz Scala. Obok niego działa sidecar typu Docker-in-Docker, który zapewnia każdej kapsule własny działający Docker, dzięki czemu testy integracyjne oraz zestawy Testcontainers wykonywają się bez wpływu na sąsiednie kapsuły. Czekają tam również narzędzia wiersza poleceń wymagające zalogowania, mianowicie GitHub CLI, AWS CLI, gcloud oraz bq. Od razu dostępne są również serwery językowe (Metals, jdtls, gopls, rust-analyzer, vtsls), które umożliwiają agentowi przemieszczanie się po kodzie za pomocą funkcji takich jak go-to-definition, find-references czy analiza hierarchii wywołań zamiast bezcelowego przeszukiwania.

Pamięci cache dla zależności są dzielone między kapsułkami za pośrednictwem wolumenu hosta. Może to wydawać się drobnym szczegółem, ale tak nie jest. W pierwszej wersji każde nowe środowisko pobierało wszystko od nowa, więc narzędzie, które zajmuje dwadzieścia minut na uruchomienie Mavena przed każdym zadaniem, nie zostałoby przyjęte. Teraz gotowa kapsułka jest dostępna w ciągu około dwudziestu do trzydziestu sekund.

Największy wpływ na zmianę zachowania agenta miała prawdziwa pętla zwrotna. Wewnątrz kapsuły działa wewnętrzna platforma CLI: sprawdza się token SSO hosta, ogranicza jego zakres i wstrzykuje go do systemu, co umożliwia agentowi stworzenie środowiska sandbox, wdrożenie właśnie skompilowanej gałęzi oraz przeprowadzenie testów wstępnych. W tym samym środowisku uruchamia się również narzędzie do testów integracyjnych, które pobiera rzeczywiste obrazy i uruchamia MySQL, Kafka oraz Cassandra w komórce sidecar. Początkowo jest to powolne, ponieważ obrazy przechodzą przez proxy, ale później system jest już gotowy do pracy. To właśnie odróżnia agenta, który generuje wiarygodny kod, od takiego, który potrafi sprawdzić, czy kod faktycznie działa.

Zintegrowana jest również funkcja wyszukiwania. Każda kapsuła rozpoczyna się od wewnętrznego bramy MCP, która tylko odczytuje dane i oferuje kilkadziesiąt narzędzi. Dostępne są tu logi z usług i kontenerów, metryki za pomocą PromQL i Thanos, panele Grafana, zdarzenia Kubernetes, status budów CI, informacje o osobach na dyżurze oraz aktywne alerty, dane dotyczące właścicieli usług, a także możliwość wyszukiwania w Confluence i Slack. Ponieważ nie można niczego zapisać, włączenie tej funkcji we wszystkich miejscach nie niosło żadnego ryzyka. Rynek wtyczek dodaje umiejętności związane z budową projektów Maven, tworzeniem szkieletów usług, zarządzaniem środowiskami testowymi oraz przeglądaniem zmian PR, dzięki czemu agent od pierwszej minuty zna standardy organizacji.

Oto nawyk wart przyjęcia. Utrzymuj prywatny repozytorium z osobistymi poleceniami typu slash oraz szablonami planów, a Capsule skopiuje je do każdego utworzonego środowiska. W ten sposób twój własny proces pracy podąża za tobą. Plany i informacje również przenoszą się między kapsułami za pośrednictwem tego repozytorium, a umiejętność przekazywania informacji pozwala zaznaczyć, gdzie zakończyła się sesja i zapisać jej podsumowanie, dzięki czemu następna kapsuła rozpoczyna pracę z kontekstem, a nie od zera. To zwykły repozytorium git, więc agent może również utrzymywać własne narzędzia – wystarczy jedno polecenie typu „dodaj polecenie build-and-test, zapisz je i wyślij”.

Lepiej przechowywać niż rozpoczynać

Pojawił się nieplanowany efekt. Gdy utworzenie izolowanego agenta staje się tanie, a każdy z nich przetrwa niezależnie od tego, czy ktoś go obserwuje, praca przestaje być wykonywana pojedynczo.

W typowym popołudniu cztery lub pięć kapsuł jest aktywnych. Jedna pracuje bez udziału człowieka nad naprawą błędu, druga to sesja SSH do prawdziwego programowania parami, trzecia ponownie uruchamia niestabilny test integracyjny i otwiera prośbę o połączenie repozytoriów, gdy ten się udaje, a czwarta zajmuje się aktualizacją zależności, której nikt nie chce obserwować. Około dziesięć innych pozostaje w stanie zatrzymanym: pomysł, do którego można wrócić, eksperyment, który nie powiódł się w ciekawy sposób, projekt częściowo przemyślany. Zatrzymanie chroni repozytoria, sesje i pamięć cache, a wznowienie zajmuje zaledwie kilka sekund, więc żaden pomysł nie jest porzucany tylko dlatego, że nie jest priorytetem dnia.

Najtrudniejsze nie było w ogóle rozpoczęcie pracy, lecz jej wstrzymanie. A gdy coś zostanie ukończone, kapsułę usuwa się – bez bałaganu w strukturze git worktree i bez konieczności sprzątania – a wszystkie produkty uboczne znikają razem.

Pełna autonomia eliminuje pozostałe utrudnienia. Nie ma żadnych prośb o zatwierdzenie dla poleceń git, nie trzeba przeglądać kart w przeglądarce w poszukiwaniu numeru na stronie CI ani przeszukiwać dziennika budowy w poszukiwaniu tej jednej ważnej linijki. Agent sam się tym zajmuje, a dzięki sandboxowi oraz tokenom o ograniczonym zakresie działania, to nie stanowi po prostu hazardu.

Cztery kapsuły, cztery stany – żadna z nich nie czeka na człowieka.

W jednym silniku dostępne są dwa tryby. Można pracować obok agenta w interaktywnej sesji tmux lub podać mu polecenie i zostawić go w spokoju.

To właśnie dlatego interfejs okazał się skuteczny. CLI jest potężne, ale ciągłe uruchamianie poleceń list, ssh i status w terminalu to żaden sposób na zarządzanie flotą. Capsule Station wypełnia tę lukę za pomocą jednego okna: kapsuły w pasku bocznym, wbudowany terminal dla każdej z nich oraz prośby o pull requesty i przeglądanie zmian obok. Przełączanie się między agentami przypomina przełączanie kart w przeglądarce. Aplikacja wykorzystuje Tauri, waży około dziesięciu megabajtów i opiera się na systemowym webview, ponieważ wyświetlanie listy nie powinno wymagać wbudowanego Chromium i gigabajta miejsca na dysku. Zwykle pozostaje otwarta przez cały dzień, podczas gdy IDE rzadko to robi.

Równie słuszne jest stwierdzenie, czego nie zmienia. Jakość generowanego kodu się nie poprawia. Znika natomiast cała praca związana z nim: przemieszczanie, zatwierdzanie, instalowanie, ponowna autoryzacja oraz tracenie poczucia miejsca w kodzie, co okazało się głównym źródłem trudności.

Dlaczego budować zamiast kupować

Opcje hostowane są rzeczywiste i coraz lepsze – np. pudełka testowe typu cloud agent od różnych dostawców oraz agenci działające zdalnie dla Ciebie. Nie stanowią one obciążenia operacyjnego i umożliwiają rzeczywiste skalowanie. Jednak kod i dane uwierzytelniające opuszczają Twoje zabezpieczenia, narzędzia są uniwersalne, co powoduje opóźnienia przy uruchamianiu dużych baz kodu, a wewnętrzny model tożsamości nie może być zrealizowany. Istnieją również projekty otwartego oprogramowania, takie jak pudełka testowe dostosowane do Kubernetes, narzędzia typu dev-container oraz lokalne mechanizmy pudełkowania dostarczane przez dostawców. Są one neutralne pod względem dostawcy i oparte na solidnych fundamentach, choć o niskim poziomie abstrakcji, co pozostawia Ci odpowiedzialność za obrazy, autoryzację oraz całe doświadczenie użytkownika. W przypadku każdej z opcji istnieje uzasadniona obawa, czy będzie ona nadal utrzymywana po sześciu miesiącach, ponieważ wszyscy uruchamiają nowe inicjatywy, a niewiele z nich przetrwa.

Budynek znajdował się pomiędzy nimi. Kapsuła składa się głównie z komponentów kompozytowych – DevPod zarządza kontenerem deweloperskim oraz cyklem życia podów, Squid zajmuje się wyjściami z sieci, klastr Kubernetes, który już dostarcza OrbStack, a także własny obraz przestrzeni roboczej, autoryzacja za pośrednictwem hosta oraz Station jako warstwa najwyższa. Zależność od tego rozwiązania jest niewielka, a poszczególne elementy można wymieniać. Pasuje to do bazy kodu oraz modelu autoryzacji, a kod pozostaje na laptopie, z wyjątkiem tego, co agent wysyła do API modelu, tak jak w przypadku każdej innej opcji.

Udostępnienia są tworzone na hostzie, natomiast wszystko, z czym ma kontakt agent, działa w podzie za proxyem z listą dopuszczalnych adresów.

Istnieje również argument dotyczący elastyczności, który okazał się ważniejszy, niż się spodziewano. Jeśli ktoś chce jakiejś funkcji, otwiera prośbę o integrację i omawia ją, a następnie funkcja zostaje wdrożona. Nikt nie spędza trzech tygodni z menedżerem produktu, tłumacząc, że może to trafić do planu na przyszły rok.

Ryzyko jest rzeczywiste i należy je wymienić: zespół za nie odpowiada, a w istocie jest to projekt jednej osoby z wsparciem firmy. Rozwój nigdy nie był tani, a koszty konserwacji pozostają prawdziwą niewiadomą. Nikt jeszcze nie ma na to odpowiedzi.

Co będzie dalej

Poprzede nas szersze wdrożenie od kilkudziesięciu użytkowników do całej organizacji, dodanie więcej umiejętności i narzędzi do obrazu oraz większa liczba integracji. Ten ostatni element jest trudniejszy, niż się wydaje, ponieważ każda z nich wymaga odpowiedzi na pytanie, co agent w trybie bezpytowym może z nią robić. Dostęp tylko do odczytu jest prosty, ale cokolwiek, co wymaga zapisu, wymaga poważnej dyskusji oraz sposobu na oznaczenie operacji niszczących. Działanie zdalne jest zdecydowanie najbardziej żądaną funkcją, więc kapsuły mogłyby działać nawet przy zamkniętym laptopie.

Ostrzeżenie dotyczące luk w bezpieczeństwie

System jest celowo defensywny, a jego budowa przynosi nieprzyjemną lekcję: narzędzie zapewniające agentom autonomię w największym stopniu polega na słabych punktach modelu bezpieczeństwa. Dobry kontroler dostępu ułatwia integrację, natomiast jego brak powoduje problemy od razu i pokazuje dokładnie dlaczego.

Mimo to sandbox ma swoje ograniczenia. Uruchamianie agenta z pełnymi uprawnieniami jest jak noszenie uzbrojonych broni, niezależnie od tego, czy zostanie użyta, czy nie. Capsule eliminuje te problemy. Wklej token administracyjny do czatu i poinstruuj agenta, aby go użył – wtedy uprawnienia są mu przywracane.

Zaczynaj budować

To niezwykłe czasy i trudno przecenić to, co jeden inżynier może stworzyć. Wszystko zaczęło się od irytacji jednej osoby w zwykłym popołudniu i przekształciło się w coś, co coraz więcej kolegów z pracy otwiera każdego ranka. Pozostają dwie warunki: musisz wiedzieć, jaki problem chcesz rozwiązać, oraz potrzebujesz wsparcia, ponieważ tokeny kosztują pieniądze i ktoś musi zgodzić się, że są tego warte. Gdy oba te warunki są spełnione, praca zmienia się na zawsze, więc znajdź problemy i je rozwiąż.