Nie: natywne sesje Claude Code --cloud wymagają konta Anthropic i nie są dostępne, gdy Claude Code korzysta z Amazon Bedrock. AWS opisuje osobną metodę: własne wdrożenie wysyła zadania do sesji Amazon Bedrock AgentCore Runtime, a ich wyniki trafiają do GitHub jako pull requesty do sprawdzenia przez człowieka. To rozwiązanie dla zespołów, które chcą uruchamiać ograniczone zadania w swoim koncie AWS.
Natywne --cloud i AgentCore to różne ścieżki
Dokumentacja Claude Code określa warunki natywnych sesji --cloud: wymagają konta Anthropic i nie działają przy konfiguracji z Amazon Bedrock. Z kolei w poradniku opublikowanym 6 listopada 2026 r. AWS opisuje własny przykład z AgentCore. Nie jest to przełącznik, który kieruje natywną funkcję --cloud do Bedrocka.
| Ścieżka | Warunek konta lub dostawcy | Sposób wykonania |
Natywne sesje Claude Code --cloud | Konto Anthropic; niedostępne przy konfiguracji Claude Code z Amazon Bedrock | Sesja działa w natywnej funkcji chmurowej Claude Code |
| Przykład AWS z AgentCore | Konto AWS, w którym wdrożono rozwiązanie; modele Claude są wywoływane przez Amazon Bedrock | Własne wdrożenie uruchamia zadania w sesjach Amazon Bedrock AgentCore Runtime |
Pull request kończy pracę agenta, ale nie decyzję o zmianach: scalanie pozostaje po stronie człowieka.
Jak zadanie trafia do pull requesta
W przykładzie AWS zadanie można wysłać z wtyczki Claude Code korzystającej z lokalnego serwera MCP albo przez konsolę internetową. W pierwszym wariancie opisana ścieżka API korzysta z autoryzacji IAM, a w drugim z Cognito. Warstwa sterująca wykorzystuje API Gateway, Lambda, DynamoDB i SQS.
Każde zadanie działa we własnej sesji AgentCore Runtime i mikromaszynie wirtualnej. Przepływ opisany przez AWS wygląda tak:
- Zaplanuj zmianę. Claude Opus przygotowuje plan.
- Wprowadź kod. Claude Sonnet wykonuje zadanie w repozytorium.
- Uruchom sprawdzenia. Przykład wykonuje polecenia konfiguracji i testów zdefiniowane w repozytorium.
- Przejrzyj wynik. Claude Opus ocenia zmianę. Pętla może wrócić do planowania, maksymalnie do trzech prób łącznie.
- Otwórz pull request. Agent nie scala zmian. Jeśli weryfikacja nie przejdzie, pull request jest wersją roboczą; człowiek ocenia zmianę i decyduje o scaleniu.
Co przygotować przed wdrożeniem
Potrzebne są konto AWS i skonfigurowane dane uwierzytelniające CLI, działający Docker, Python 3.11 lub nowszy, uv oraz Node.js 22.12 lub nowszy. Repozytorium powinno być zaufane i zawierać polecenia konfiguracji oraz testów, które może uruchamiać agent. Wtyczka Claude Code jest opcjonalna, jeśli zadania mają być wysyłane przez konsolę.
AWS wymienia w poradniku pięć regionów AgentCore Runtime V2: us-east-1, us-east-2, us-west-2, ap-northeast-1 i eu-west-1; samouczek korzysta z us-west-2. Według szacunków AWS wdrożenie zajmuje 15–25 minut, a rejestracja repozytorium kolejne 8–12 minut. Przy wdrożeniu lokalnie budowany jest obraz ARM64 o wielkości około 1,3 GB.
Wdrożenie i podłączenie repozytorium
Zachowaj kolejność konfiguracji: najpierw sprawdź wymagania i repozytorium, potem wdroż zasoby, połącz GitHub i dopiero na końcu zarejestruj repozytorium.
- Przygotuj repozytorium. Sprawdź, czy zawiera wymagane polecenia konfiguracji i testów oraz czy możesz powierzyć agentowi jego kod i polecenia.
- Wykonaj kontrolę wstępną i wdroż zasoby AWS. Użyj skonfigurowanego CLI i Dockera. AWS podaje w poradniku szacunek czasu wdrożenia wynoszący 15–25 minut.
- Zainstaluj i autoryzuj GitHub App. Instalacja ogranicza dostęp do repozytoriów wskazanych dla aplikacji. Zrób to przed rejestracją repozytorium.
- Zarejestruj repozytorium. Dopiero po autoryzacji GitHub dodaj repozytorium do wdrożenia; AWS szacuje tę czynność na 8–12 minut.
- Wyślij ograniczone zadanie. Skorzystaj z wtyczki Claude Code i lokalnego MCP albo z konsoli internetowej. Po wykonaniu pracy sprawdź pull request, zanim zdecydujesz o scaleniu.
Granice filtrowania, dostępu i kosztów
Kontrola bezpieczeństwa promptu sprawdza treść zadania przed dodaniem go do kolejki. Nie obejmuje plików repozytorium ani wyników poleceń czytanych podczas pracy agenta. Ponieważ agent uruchamia polecenia zdefiniowane w repozytorium, AWS nie zaleca tego przykładu do niezaufanego kodu. Ograniczenie pętli do trzech prób sprawia też, że nie jest przeznaczony do zadań otwartych.
AWS opisuje prywatne podsieci i prywatne endpointy usług AWS, ale ruch wychodzący przez bramę NAT nadal umożliwia połączenia z GitHubem i rejestrami pakietów. Opisana zapora DNS blokuje wybrane domeny; nie jest ogólną listą dozwolonych połączeń HTTPS. Dostęp do GitHub kontroluje GitHub App, a AgentCore Identity zapewnia token użytkownik–serwer, który według AWS wygasa po ośmiu godzinach i odnawia się automatycznie.
Zasoby wdrożenia generują opłaty także wtedy, gdy nie wykonują zadań. AWS wymienia między innymi bramę NAT, endpointy interfejsowe, AWS WAF, pulę użytkowników Cognito, DNS Firewall, obrazy i logi. Domyślne ustawienie budżetu Amazon Bedrock wynosi 200 USD miesięcznie i wysyła powiadomienie e-mail; nie ogranicza wydatków.
Usuwanie wdrożenia
Przy sprzątaniu zachowaj kolejność opisaną dla przykładu AWS:
- Wyrejestruj podłączone repozytoria.
- Odłącz GitHub.
- Usuń stosy AWS.
- Usuń GitHub App.
To rozdziela odłączenie dostępu do kodu od usunięcia infrastruktury, która może generować opłaty podczas bezczynności.
