La Claude Code eller Codex endre nettsiden: testmiljø, sikkerhetskopi og kontroll

Claude Code, Codex og lignende agenter nøyer seg ikke lenger med å foreslå kode. De kjører WP-CLI, laster opp Shopify-temaer, redigerer Astro-komponenter og åpner pull requests på egen hånd. Den farten er grunnen til at nettstedseiere gir dem nøklene, og den er også grunnen til at én feil kommando når kundene i løpet av sekunder. Denne guiden viser rekkefølgen på sikringene vi bruker før en agent får røre en kundes nettside: en kopi å jobbe på, en gjenoppretting du har testet, tillatelser som verktøyet håndhever, tilganger som ikke kan mer enn oppgaven krever, og kontroller du kjører selv.

Det gjelder WordPress, Shopify og Git-baserte frontender som Astro eller Next.js. All produktatferd som siteres nedenfor, er hentet fra leverandørenes egen dokumentasjon 23. oktober 2026. Sitater derfra er egen oversettelse.

#Bør jeg la en AI-agent endre nettsiden direkte i produksjon

Nei, ikke som første steg. Grunnen er teknisk, ikke et spørsmål om tillit til modellen. Tillatelsesdokumentasjonen til Claude Code sier det rett ut: “Tillatelsesregler håndheves av Claude Code, ikke av modellen.” En linje i CLAUDE.md eller AGENTS.md om å “aldri røre produksjon” påvirker hva agenten prøver på. Den stopper ingen kommando. På en server i drift har agentens skall de rettighetene SSH-brukeren, databasebrukeren eller API-nøkkelen har.

Et svar i en tråd på r/Wordpress om å gjøre et AI-laget HTML-design om til et tema, oppsummerte regelen i én setning:

AI er flink til å gjøre HTML-en din om til temadeler, men jeg ville ikke latt den koble seg til og redigere den levende nettsiden din direkte.

(u/eshbanbahadur2020, r/Wordpress, 23. oktober 2026, egen oversettelse)

Angreknappen er også smalere enn den ser ut. Siden om sjekkpunkter i Claude Code sier at en fil som bare er endret av Bash-kommandoer, “spores ikke og forblir som den er”, og kaller sjekkpunkter “ikke en erstatning for versjonskontroll”. En kjøring av wp search-replace, en utvidelsesoppdatering eller en temaopplasting skjer helt utenfor den historikken. Derfor starter arbeidsflyten et annet sted enn i produksjon.

#Hvordan gi agenten en kopi av nettsiden i stedet for produksjon

Velg kopien som passer plattformen din.

WordPress. Et testmiljø hos samme leverandør, eller en lokal kopi, der databasen eksporteres og importeres med WP-CLI. Guiden vår om arbeidsflyt med testmiljø går gjennom hele oppsettet. To kommandoer er viktige for agenter: wp db export skriver databasen til en fil, og wp search-replace har valget --dry-run, som ifølge WP-CLI-håndboken vil “kjøre hele søk-og-erstatt-operasjonen og vise en rapport, men ikke lagre endringene i databasen”. La agenten kjøre hver search-replace som en prøvekjøring først og vise deg rapporten.

Til engangseksperimenter starter Playground CLI WordPress lokalt med npx @wp-playground/cli@latest server. I den modusen ligger filene og SQLite-databasen i midlertidige mapper, så ingenting overlever når du stopper. Modusen start beholder endringene mellom omstarter. Artikkelen vår om WordPress Playground og MCP for AI-agenter dekker agentdelen av det oppsettet.

Shopify. shopify theme dev laster opp det lokale temaet ditt som et utviklingstema og viser en forhåndsvisning på http://127.0.0.1:9292. CLI-dokumentasjonen til Shopify beskriver utviklingstemaer som “midlertidige, skjulte temaer” som ikke teller mot temagrensen og “slettes fra butikken etter sju dager uten aktivitet”. De slettes også ved shopify auth logout. Trenger du en forhåndsvisning som varer lenge nok til at kunden kan se på den, anbefaler Shopify heller å laste opp til et upublisert tema. Uansett trenger agenten aldri rett til å publisere det aktive temaet.

Astro, Next.js og andre Git-baserte nettsider. Agenten jobber på en gren, og leverandøren bygger en forhåndsvisning. Hos Cloudflare Pages er forhåndsvisnings-URL-er “offentlige” som standard, og hver forhåndsvisning sender X-Robots-Tag: noindex; med Cloudflare Access kan du begrense dem til kontoen din. Siden om miljøer hos Vercel har en advarsel som er verdt å lese to ganger: en produksjonsutrulling som venter på publisering, bruker miljøvariablene fra produksjon, “så testing kan få tilgang til produksjonstjenester og -data”. Snakker agentens forhåndsvisning med den aktive databasen eller betalingsnøklene dine, er det ikke et testmiljø.

#Hvordan ta sikkerhetskopi så agentens endring kan rulles tilbake

En sikkerhetskopi teller først når du har gjenopprettet den. Før en økt med agenten:

• Kode: commit eller tagg dagens tilstand i Git. På en WordPress-side uten Git kopierer du wp-content med datoen i mappenavnet.
• Database: wp db export before-agent.sql. Den tilhørende gjenopprettingen er wp db import before-agent.sql, ifølge WP-CLI-referansen for import.
• Shopify: dupliser det aktive temaet i administrasjonspanelet. Produkter, ordrer og innstillinger som endres gjennom Admin API, ligger ikke i temaet, så alt agenten skriver der, trenger sin egen eksport.
• Øvelse i gjenoppretting: kjør gjenopprettingen i testmiljøet én gang og ta tiden. Ti målte minutter slår en antakelse om at “leverandøren tar sikkerhetskopier”.

Den samme vanen beskytter oppdateringer av utvidelser og kjerne; artikkelen vår om hvorvidt det er verdt å oppdatere WordPress viser hvordan du oppdaterer uten å ødelegge nettsiden.

#Hvordan begrense hva Claude Code eller Codex får lov til

Begge verktøyene har et tillatelseslag. Bruk det, men ikke stol bare på det.

Claude Code har moduser: default (merket Manual) spør før første bruk av hvert verktøy, acceptEdits godtar filendringer i arbeidsmappen automatisk, plan utforsker uten å endre kildefiler, auto lar en klassifiserer vurdere handlingene, og bypassPermissions hopper over spørsmålene. Dokumentasjonen sier at bypassPermissions skal brukes “bare i isolerte miljøer som containere eller virtuelle maskiner, der Claude Code ikke kan gjøre skade”. Reglene i settings.json sjekkes i fast rekkefølge, “deny, så ask, så allow”, og en allow-regel kan ikke lage et unntak fra en deny-regel. Et utgangspunkt for et WordPress-repositorium:

{
  "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 *)"]
  }
}

Én begrensning bør du kjenne til: deny-regler for Read og Edit dekker filverktøyene til Claude og kommandoer som cat eller sed, men ikke “et Python- eller Node-skript som åpner filer selv”. Vil du ha en hard mur rundt hemmelighetene, viser dokumentasjonen til sandkassen.

Codex skiller sandkassen fra godkjenningene. Ifølge siden om godkjenninger og sikkerhet fra OpenAI “kjører agenten med nettverkstilgang slått av” som standard, en mappe under versjonskontroll får skrivetilgang til arbeidsområdet med godkjenning ved behov, og en mappe utenfor versjonskontroll får read-only. danger-full-access betyr ingen sandkasse og ingen godkjenninger; siden merker det som forhøyet risiko og fraråder det. Behold standarden og godkjenn nettverkstilgang for hver oppgave.

Tilganger er laget som holder når alt annet svikter. Gi agenten en egen databasebruker på testkopien, og trenger den bare å analysere data, gir du den kun SELECT, slik GRANT-referansen til MySQL beskriver. For Shopify: en tilgangsnøkkel fra en egen app med bare de tilgangsområdene oppgaven trenger; Shopify påpeker i guiden om tilgangsområder at “et skriveområde inkluderer lesing”, så write_products er allerede det brede valget. Trekk tilbake nøkkelen når jobben er ferdig. Gjennomgangen vår av fjerntilgang og API-nøkler viser hvor slike nøkler gjemmer seg.

#Hvordan gå gjennom endringene en AI-agent har gjort

Les endringslisten før noe flyttes til produksjon. git diff --stat viser hvilke filer som er endret; har en agent som skulle rette en lenke i bunnteksten rørt førti filer, har den gjort noe annet i tillegg. Les deretter hele endringen i hver fil. Se etter:

• deaktiverte kontroller: en utkommentert nonce-verifisering, en rettighetssjekk byttet ut med is_admin(), en test slettet “fordi den feilet”;
• nye avhengigheter, utvidelser eller Composer-pakker ingen har bedt om;
• hemmeligheter eller API-nøkler limt inn i koden;
• endringer i databasemigreringer, .htaccess, omdirigeringer eller robots.txt.

I WordPress sammenligner du wp plugin list og wp option get active_plugins før og etter: noen endringer ligger i databasen, ikke i filene. For utvidelseskode agenten har skrevet, går sjekklisten vår for AI-generert WordPress-utvidelseskode gjennom åtte vanlige feil.

#Hvordan sjekke at endringen fra agenten faktisk virker

At agenten sier “ferdig, testet, alt virker”, er en rapport, ikke et bevis. En kontroll agenten har skrevet for seg selv, kan bestå av feil grunn. Kjør dine egne:

Et innlegg merket [PROMO] på r/Wordpress, skrevet av utvikleren av en utvidelse for A/B-testing som promoterte agentferdigheter til den, hadde tittelen: “Claude gjorde det så lett å endre WordPress-siden min at jeg sluttet å sjekke om endringene faktisk virket”. Et av svarene:

‘Jeg sluttet å sjekke om endringene mine faktisk virket’ er akkurat slik vi havnet i mye av rotet vi står i nå. Stol på det, greit nok, hvis du vil, men sjekk.

(u/SoItBegins_n, r/Wordpress, 22. oktober 2026, egen oversettelse)

1. curl -sI mot hver endrede URL og mot forsiden: statuskode, omdirigeringer, cache-headere.
2. PHP-feilloggen eller nettleserkonsollen på de samme sidene.
3. En ekte innsending av skjema, og i en nettbutikk en testordre gjennom kassen.
4. Siden på en mobil, ikke bare i agentens hodeløse nettleser.
5. For endringer som påvirker SEO: den gjengitte tittelen, canonical og robots-meta, siden agenter redigerer maler som skriver dem ut.

Gjør dette i testmiljøet, og så igjen i produksjon rett etter utrullingen. Feiler noe i produksjon, gjenoppretter du først og feilsøker etterpå.

#Hva gjør jeg når AI-agenten har etterlatt spagettikode

Tegnene er kjente: den samme funksjonen i tre filer, rettelser stablet oppå rettelser, én utvidelse per lille funksjon, stiler skrevet direkte i HTML fordi agenten ikke fant stilarket. Ikke be den samme agenten om å “rydde opp i alt” på nettsiden i drift; det mangedobler endringene du må gå gjennom. Frys dagens tilstand i Git, list opp hva nettsiden må gjøre, og avgjør område for område om det skal omstruktureres eller bygges på nytt.

En nybegynner som ikke hadde programmert på 20 år, beskrev to uker med Codex på r/Wordpress som “en marerittsløyfe: ødelegge, lappe, ødelegge igjen og lappe igjen” (tråd, 21. oktober 2026, egen oversettelse). Et av svarene pekte på veien ut:

Bruk Codex til små endringer som kan gjennomgås, i testmiljøet, ikke til åpne omskrivinger av den levende nettsiden.

(u/NakanoNoNeko, r/Wordpress, 22. oktober 2026, egen oversettelse)

Artikkelen vår om vibecoding og WordPress forklarer hvorfor AI-bygde nettsider blir vanskelige å vedlikeholde. Vil du heller overlate det til noen andre, tar tjenesten vår for redning av AI-bygde nettsider over nettsiden derfra, og en vedlikeholdsavtale holder testmiljø, sikkerhetskopier og oppdateringskontroller i gang etterpå. Vil du ha agenter fast i arbeidsflyten, dekker AI-implementering oppsett av tillatelser, nøkler og gjennomgangssteg.

#Hvilken tilgang skal agenten ha i hver fase

Agenten gjør skrivejobben. Produksjon er et steg du tar selv.