Sandboksy dla agentów: container-use, E2B, Daytona, microVM i Docker

Sandboks agenta to jednorazowa maszyna, w której działa agent kodujący, na przykład Claude Code albo Codex, dzięki czemu uruchomienie bez nadzoru może zrobić cokolwiek, nie sięgając do twojego laptopa, poświadczeń ani produkcji. Opcje różnią się izolacją: opakowanie na poziomie systemu (sandbox runtime Claude Code), kontenery (container-use, Modal), microVM (E2B, Docker Sandboxes) oraz platformy zarządzane albo hostowane u siebie (Daytona, Coder).

Ta strona jest dla developera, który chce, żeby agent pracował godzinę bez pytań o zgodę, i dla tech leada, który musi zdecydować, gdzie wolno to robić. Wypróbowałeś tryb auto, a potem ktoś w zespole puścił claude -p --dangerously-skip-permissions na laptopie, z produkcyjnym .env w repozytorium. Pytanie brzmi teraz: który sandboks sprawi, że następne uruchomienie będzie bezpieczne z definicji, i jak jego wynik wróci do review.

Co daje ci ten katalog sandboksów

• Tabelę decyzyjną i datowane porównanie siedmiu sandboksów: izolacja, start, czas życia, kontrola sieci i cena.
• Działający przykład: Claude Code w trybie headless w E2B, z cookbooka E2B, oraz Codex.
• Workflow: pętla bez nadzoru w jednorazowej maszynie, której gałąź wraca jako git bundle do review.
• Trzy prompty do skopiowania, pułapki i typowe awarie.

Wzorzec stojący za tym wszystkim (osobny stos dla każdego zadania, z danymi startowymi, własnymi portami i poświadczeniami) opisuje strona o efemerycznych środowiskach. Tryby zatwierdzania i sandboksy systemowe wbudowane w każdego agenta opisuje strona o uprawnieniach i sandboksach.

Jaki sandboks dla agenta wybrać?

Zacznij od tego, gdzie działa uruchomienie i kto jest właścicielem maszyny.

Twoja sytuacja	Wybierz	Dlaczego
Jeden developer, kilku agentów, laptop	Docker Sandboxes (sbx) albo container-use	microVM (Docker) albo kontener (container-use) na agenta, każdy na własnym klonie lub gałęzi; lokalnie za darmo
Uruchomienia bez nadzoru tylko Claude Code, bez Dockera	Sandbox runtime Claude Code (@anthropic-ai/sandbox-runtime)	Zamyka cały proces Claude Code, razem z hookami i serwerami MCP, w Seatbelt albo bubblewrap
Uruchomienia agentów startowane przez CI, kolejkę albo twój produkt	E2B, Modal albo Daytona	Sandboksy tworzone z SDK, z kontrolą ruchu wychodzącego na sandboks i czasem życia ustawianym w kodzie
Kod i poświadczenia do modeli muszą zostać na twojej infrastrukturze	Coder	Własne workspace’y w Terraformie; Coder Agents działa „bez kluczy API w workspace’ach”
Interfejs webowy albo mobilny nad agentami w sandboksach	CloudCLI sandbox (eksperymentalne)	Opakowuje Docker Sandboxes w interfejs CloudCLI
Zadania w tle startowane ze zgłoszenia albo czatu, bez własnej infrastruktury	Środowiska chmurowe samych dostawców	Opisane w efemerycznych środowiskach, nie tutaj

Worktree celowo nie ma na tej liście. Izoluje tylko pliki; porty, bazy danych, nazwy kontenerów Dockera i każde poświadczenie w twojej powłoce pozostają wspólne (zobacz stronę o równoległych agentach).

Jak sandboksy wypadają pod względem izolacji, startu, czasu życia i ceny?

Poniższe fakty sprawdziliśmy 2026-09-26 w README każdego projektu, w definicjach typów SDK albo w źródłach dokumentacji na GitHubie. Strony E2B, Modala i Daytony były tego dnia nieosiągalne z naszego środowiska, więc nie ma tu ani jednej ceny ani czasu startu z tych stron.

Sandboks	Model izolacji	Gdzie działa	Co wpływa na start	Domyślny czas życia	Kontrola sieci	Cena
Sandbox runtime Claude Code (npm @anthropic-ai/sandbox-runtime 0.0.77, beta research preview)	Mechanizmy systemu operacyjnego obejmujące cały proces: sandbox-exec (Seatbelt) na macOS, bubblewrap na Linuksie i Windows w wersji alfa (konto srt-sandbox plus filtr ruchu wychodzącego WFP) w wersji 0.0.77	Twoja maszyna	Nie ma czego uruchamiać; opakowuje istniejący proces	Czas życia procesu	Domyślnie blokuje sieć; domeny dopuszczasz w ~/.srt-settings.json	Darmowa paczka npm
container-use (Dagger, Apache-2.0, „experimental”)	Świeży kontener na agenta, każdy na własnej gałęzi gita	Twoja maszyna, przez Daggera	Budowa obrazu przy pierwszym użyciu	Do merge, apply albo odrzucenia środowiska	README tego nie opisuje	Darmowe, open source
Docker Sandboxes (CLI sbx)	microVM na sandboks z własnym demonem Dockera, systemem plików i siecią	Twoja maszyna albo chmura Dockera	Pierwsze uruchomienie pobiera obraz agenta; według Dockera kolejne „startują w kilka sekund”	Zostaje po wyjściu agenta, aż do sbx rm	Globalne presety Open, Balanced albo Locked Down oraz sbx policy allow network <host>	CLI i lokalne zasoby za darmo, także komercyjnie; chmura płatna za faktyczne zużycie (pay-as-you-go)
E2B (npm e2b 2.51.0)	Jedna microVM Firecracker na sandboks, z własną cgroup i przestrzenią nazw sieci	E2B Cloud albo własny hosting z e2b-dev/infra	Start albo wznowienie ze snapshotu szablonu, który budujesz raz	300 s, chyba że ustawisz timeoutMs; maksymalnie 1 godzina w planie Hobby i 24 godziny w Pro (dokumentacja SDK)	network.allowOut i denyOut (hosty, adresy IP, CIDR) albo allowInternetAccess: false	Plany (Hobby, Pro); ceny niesprawdzone
Modal Sandboxes (PyPI modal 1.5.5)	Kontener tworzony na żądanie przez modal.Sandbox.create	Chmura Modala	Budowa zdefiniowanego przez ciebie modal.Image	Domyślnie timeout=300 sekund	block_network=True, outbound_domain_allowlist, outbound_cidr_allowlist	Niesprawdzona
Daytona (PyPI daytona, npm @daytona/sdk 0.218.0)	Hostowane sandboksy tworzone przez SDK	Usługa hostowana Daytony	Tworzenie ze snapshotu	Zatrzymuje się po 15 minutach bezczynności; automatyczne usuwanie jest wyłączone, dopóki go nie ustawisz	network_block_all, domain_allow_list, network_allow_list	Niesprawdzona
Coder (AGPL-3.0; płatny plan Premium)	Workspace’y definiowane w Terraformie	Twoja infrastruktura	Twój szablon Terraform	Ustalany przez twoje szablony	Konfigurujesz sam	Rdzeń open source; Premium płatny

Repozytorium open source Daytony mówi: „This repository is no longer maintained. As of June 2026, Daytona’s core development has moved to a private codebase.” Usługa hostowana i SDK działają dalej (obie paczki wydały wersję 0.218.0 2026-09-25). Sandboks CloudCLI jest oznaczony jako eksperymentalny i wymaga CLI sbx Dockera; zarządzana chmura CloudCLI zaczyna się od 7 € miesięcznie, niezależnie od subskrypcji modelu.

Popularność na 2026-09-26 (gwiazdki na GitHubie odczytane tego dnia przez API GitHuba): Daytona 71 717 (repozytorium zamrożone), Coder 16 696, E2B 13 971, CloudCLI 13 811, container-use 4046 i modal-labs/modal-client 518 (tylko repozytorium SDK). Gwiazdki mierzą zainteresowanie, a nie dopasowanie do twojego modelu zagrożeń.

Zmierz czas startu sam

Zmierz własny szablon: owiń Sandbox.create(...) (E2B), modal.Sandbox.create(...) albo daytona.create() pomiarem czasu, uruchom dziesięć razy i zapisz medianę obok rozmiaru obrazu. Największą dźwignią, na którą masz wpływ, jest szablon, który instaluje zależności przy budowie, a nie przy uruchomieniu.

Uruchom Claude Code w trybie headless w sandboksie E2B

To przykład z cookbooka E2B (e2b-dev/e2b-cookbook, examples/anthropic-claude-code-in-sandbox-js), sprawdzony 2026-09-26. Buduje szablon raz, potem wykonuje jeden prompt Claude Code w sandboksie i go niszczy.

1. Zainstaluj SDK i narzędzie do uruchamiania, a oba klucze wyeksportuj z menedżera sekretów (nigdy nie wklejaj ich do pliku):

   npm install e2b dotenv
   npm install -D tsx
   export E2B_API_KEY ANTHROPIC_API_KEY   # wartości pochodzą z menedżera sekretów

2. Zdefiniuj szablon. Cookbook nazywa go anthropic-claude-code; nazwę wybierasz sam i nie jest to gotowy szablon E2B:

   src/template.ts

   import { Template } from "e2b";
   
   export const templateName = "anthropic-claude-code";
   
   export const template = Template()
     .fromNodeImage("24")
     .npmInstall(["@anthropic-ai/claude-code"], { g: true });

3. Zbuduj go raz. Cookbook używa jednego vCPU i 1024 MB pamięci:

   src/build.prod.ts

   import "dotenv/config";
   import { Template, defaultBuildLogger } from "e2b";
   import { template, templateName } from "./template";
   
   await Template.build(template, {
     alias: templateName,
     cpuCount: 1,
     memoryMB: 1024,
     onBuildLogs: defaultBuildLogger(),
   });

   npx tsx src/build.prod.ts

4. Wykonaj prompt. timeoutMs: 0 przy poleceniu wyłącza limit czasu tego polecenia, bo uruchomienie Claude Code może trwać długo:

   src/index.ts

   import "dotenv/config";
   import { Sandbox } from "e2b";
   import { templateName } from "./template";
   
   const sbx = await Sandbox.create(templateName, {
     envs: { ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY! },
     // Tego nie ma w cookbooku: blokuj ruch wychodzący poza API modelu.
     network: { allowOut: ["api.anthropic.com"], denyOut: ["0.0.0.0/0"] },
   });
   console.log("Sandbox created", sbx.sandboxId);
   
   const result = await sbx.commands.run(
     `echo 'Create a hello world index.html' | claude -p --dangerously-skip-permissions`,
     { timeoutMs: 0 },
   );
   console.log(result.stdout);
   
   await sbx.kill();

   npx tsx src/index.ts

Zobaczysz Sandbox created z identyfikatorem, a potem końcową wiadomość Claude Code opisującą zapisany index.html. Plik istnieje tylko wewnątrz microVM, sbx.kill() ją niszczy i nic do ciebie nie wraca. Następna sekcja zamienia go w pętlę, której wynik możesz przejrzeć.

Gdzie --dangerously-skip-permissions jest dopuszczalne

Używaj tej flagi tylko w jednorazowym sandboksie z ograniczonym ruchem wychodzącym i bez produkcyjnych poświadczeń. Samo --help Claude Code (v2.1.283) zaleca ją „only for sandboxes with no internet access”, a Claude Code odmawia jej użycia jako root albo przez sudo na Linuksie i macOS poza rozpoznanym sandboksem. Sam cookbook dopuszcza cały ruch wychodzący; krok 4 dodaje pominiętą w nim regułę.

Jak bezpiecznie puścić —dangerously-skip-permissions i nadal przejrzeć wynik?

Pętla ma pięć etapów, a sandboks jest tylko jednym z nich: specyfikacja → praca w jednorazowej maszynie → weryfikacja przez harness, nie przez agenta → zwrot gałęzi → review i merge. Agent nigdy nie dostaje tokenu GitHuba i nigdy nie robi pusha. Twój harness przenosi kod do środka i na zewnątrz jako git bundle, więc jedyne połączenia wychodzące sandboksa to API modelu i rejestr paczek.

1. Specyfikacja. Zapisz zadanie jako plik z kryteriami akceptacji, które harness potrafi sprawdzić (polecenie testowe, które musi przejść). Agent, któremu powiesz „zrób, żeby działało”, ogłosi sukces; agenta, któremu powiesz „npm test -- src/billing musi przejść i żaden plik poza src/billing/ nie może się zmienić”, da się z tego rozliczyć. Zobacz, jak pisać kryteria akceptacji, z których da się rozliczyć agenta.

2. Praca w jednorazowej maszynie. Utwórz sandboks z zablokowanym ruchem wychodzącym poza hostami potrzebnymi do uruchomienia, wgraj repozytorium jako bundle i puść agenta bez nadzoru.

3. Weryfikacja przez harness. Po zakończeniu pracy agenta harness sam uruchamia polecenie akceptacyjne i zapisuje kod wyjścia. „Wszystkie testy przechodzą” z ust agenta nie jest dowodem.

4. Zwrot gałęzi. Harness pakuje commity agenta w bundle i go pobiera. Z wnętrza sandboksa nic nie jest pushowane.

5. Review i merge. Pobierasz bundle do lokalnej gałęzi, pushujesz ją i otwierasz pull request. CI, bot do code review i człowiek widzą go jak każdą inną zmianę.

Ten harness realizuje etapy od 2 do 4 dla Claude Code na E2B i korzysta z szablonu z cookbooka. Uruchamiasz go z katalogu głównego repozytorium:

scripts/sandbox-task.ts

import { execFileSync } from "node:child_process";
import { readFileSync, writeFileSync } from "node:fs";
import { Sandbox } from "e2b";

const [taskFile, branch, acceptance] = process.argv.slice(2); // np. task.md agent/billing "npm test -- src/billing"
const git = (...args: string[]) => execFileSync("git", args, { encoding: "utf8" }).trim();

const base = git("rev-parse", "HEAD");
git("bundle", "create", "/tmp/in.bundle", "HEAD");

const sbx = await Sandbox.create("anthropic-claude-code", {
  timeoutMs: 60 * 60 * 1000, // godzina, maksimum w planie Hobby
  envs: { ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY! },
  network: {
    allowOut: ["api.anthropic.com", "registry.npmjs.org"],
    denyOut: ["0.0.0.0/0"],
  },
});

try {
  const sh = (cmd: string) => sbx.commands.run(cmd, { cwd: "/tmp/work", timeoutMs: 0 });
  await sbx.commands.run("git --version && mkdir -p /tmp/work");
  await sbx.files.write("/tmp/in.bundle", new Blob([readFileSync("/tmp/in.bundle")]));
  await sbx.files.write("/tmp/task.md", readFileSync(taskFile, "utf8"));
  await sh(`git clone -q /tmp/in.bundle . && git checkout -q -b ${branch}`);
  await sh(`git config user.email agent@sandbox.invalid && git config user.name sandbox-agent`);
  await sh("npm ci");

  // Etap 2: pętla bez nadzoru. Bezpieczna tylko dzięki regułom ruchu wychodzącego powyżej.
  const run = await sh("claude -p --dangerously-skip-permissions --max-budget-usd 5 < /tmp/task.md").catch((e) => e);
  console.log(`agent exit code: ${run.exitCode}`);

  // Etap 3: test akceptacyjny uruchamia harness, nie agent.
  const check = await sh(acceptance).catch((e) => e);
  console.log(`acceptance exit code: ${check.exitCode}`);

  // Etap 4: zacommituj resztki i spakuj w bundle tylko nowe commity.
  await sh(`git add -A && (git diff --cached --quiet || git commit -qm "agent: ${branch}")`);
  await sh(`git bundle create /tmp/out.bundle ${branch} ^${base}`);
  writeFileSync("/tmp/out.bundle", await sbx.files.read("/tmp/out.bundle", { format: "bytes" }));
} finally {
  await sbx.kill();
}

Potem na swojej maszynie:

npx tsx scripts/sandbox-task.ts task.md agent/billing "npm test -- src/billing"
git fetch /tmp/out.bundle agent/billing:agent/billing
git diff --stat HEAD...agent/billing       # najpierw sprawdź zakres zmian
git push -u origin agent/billing            # dalej przejmują CI i review

commands.run rzuca wyjątek, gdy polecenie kończy się kodem różnym od zera, dlatego krok akceptacyjny łapie błąd i czyta z niego exitCode. Nieudany test akceptacyjny i tak zwraca gałąź, więc widzisz, co agent próbował zrobić; kod wyjścia mówi recenzentowi, żeby tego nie mergować. Przenoszenie bundli w obie strony przetestowaliśmy gitem 2026-09-26, a wywołania E2B są zgodne z definicjami typów SDK 2.51.0; zanim zaufasz harnessowi, puść go raz na zadaniu do wyrzucenia.

Ta sama pętla z Codeksem albo Cursorem

Zmienia się tylko instalacja agenta i polecenie uruchomienia bez nadzoru.

Claude Code

Szablon: .npmInstall(["@anthropic-ai/claude-code"], { g: true }). Dopuść api.anthropic.com. Polecenie:

claude -p --dangerously-skip-permissions --max-budget-usd 5 < /tmp/task.md

--max-budget-usd ogranicza wydatki na API w tym uruchomieniu (--help Claude Code v2.1.283).

Codex

Szablon: .npmInstall(["@openai/codex"], { g: true }). Przekaż OPENAI_API_KEY w envs i dopuść api.openai.com (host domyślnego dostawcy OpenAI przy logowaniu kluczem API; własny dostawca wymaga hosta z base_url w jego wpisie model_providers). Polecenie (flagi sprawdzone w codex exec --help, codex-cli 0.157.1):

printenv OPENAI_API_KEY | codex login --with-api-key
codex exec --dangerously-bypass-approvals-and-sandbox - < /tmp/task.md

Pomoc mówi, że flaga obejścia jest „intended solely for running in environments that are externally sandboxed”, a tym właśnie jest microVM. Z - polecenie codex exec czyta prompt ze standardowego wejścia.

Cursor

Strona Dockera o agencie Cursora podaje, że plik wykonywalny agenta CLI to cursor-agent (sbx run cursor uruchamia cursor-agent --yolo). Jego skrypt instalacyjny jest hostowany na cursor.com, którego nie mogliśmy sprawdzić 2026-09-26, więc nie pokazujemy szablonu E2B. W chmurze Cloud Agents Cursora działają w maszynie wirtualnej dostawcy, co opisują efemeryczne środowiska.

Skonfiguruj każdy sandboks z Claude Code, Codeksem i Cursorem

container-use: kontener i gałąź na agenta

container-use to serwer MCP, więc to agent tworzy środowiska i z nich korzysta przez swoje narzędzia. Najpierw zainstaluj binarkę (nie ma jej w npm ani PyPI):

brew install dagger/tap/container-use
# albo na dowolnej platformie
curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bash

Claude Code

cd /path/to/repository
claude mcp add container-use -- container-use stdio
curl https://raw.githubusercontent.com/dagger/container-use/main/rules/agent.md >> CLAUDE.md

Codex

codex mcp add container-use -- container-use stdio
mkdir -p ~/.codex
curl https://raw.githubusercontent.com/dagger/container-use/main/rules/agent.md >> ~/.codex/AGENTS.md

Przewodnik container-use pokazuje równoważny blok [mcp_servers.container-use] w ~/.codex/config.toml z command = "container-use" i args = ["stdio"].

Cursor

Dodaj serwer do .cursor/mcp.json, a potem plik reguł dla Cursora:

.cursor/mcp.json

{
  "mcpServers": {
    "container-use": { "command": "container-use", "args": ["stdio"] }
  }
}

curl --create-dirs -o .cursor/rules/container-use.mdc https://raw.githubusercontent.com/dagger/container-use/main/rules/cursor.mdc

Daj agentowi prawdziwe zadanie, na przykład „Create a Flask hello-world app in Python.”. Twoje drzewo robocze się nie zmienia; agent zwraca adres aplikacji i identyfikator środowiska, na przykład fancy-mallard. Przegląd i decyzję robisz w terminalu:

container-use list                 # wszystkie środowiska
container-use diff fancy-mallard   # co agent zmienił
container-use log fancy-mallard    # każde polecenie, które wykonał
container-use merge fancy-mallard  # zachowaj jego commity albo: container-use apply fancy-mallard, żeby dodać je do indeksu (stage)

Koszt kontekstu. container-use dodaje narzędzia MCP do każdej sesji; lista --allowedTools w jego quickstarcie wymienia ich dziesięć. Uruchom /context w Claude Code przed rejestracją serwera i po niej, żeby zobaczyć, ile kosztuje cię to okna kontekstu.

Docker Sandboxes: microVM na agenta na twojej maszynie

Zainstaluj sbx (macOS 14+ na Apple silicon, Windows 11 z Hypervisor Platform albo Linux z KVM), a potem się zaloguj:

brew trust docker/tap && brew install docker/tap/sbx   # Windows: winget install -h Docker.sbx
sbx login

Claude Code

sbx secret set anthropic          # albo /login w sandboksie z subskrypcją Claude
sbx run --clone claude .

Strona Dockera o tym agencie mówi, że Claude Code domyślnie startuje z --dangerously-skip-permissions.

Codex

sbx secret set openai             # albo: sbx secret set openai --oauth
sbx run --clone codex .

Docker uruchamia Codeksa z --dangerously-bypass-approvals-and-sandbox.

Cursor

sbx run --clone cursor .

Docker uruchamia agenta CLI Cursora z --yolo; obsługuje klucz API zapisany jako sekret albo OAuth.

Używaj --clone. Bez tej flagi sbx run montuje bieżący katalog do odczytu i zapisu, a zmiany agenta trafiają do twojego drzewa roboczego w chwili zapisu. W trybie klonowania agent edytuje prywatny klon, twoje repozytorium jest widoczne tylko do odczytu w /run/sandbox/source, a sbx rm usuwa klon, więc najpierw pobierz commity, które chcesz zachować. Tryb klonowania nie działa z dołączonego worktree gita, tylko z głównego. Przy pierwszym uruchomieniu wybierz preset sieci Balanced albo Locked Down zamiast Open i sprawdź go poleceniem sbx policy ls. Przy Locked Down najpierw dopuść host modelu: sbx policy allow network api.anthropic.com (albo host swojego dostawcy). Strona startowa Dockera mówi, że w tym presecie zablokowane jest nawet API dostawcy modelu, dopóki go wprost nie dopuścisz.

Modal, Daytona, Coder i sandbox runtime

• Modal. Przykład Modala (modal-labs/modal-examples, 13_sandboxes/sandbox_agent.py) instaluje Claude Code w modal.Image, klonuje repozytorium i wykonuje poniższe wywołanie. Zostaw pty=True: przykład mówi, że Claude tego wymaga. Działa jako root i zadaje pytanie tylko do odczytu, więc pomija --dangerously-skip-permissions.

  sandbox.exec(
      "claude", "-p", "What is in this repository?",
      pty=True,
      secrets=[modal.Secret.from_name("anthropic-secret", required_keys=["ANTHROPIC_API_KEY"])],
      workdir="/repo",
  )

• Daytona. pip install daytona albo npm install @daytona/sdk. Twórz sandboks przez daytona.create(), a polecenia uruchamiaj przez sandbox.process.exec(...). Jawnie ustaw auto_delete_interval (albo ephemeral), ttl_minutes jako twardy limit czasu zegarowego oraz network_block_all lub domain_allow_list, bo zatrzymany sandboks jest domyślnie zachowywany. Parametr secrets Daytony montuje sekret organizacji jako placeholder i podstawia prawdziwą wartość dopiero w żądaniach wychodzących do hostów dozwolonych dla tego sekretu.

• Coder. curl -fsSL https://coder.com/install.sh | sh, potem coder server. Jego moduły z rejestru uruchamiają Claude Code, Codex i OpenCode w izolowanych workspace’ach, a AI Gateway centralizuje uwierzytelnianie, audyt i koszty. Coder i CloudCLI mają licencję AGPL, więc zanim je wbudujesz albo zaczniesz hostować, uzgodnij to z działem prawnym.

• Sandbox runtime Claude Code. Dopuść zapis do projektu, ~/.claude, ~/.claude.json i /tmp oraz domenę api.anthropic.com w ~/.srt-settings.json. Klucze to filesystem.allowWrite i network.allowedDomains (README sandbox-runtime, 0.0.77):

  {
    "filesystem": { "allowWrite": [".", "~/.claude", "~/.claude.json", "/tmp"] },
    "network": { "allowedDomains": ["api.anthropic.com"] }
  }

  Potem uruchom npx @anthropic-ai/sandbox-runtime claude. Gdy ~/.srt-settings.json w ogóle nie ma, srt i tak startuje na wbudowanych ustawieniach domyślnych (bez sieci, z ograniczonym zapisem), więc czysty start nie dowodzi, że plik został znaleziony; plik, który istnieje, ale nie przechodzi walidacji, sprawia, że srt kończy działanie z błędem (README, 0.0.77).

Pułapki: polecenia sandboksów, które wyglądają dobrze, a nie działają

• "command": "npx", "args": ["container-use"] nie działa. container-use to binarka w Go; rejestrujesz container-use stdio.
• E2B nie ma szablonu o nazwie claude-code. Cookbook sam buduje anthropic-claude-code; dokumentacja E2B wspomina też gotowy szablon claude, którego nie udało się nam zweryfikować 2026-09-26.
• Moduł sandbox.git w E2B jest w SDK 2.51.0 oznaczony jako przestarzały („will be removed in the next major version”). Uruchamiaj gita przez sandbox.commands.run().
• Własny hosting Daytony z GitHuba: repozytorium nie jest utrzymywane od czerwca 2026. Paczka daytona-sdk w PyPI jest przestarzała na rzecz daytona.
• Docker Sandboxes bez --clone daje agentowi działającemu bez sprawdzania uprawnień prawo zapisu w twoim drzewie roboczym.

Jak udowodnić, że granica sandboksa trzyma?

Sandboks, którego nie przetestowałeś, to tylko przekonanie. Wykonaj te cztery testy, gdy wdrażasz sandboks, i ponownie po każdej zmianie szablonu. Tech lead odpowiada za politykę sandboksa i zatwierdza wyniki testów; recenzent pull requestu zatwierdza samą zmianę.

Test	Jak	Warunek zaliczenia
Kanarek ruchu wychodzącego	W sandboksie curl -sS -m 5 https://example.com	Kończy się błędem; curl -sS -m 5 https://api.anthropic.com się łączy
Kanarek poświadczeń	W sandboksie env | grep -i -E 'token|secret|key'	Widać tylko klucz modelu (albo placeholder Daytony); żadnych wartości GitHuba, chmury ani produkcji
Test zakresu	Na twojej maszynie git diff --stat HEAD...agent/<branch>	Zmieniły się tylko ścieżki dozwolone przez zadanie
Test sprzątania	E2B Sandbox.list(), sbx ls, container-use list	Po zakończonych uruchomieniach nie został żaden sandboks

Jakość samego kodu udowadniasz jak zwykle: kodem wyjścia testu akceptacyjnego z harnessu, CI na wypchniętej gałęzi i agentem albo botem do review, zanim zatwierdzi człowiek. Sandboks sprawia, że uruchomienie jest bezpieczne; nie sprawia, że wynik jest poprawny.

Prompty do skopiowania dla sandboksów agentów

Prompt do skopiowania: zbuduj harness sandboksa dla tego repozytorium

Write scripts/sandbox-task.ts for this repository using the e2b npm package.
It must: bundle HEAD with `git bundle create`, create a sandbox from the
template "anthropic-claude-code" with network.allowOut limited to
api.anthropic.com and our package registry and denyOut ["0.0.0.0/0"],
upload the bundle, clone it to /tmp/work on a new branch named from argv,
install dependencies with our lockfile command, run
`claude -p --dangerously-skip-permissions --max-budget-usd 5 < /tmp/task.md`,
then run the acceptance command from argv itself and print its exit code,
commit leftovers, bundle only the new commits (branch ^base), download the
bundle to /tmp/out.bundle and always kill the sandbox in a finally block.
No GitHub token may enter the sandbox. Read keys only from process.env.
Show me the file and the exact commands to run it; do not run it.

Prompt do skopiowania: plik zadania dla uruchomienia w sandboksie

You are running unattended in a disposable sandbox with no network access
except the model API and the npm registry. Nobody will answer questions.

Task: add retry with exponential backoff (3 attempts, 200 ms base) to
src/billing/charge.ts for HTTP 429 and 503 responses only.
Acceptance: `npm test -- src/billing` passes, and a new test proves that a
429 followed by a 200 results in exactly one successful charge.
Constraints: change files under src/billing/ only. Do not edit, skip or
weaken existing tests. Commit your work with a descriptive message.
Do not push. If you cannot meet the acceptance check, commit what you have
and write BLOCKED.md explaining what is missing.

Prompt do skopiowania: audyt granicy sandboksa

Audit the sandbox configuration in scripts/sandbox-task.ts (or our sbx /
container-use setup). Produce a table of: every host the sandbox can reach,
every environment variable passed in and whether it is a production
credential, what is mounted writable from the host, the sandbox's maximum
lifetime, and how it is deleted after a failed run. Then write the four
canary commands (egress, credentials, scope, teardown) I should run to prove
each boundary, with the expected output for a pass. Flag anything that lets
an agent running with permission checks off reach production.

Co psuje się, gdy agenci pracują w sandboksach, i jak z tego wyjść

• Agent melduje sukces, a test akceptacyjny nie przechodzi. Wyjście: zachowaj gałąź, przeczytaj BLOCKED.md, jeśli powstał, doprecyzuj plik zadania i uruchom ponownie; nie merguj na podstawie podsumowania agenta.
• Uruchomienie ginie na limicie czasu sandboksa. Wyjście: ustaw czas życia jawnie (timeoutMs w E2B, timeout w Modalu), podziel zadanie i pakuj pracę w bundle w punktach kontrolnych, żeby limit czasu zabierał minuty, a nie całe uruchomienie.
• Instalacja zależności pada przy ścisłej liście dozwolonych hostów. Rejestr albo host pobierany w postinstall jest zablokowany. Wyjście: instaluj zależności w szablonie przy budowie, żeby w czasie uruchomienia potrzebne było tylko API modelu, albo dopisz dokładne hosty, nigdy 0.0.0.0/0.
• Sandboksy się mnożą i generują rachunki. Harness, który się wysypał, pomija kill(); Daytona domyślnie zachowuje zatrzymane sandboksy; Docker Sandboxes żyją do sbx rm. Wyjście: try/finally wokół każdego uruchomienia, jawne ustawienie automatycznego usuwania oraz limit ttl_minutes w Daytonie i cykliczne zadanie, które listuje i usuwa sandboksy starsze niż twój maksymalny czas uruchomienia.
• Zmiany agenta pojawiają się w twoim drzewie roboczym. Docker Sandboxes bez --clone montuje katalog do odczytu i zapisu. Wyjście: git stash albo odrzuć zmiany, a potem zawsze twórz sandboksy z --clone.
• git bundle create kończy się błędem pustego bundla. Agent nie zrobił żadnego commita i niczego nie zmienił. Wyjście: potraktuj to jako nieudane uruchomienie, przeczytaj końcową wiadomość agenta i wynik testu akceptacyjnego i popraw plik zadania.
• Claude Code wisi albo nic nie wypisuje w Modalu. Proces nie ma PTY. Wyjście: przekaż pty=True do sandbox.exec.
• Claude Code odrzuca --dangerously-skip-permissions. Proces działa jako root. Wyjście: uruchamiaj agenta jako zwykłego użytkownika w obrazie albo użyj Docker Sandboxes, które same startują agenta w trybie obejścia.
• Wstrzyknięty prompt wyprowadza dane. Każdy sandboks z otwartym ruchem wychodzącym może wynieść to, co agent potrafi przeczytać. Wyjście: blokuj cały ruch wychodzący poza wymienionymi hostami, trzymaj produkcyjne poświadczenia poza sandboksem i rotuj każdy klucz, który był obecny w podejrzanym uruchomieniu.

Dokąd dalej z sandboksami dla agentów

• Uprawnienia i sandboksy: tryby zatwierdzania i sandboksy systemowe wewnątrz Claude Code, Codeksa i Cursora, które narzędzia z tej strony opakowują z zewnątrz.
• Efemeryczne środowiska: daj każdemu uruchomieniu w sandboksie własną bazę z danymi, zaślepki i blok portów.
• Agenci headless w CI: uruchamiaj tę samą pętlę z pipeline’u zamiast z terminala.
• Pętle autonomiczne: długie pętle, które potrzebują dokładnie takiego ograniczenia skutków.
• Porównanie botów do AI code review: bramka review, przez którą przechodzi zwrócona gałąź.
• Przegląd narzędzi agentowych: pozostałe półki, od multiplekserów po boty do review.