Agent do kodowania z wyłączonymi pytaniami o zgodę jest wygodny i szybki, ale robi wszystko, co mu się każe, także wtedy, gdy każe mu złośliwy plik w cudzym repozytorium. Dlatego tryb --dangerously-skip-permissions odpala się w kontenerze albo w maszynie wirtualnej. Sam kontener niczego jednak nie gwarantuje. Liczy się to, co do niego wpadnie przez montowania i zmienne środowiskowe.
Jak uruchomić Claude Code w devcontainerze
Najkrótsza droga to gotowa funkcja devcontainera od Anthropic. W pliku .devcontainer/devcontainer.json wystarczy obraz bazowy, na przykład mcr.microsoft.com/devcontainers/base:ubuntu, i w sekcji features wpis ghcr.io/anthropics/devcontainer-features/claude-code:1.0 z pustym obiektem konfiguracji. VS Code, Cursor i inne edytory obsługujące devcontainery zbudują środowisko same, a Claude Code będzie w nim od pierwszego uruchomienia.
Dokumentacja dokłada do tego trzy rzeczy, które warto zrobić od razu. Logowanie znika przy każdym przebudowaniu kontenera, więc katalog ~/.claude trzyma się na wolumenie i wskazuje zmienną CLAUDE_CONFIG_DIR. Wersję przypina się w obrazie poleceniem npm install -g @anthropic-ai/claude-code@X.Y.Z i wyłącza automatyczne aktualizacje zmienną DISABLE_AUTOUPDATER. Zasady dla całego zespołu trafiają do /etc/claude-code/managed-settings.json. Tu jest haczyk: plik pochodzi z konfiguracji devcontainera w repozytorium, więc obejdzie go każdy, kto ma do repo prawo zapisu.
Czego nie montować do kontenera z agentem
Ostrzeżenie Anthropic jest jednoznaczne. Przy wyłączonych pytaniach o zgodę złośliwy projekt może wyprowadzić z kontenera wszystko, co w nim jest, łącznie z danymi logowania Claude Code w ~/.claude. Stąd zasady, które powinny wejść w nawyk:
- Bez ~/.ssh i plików z poświadczeniami chmury (AWS, GCP, Azure). Agent z kluczem SSH ma dostęp do wszystkiego, do czego ma go ten klucz.
- Tokeny wąskie i krótkotrwałe. Token z dostępem do jednego repozytorium zamiast osobistego tokenu do całego konta GitHuba.
- Bez /var/run/docker.sock. Kontener z gniazdem Dockera hosta może uruchomić kolejny kontener z zamontowanym całym dyskiem hosta. Na tym polegał pokaz Dockera przy premierze Cloud Sandboxes.
- Ruch sieciowy z listy dozwolonych adresów zamiast pełnego dostępu do internetu, jeśli środowisko to umożliwia.
Kontener, Docker-in-Docker czy sandbox?
Kłopot zaczyna się, gdy agent ma sam budować obrazy i odpalać kontenery, bo testy bez tego nie wstaną. Dokumentacja Dockera zestawia opcje tak:
| Sposób | Izolacja | Demon Dockera | Do czego |
|---|---|---|---|
| Docker Sandboxes | pełna (hipernadzorca) | własny, odizolowany | autonomiczne agenty |
| Kontener z gniazdem | częściowa (przestrzenie nazw) | wspólny z hostem | zaufane narzędzia |
| Docker-in-Docker | częściowa (kontener uprzywilejowany) | zagnieżdżony | CI/CD |
| Prosto na hoście | brak | hosta | ręczna praca |
Claude Code w Docker Sandboxes (sbx)
$ sbx run --name my-sandbox claude $ sbx policy allow network registry.npmjs.org $ sbx secret set github --command 'gh auth token'
Pierwsze polecenie startuje Claude Code w microVM i montuje bieżący katalog do odczytu i zapisu. Z flagą --clone repozytorium wchodzi tylko do odczytu, a agent pracuje na własnym klonie. Drugie dopuszcza ruch do rejestru npm, trzecie podaje token GitHuba prosto z gh. Token nie trafia do maszyny wirtualnej, bo dane logowania dokleja proxy na hoście. To samo dotyczy logowania przez /login: token OAuth zostaje na hoście. Po wycieku kluczy z OpenCode to akurat najmocniejszy argument za sandboksem. Jeśli w zespole pracuje kilka agentów naraz, warto pamiętać, że w agent teams tryb bez pytań o zgodę przechodzi z lidera na wszystkich teammates.
