Claude Code lub Codex na działającej stronie: środowisko testowe, kopie zapasowe i kontrola

Claude Code, Codex i podobni agenci nie ograniczają się już do podpowiadania kodu. Sami uruchamiają WP-CLI, wypychają motywy Shopify, edytują komponenty Astro i otwierają pull requesty. Właśnie przez to tempo właściciele stron dają im klucze, i z tego samego powodu jedno złe polecenie dociera do klientów w kilka sekund. Ten poradnik opisuje kolejność zabezpieczeń, którą stosujemy, zanim agent dotknie strony klienta: kopia do pracy, sprawdzone odtwarzanie, uprawnienia egzekwowane przez narzędzie, dane dostępowe, które nie pozwalają na więcej, niż wymaga zadanie, i testy, które przeprowadzasz sam.

Dotyczy to WordPressa, Shopify i frontendów opartych na Gicie, takich jak Astro czy Next.js. Każde opisane niżej zachowanie produktu pochodzi z dokumentacji producenta pobranej 23 października 2026 r.

#Czy można pozwolić agentowi AI edytować stronę na produkcji

Nie na pierwszym kroku. Powód jest techniczny, a nie kwestia zaufania do modelu. Dokumentacja uprawnień Claude Code mówi wprost: “Reguły uprawnień egzekwuje Claude Code, a nie model” (tłumaczenie własne). Linijka w CLAUDE.md albo AGENTS.md w stylu “nigdy nie dotykaj produkcji” wpływa na to, co agent próbuje zrobić, ale żadnego polecenia nie zatrzyma. Na działającym serwerze powłoka agenta ma dokładnie te prawa, które ma użytkownik SSH, użytkownik bazy danych albo token API.

Jedna z odpowiedzi w wątku na r/Wordpress o przerabianiu projektu HTML z AI na motyw ujęła tę zasadę w jednym zdaniu:

AI świetnie zamienia twój HTML na elementy motywu, ale nie pozwoliłbym mu łączyć się z twoją działającą stroną i edytować jej bezpośrednio.

(u/eshbanbahadur2020, r/Wordpress, 23 października 2026, tłumaczenie własne)

Przycisk cofania też obejmuje mniej, niż się wydaje. Strona o punktach kontrolnych podaje, że plik zmieniony wyłącznie poleceniami Bash “nie jest śledzony i zostaje w obecnym stanie”, a same punkty kontrolne “nie zastępują kontroli wersji” (tłumaczenie własne). Uruchomienie wp search-replace, aktualizacja wtyczki czy wypchnięcie motywu dzieją się całkowicie poza tą historią. Dlatego praca zaczyna się z dala od produkcji.

#Jak przygotować kopię testową strony dla agenta AI

Wybierz kopię pasującą do twojej platformy.

WordPress. Strona testowa na tym samym hostingu albo kopia lokalna, z bazą danych wyeksportowaną i zaimportowaną przez WP-CLI. Cały proces opisuje nasz przewodnik po środowisku testowym WordPressa. Przy pracy z agentem liczą się dwa polecenia: wp db export zapisuje bazę do pliku, a wp search-replace ma opcję --dry-run, która według podręcznika WP-CLI “wykona całą operację wyszukiwania i zamiany i pokaże raport, ale nie zapisze zmian w bazie danych” (tłumaczenie własne). Każ agentowi uruchamiać każdą zamianę najpierw na sucho i pokazywać ci raport.

Do jednorazowych eksperymentów Playground CLI uruchamia WordPressa lokalnie poleceniem npx @wp-playground/cli@latest server. W tym trybie pliki i baza SQLite trafiają do katalogów tymczasowych, więc po zatrzymaniu nic nie zostaje. Tryb start zachowuje zmiany między uruchomieniami. Rolę agenta w takiej konfiguracji omawia nasz artykuł o WordPress Playground i MCP dla agentów AI.

Shopify. shopify theme dev wgrywa twój lokalny motyw jako motyw deweloperski i serwuje podgląd pod adresem http://127.0.0.1:9292. Dokumentacja CLI Shopify określa motywy deweloperskie jako “tymczasowe, ukryte motywy”, które nie wliczają się do limitu motywów i “są usuwane ze sklepu po siedmiu dniach bezczynności” (tłumaczenie własne). Znikają też po shopify auth logout. Jeśli potrzebujesz podglądu, który przetrwa do akceptacji przez klienta, Shopify zaleca wypchnięcie zmian do nieopublikowanego motywu. W obu przypadkach agent nie potrzebuje prawa publikacji na żywym motywie.

Astro, Next.js i inne strony oparte na Gicie. Agent pracuje na gałęzi, a hosting buduje podgląd. W Cloudflare Pages adresy podglądów domyślnie “są publiczne” (tłumaczenie własne), a każdy podgląd wysyła X-Robots-Tag: noindex; Cloudflare Access pozwala udostępnić je tylko twojemu kontu. Strona o środowiskach w Vercel zawiera ostrzeżenie warte dwukrotnego przeczytania: przygotowane wdrożenie produkcyjne korzysta z produkcyjnych zmiennych środowiskowych, “więc testy mogą sięgać do produkcyjnych usług i danych” (tłumaczenie własne). Jeśli podgląd agenta łączy się z twoją działającą bazą albo kluczami płatności, to nie jest środowisko testowe.

#Jak zrobić kopię zapasową strony, żeby cofnąć zmianę agenta

Kopia zapasowa się liczy dopiero wtedy, gdy ją odtworzyłeś. Przed sesją z agentem:

• Kod: zatwierdź albo otaguj obecny stan w Gicie. Na stronie WordPress bez Gita skopiuj wp-content do folderu z datą w nazwie.
• Baza danych: wp db export before-agent.sql. Odtworzenie to wp db import before-agent.sql, zgodnie z opisem polecenia import w WP-CLI.
• Shopify: zduplikuj żywy motyw w panelu. Produkty, zamówienia i ustawienia zmienione przez Admin API nie są częścią motywu, więc wszystko, co agent tam zapisze, wymaga osobnego eksportu.
• Próba odtworzenia: raz odtwórz kopię na środowisku testowym i zmierz czas. Zmierzone dziesięć minut jest więcej warte niż założenie, że “hosting robi kopie”.

Ten sam nawyk chroni aktualizacje wtyczek i rdzenia; w artykule czy warto aktualizować WordPressa pokazujemy, jak aktualizować bez psucia strony.

#Jak ograniczyć uprawnienia Claude Code i Codexa

Oba narzędzia mają warstwę uprawnień. Korzystaj z niej, ale nie polegaj tylko na niej.

Claude Code ma tryby: default (opisany jako Manual) pyta przed pierwszym użyciem każdego narzędzia, acceptEdits automatycznie akceptuje edycje plików w katalogu roboczym, plan przegląda projekt bez edytowania plików źródłowych, auto przekazuje ocenę działań klasyfikatorowi, a bypassPermissions pomija pytania. Dokumentacja zaleca używanie bypassPermissions “wyłącznie w odizolowanych środowiskach, takich jak kontenery czy maszyny wirtualne, gdzie Claude Code nie może wyrządzić szkód” (tłumaczenie własne). Reguły w settings.json są sprawdzane w stałej kolejności, “deny, potem ask, potem allow”, a reguła allow nie wytnie wyjątku z reguły deny. Punkt wyjścia dla repozytorium WordPressa:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./wp-config.php)", "Bash(git push *)", "Bash(wp db drop *)", "Bash(ssh *)"],
    "ask": ["Bash(wp search-replace *)", "Bash(wp plugin update *)"],
    "allow": ["Bash(git diff *)", "Bash(wp plugin list *)"]
  }
}

Jedno ograniczenie warto znać: reguły deny dla Read i Edit obejmują narzędzia plikowe Claude’a i polecenia takie jak cat czy sed, ale nie “skrypt Pythona lub Node, który sam otwiera pliki” (tłumaczenie własne). Jeśli sekrety mają być naprawdę odgrodzone, dokumentacja odsyła do piaskownicy.

Codex oddziela piaskownicę od zatwierdzeń. Według strony OpenAI o zatwierdzeniach i bezpieczeństwie agent domyślnie “działa z wyłączonym dostępem do sieci” (tłumaczenie własne), folder objęty kontrolą wersji dostaje zapis w obszarze roboczym z zatwierdzaniem na żądanie, a folder poza kontrolą wersji tryb read-only. danger-full-access oznacza brak piaskownicy i brak zatwierdzeń; strona oznacza go jako podwyższone ryzyko i odradza. Zostaw ustawienia domyślne i zatwierdzaj dostęp do sieci osobno dla każdego zadania.

Dane dostępowe to warstwa, która trzyma, gdy wszystko inne zawiedzie. Daj agentowi osobnego użytkownika bazy danych na kopii testowej, a jeśli ma tylko analizować dane, nadaj mu samo SELECT, tak jak w opisie GRANT w MySQL. W Shopify użyj tokenu aplikacji własnej z zakresami, których wymaga zadanie; Shopify zaznacza w przewodniku po zakresach dostępu, że “zakres zapisu obejmuje odczyt” (tłumaczenie własne), więc write_products to już szeroka opcja. Po zakończeniu pracy unieważnij token. Nasz audyt dostępów zdalnych i kluczy API wymienia miejsca, w których takie tokeny się chowają.

#Jak przejrzeć zmiany wprowadzone przez agenta AI

Przeczytaj listę zmian, zanim cokolwiek trafi na produkcję. git diff --stat pokazuje, które pliki się zmieniły; agent poproszony o poprawienie linku w stopce, który dotknął czterdziestu plików, zrobił też coś innego. Potem przeczytaj pełny git diff każdego pliku. Zwróć uwagę na:

• wyłączone zabezpieczenia: zakomentowaną weryfikację nonce, sprawdzenie uprawnień zastąpione przez is_admin(), test usunięty, “bo nie przechodził”;
• nowe zależności, wtyczki albo pakiety Composera, o które nikt nie prosił;
• sekrety lub klucze API wklejone w kod;
• zmiany w migracjach bazy danych, .htaccess, przekierowaniach albo robots.txt.

W WordPressie porównaj wp plugin list i wp option get active_plugins przed zmianą i po niej: część zmian siedzi w bazie danych, a nie w plikach. Jeśli agent napisał kod wtyczki, nasza lista kontrolna do audytu kodu wtyczek WordPress generowanego przez AI przechodzi przez osiem typowych błędów.

#Jak sprawdzić, czy zmiana agenta naprawdę działa

Gdy agent pisze “gotowe, przetestowane, wszystko działa”, to jest raport, a nie dowód. Test, który agent napisał sam dla siebie, może przejść z niewłaściwego powodu. Przeprowadź własne sprawdzenie:

Wpis oznaczony jako [PROMO] na r/Wordpress, napisany przez twórcę wtyczki do testów A/B, który promował do niej umiejętności dla agentów, miał tytuł: “Claude tak ułatwił zmiany na mojej stronie WordPress, że przestałem sprawdzać, czy w ogóle działają”. Jedna z odpowiedzi:

‘Przestałem sprawdzać, czy moje zmiany w ogóle działają’ to właśnie sposób, w jaki wpakowaliśmy się w dużą część bałaganu, w którym teraz stoimy. Ufaj, jasne, jeśli chcesz, ale sprawdzaj.

(u/SoItBegins_n, r/Wordpress, 22 października 2026, tłumaczenie własne)

1. curl -sI na każdym zmienionym adresie i na stronie głównej: kod odpowiedzi, przekierowania, nagłówki cache.
2. Log błędów PHP albo konsola przeglądarki na tych samych stronach.
3. Prawdziwe wysłanie formularza, a w sklepie testowe zamówienie przez cały koszyk.
4. Strona na telefonie, a nie tylko w przeglądarce bez interfejsu, której używa agent.
5. Przy zmianach istotnych dla SEO: wyrenderowany tytuł, canonical i meta robots, bo agenci edytują szablony, które je generują.

Zrób to na środowisku testowym, a potem jeszcze raz na produkcji zaraz po wdrożeniu. Jeśli coś zawiedzie na produkcji, najpierw przywróć kopię, a dopiero potem szukaj przyczyny.

#Co zrobić ze spaghetti kodem po agencie AI

Objawy są znajome: ta sama funkcja w trzech plikach, poprawki nakładane na poprawki, osobna wtyczka do każdej drobnej funkcji, style wpisane w kod, bo agent nie znalazł arkusza stylów. Nie proś tego samego agenta, żeby “posprzątał wszystko” na działającej stronie, bo tylko powiększysz listę zmian do przejrzenia. Zamroź obecny stan w Gicie, spisz, co strona ma robić, i dla każdego obszaru zdecyduj, czy go przebudować od środka, czy napisać od nowa.

Początkujący, który nie programował od 20 lat, opisał na r/Wordpress dwa tygodnie pracy z Codexem jako “koszmarną pętlę: psucie, łatanie, znowu psucie i znowu łatanie” (wątek, 21 października 2026, tłumaczenie własne). Jedna z odpowiedzi podsunęła wyjście:

Używaj Codexa do małych zmian, które da się przejrzeć, na kopii testowej, a nie do otwartych przeróbek działającej strony.

(u/NakanoNoNeko, r/Wordpress, 22 października 2026, tłumaczenie własne)

Nasz artykuł o vibecodingu a WordPressie wyjaśnia, dlaczego strony zbudowane przez AI trudno potem utrzymać. Jeśli wolisz to komuś przekazać, nasza usługa naprawy stron zrobionych przez AI przejmuje stronę od tego miejsca, a plan opieki technicznej utrzymuje potem środowisko testowe, kopie zapasowe i kontrolę aktualizacji. Jeśli chcesz włączyć agentów do swojej pracy na stałe, wdrożenia AI obejmują konfigurację uprawnień, tokenów i etapów przeglądu.

#Jakie uprawnienia dać agentowi AI na każdym etapie

Agent pisze kod. Wejście na produkcję zostaje krokiem, który wykonujesz sam.