Claude Code zdalnie na AWS: zadanie wychodzi, pull request wraca

AWS opisało na swoim blogu (6 listopada 2026), jak uruchomić Claude Code jako zdalnego agenta na Amazon Bedrock AgentCore. Każde zadanie programistyczne dostaje własną, odizolowaną sesję na Twoim koncie AWS, każde wywołanie modelu przechodzi przez Amazon Bedrock, a wynik wraca jako pull request, czyli propozycja zmian w kodzie, którą człowiek przegląda i zatwierdza. To przykładowy projekt do samodzielnego wdrożenia (sample-remote-coding-agent na GitHubie AWS), nie gotowy produkt z cennikiem. To też opis architektury i zabezpieczeń od AWS, a nie wynik testu jakości kodu, który taki agent produkuje.

Zadanie zlecasz, zamykasz laptopa i wracasz do gotowego efektu. Dla osoby, która nie koduje, to abstrakcja, ale mechanizm jest prosty i warto go znać, bo tak będą wyglądać zespoły, w których pracujesz albo które zatrudniasz.

Jak zadanie wędruje od Twojego polecenia do pull requesta

Zadanie możesz wysłać na dwa sposoby: z Claude Code przez wtyczkę sample-rca albo z konsoli webowej, w której logujesz się przez Amazon Cognito. Dalej wszystko dzieje się automatycznie:

• Kolejka. Funkcja Lambda sprawdza treść zadania w Amazon Bedrock Guardrails, zapisuje je w bazie DynamoDB i wrzuca do kolejki SQS.
• Sesja. Każde zadanie startuje w osobnej sesji AgentCore runtime. To mikrowirtualna maszyna z własnym procesorem, pamięcią i systemem plików. Pamięć jest czyszczona po zakończeniu sesji.
• Plan. Agent dostaje token GitHuba, klonuje repozytorium i sprawdza w pamięci AgentCore wnioski z wcześniejszych zadań na tym samym repozytorium. Plan zmiany robi Claude Opus na Bedrock.
• Kod i weryfikacja. Zmianę pisze Claude Sonnet, a agent uruchamia komendy setup i test zdefiniowane w samym repozytorium.
• Przegląd. Claude Opus ocenia wynik i może odesłać go do planowania. Łącznie są maksymalnie trzy podejścia.
• Pull request. Agent wypycha gałąź agent/<taskId> i otwiera pull request z komendą weryfikacji, jej kodem wyjścia i liczbą podejść. Jeśli testy nie przeszły, pull request jest wersją roboczą (draft).

Agent nigdy sam nie scala zmian. Decyzję podejmuje człowiek, a AWS zaleca włączenie ochrony domyślnej gałęzi (branch protection), żeby każda zmiana musiała przejść przegląd. Jak sprawdzać kod od agenta, opisywaliśmy w tekście Agent AI oddaje kod. Heise uczy, jak go sprawdzać. Podobny ruch, czyli wynajem środowiska dla agentów, robi też Moonshot w Kimi Hosted Agents.

Zabezpieczenia: co jest zamknięte, a co wciąż otwarte

Co AWS domyka

AWS podkreśla, że wywołania modelu z sesji zdalnej mają te same cechy ochrony danych co Claude Code na laptopie. Według AWS Amazon Bedrock nie używa Twoich treści do trenowania modeli ani nie udostępnia ich dostawcom modeli. Można też skonfigurować zero data retention, czyli brak zapisu żądań i odpowiedzi w trwałej pamięci AWS. Kontener nie ma innych poświadczeń AWS niż rola wykonawcza runtime'u, a ta może wywoływać tylko modele Anthropic.

Dostęp do GitHuba jest krótkotrwały. Przykład tworzy aplikację GitHub App z uprawnieniami do odczytu i zapisu Contents oraz Pull requests. Agent dostaje token ważny 8 godzin, odnawiany automatycznie. Obejmuje on tylko repozytoria, na których zainstalowałeś aplikację. Sesje działają w prywatnych podsieciach Twojego VPC, a grupa zabezpieczeń przepuszcza wyłącznie wychodzący HTTPS.

Czego AWS nie domyka

Tu zaczyna się uczciwa część, bo AWS sam wskazuje dziury:

• Guardrail sprawdza to, co wpiszesz, nie to, co agent czyta w trakcie pracy. Wstrzyknięcie poleceń ukryte w plikach repozytorium albo w wyniku komend przejdzie bez kontroli. Jak to wygląda w praktyce, pokazał przypadek AGENTS.md w Download, który nakłonił Codex i Claude Code do malware.
• Blokada domen jest czarną listą. DNS Firewall odcina domeny dostawcy modelu, takie jak api.anthropic.com, ale nie zatrzyma innego ruchu HTTPS. Na produkcję AWS radzi rozważyć listę dozwolonych domen w AWS Network Firewall.
• Repozytorium musi być zaufane. Agent uruchamia komendy zapisane w repozytorium i nie ma jak ich uczynić bezpiecznymi.

Do jakich zadań ten układ się nadaje

AWS jasno rozdziela zastosowania. Dobrze pasują ograniczone w zakresie funkcje, poprawki błędów i testy w zaufanym repozytorium, które samo deklaruje komendy setup i test. Nie pasuje kod, któremu nie ufasz, ani praca otwarta, bo po trzech nieudanych podejściach zadanie się kończy.

AWS wymienia też wady wzorca zdalnego agenta: mniej sterujesz w trakcie pracy, środowisko wymaga konfiguracji, a koszt trudniej przewidzieć. Zaleta jest taka, że kilka zadań biegnie równolegle zamiast konkurować o jeden komputer, a każde działa poza Twoim laptopem i poświadczeniami z Twojej powłoki. Przykładowe zadanie z blogu AWS to dodanie brakującego testu jednostkowego dla jednej funkcji, bez ruszania kodu poza plikami testów. Mała, sprawdzalna robota.

Rachunek, regiony i polska perspektywa

Tu jest haczyk dla portfela. Wdrożenie rozlicza się także wtedy, gdy nic nie robi: płacisz za bramę NAT, punkty końcowe interfejsów, AWS WAF, pulę użytkowników Cognito, DNS Firewall, obrazy i logi. Laptop zamknięty, a licznik chodzi. Deploy ustawia domyślny budżet 200 USD miesięcznie na Bedrock, który wysyła e-mail z ostrzeżeniem, ale niczego nie blokuje. AWS nie publikuje szacunku kosztów tego przykładu, więc realny rachunek policzysz w cennikach poszczególnych usług AWS. Na koniec trzeba posprzątać w odpowiedniej kolejności: najpierw wyrejestrować repozytoria, potem odłączyć GitHuba i zniszczyć stosy, bo część zasobów nie należy do żadnego stosu i dalej się rozlicza.

Wdrożenie wymaga konta AWS (najlepiej dedykowanego) w jednym z regionów: us-east-1, us-east-2, us-west-2, ap-northeast-1 albo eu-west-1 (Irlandia). Ostatni jest najbliżej polskich firm. Do tego potrzebujesz Dockera, bo lokalnie buduje się obraz o wielkości około 1,3 GB, oraz Pythona 3.11+ i Node.js 22.12+. Deploy trwa 15-25 minut, rejestracja repozytorium kolejne 8-12. Według AWS Bedrock może być używany zgodnie z RODO. Jeśli liczy się rezydencja danych, przypnij geograficzny profil inferencji zamiast globalnych ustawień domyślnych przykładu i włącz zero data retention w regionie wdrożenia, sprawdzając, czy Twój model to wspiera.

Jeśli Twój zespół myśli o agentach w kodzie, kolejne rozwiązania będą się różnić szczegółami, ale pytania będą te same: gdzie działa sesja, kto trzyma poświadczenia i kto naciska "merge". Weź listę ostatnich pięciu zadań technicznych w Twoim zespole albo projekcie i przy każdym zaznacz dwie rzeczy: czy zakres jest wąski i czy istnieją testy, które powiedzą, że zmiana działa. Zadania z dwoma "tak" to kandydaci do oddania agentowi. Reszta zostaje u ludzi. To 10 minut z kartką i nie wymaga kodowania.

Jeśli interesuje Cię druga strona, czyli gdzie agentom można powierzyć cały kod, zobacz też Entire, które rzuca wyzwanie GitHubowi hostingiem kodu dla agentów AI.