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 jeg 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.

Oppdatering, 4. november 2026. Playground-teamet beskrev at WordPress Playground nå kan klone et aktivt nettsted inn i nettleseren, uten lokal server. Du velger New Playground > Clone a live site, skriver inn adressen og sjekker nettstedet. Kildenettstedet må ha tillegget Reprint aktivt, og du trenger en administratorkonto. Adressen alene gir ikke tilgang til filer eller database: Du limer inn migreringsnøkkelen fra Playground under Tools > Reprint Server > Migration Token og velger Authorize client. Endringer i kopien når ikke det aktive nettstedet, og den ferdige kopien lagres i nettleseren. Reprint overfører filer og databaseinnhold i små deler og justerer de lagrede nettstedsadressene. Nettleserimporten tar for øyeblikket imot opptil 2 GiB. Playground kjører WordPress i et annet miljø enn hostingen din, så noen tillegg og eksterne tjenester kan oppføre seg annerledes; innlegget anbefaler å bruke disse kontrollene sammen med tester på hostingen. For arbeid med en agent gir dette en kopi for én økt, uten egen server. Innlegget advarer også om at en kopi kan inneholde private innhold, brukerdata og påloggingsdata til tillegg, så behandle den som enhver databasekopi med kundedata og fjern den informasjonen før du deler en eksport.

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.
• Utviklings- og testnettsted (oppdatert 24. oktober 2026): Utvidelsen SnapShots, versjon 3.0.0, lagrer databasen og som standard opplastingsmappen, og gjenoppretter begge med ett klikk fra adminlinjen eller med wp snapshot restore. Utvidelser, temaer og kjernen er ikke med, og filene blir liggende på samme server. Siden til utvidelsen kaller den et utviklingsverktøy for å rulle tilbake under testing, ikke en sikkerhetskopi utenfor serveren. Den krever WP-CLI og PHP-funksjonen exec, som mange leverandører slår av. Bruk den mellom forsøkene til agenten på en lokal kopi eller i testmiljøet, og behold eksporten over og en sikkerhetskopi på et annet sted for produksjon.
• 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.

#Kan en AI-agent få en kopi av kundedatabasen

En kopi av en WooCommerce- eller Shopify-butikk i et testmiljø er en kopi av kundenes navn, adresser og ordrer. Sender agenten filinnhold til en skybasert modell, forlater de opplysningene serveren din. I EU gjelder personvernforordningen (GDPR) for dette som for all annen behandling. Artikkel 5 nr. 1 bokstav c krever at personopplysninger er “begrenset til det som er nødvendig for formålene de behandles for”, og etter artikkel 28 nr. 1 skal en behandlingsansvarlig “bare benytte databehandlere som gir tilstrekkelige garantier” (egen oversettelse). Å rette en mal for toppfeltet krever ikke ekte kunder i databasen.

I Norge gjelder dette gjennom personopplysningsloven. Lovdata skriver at loven gjennomfører EUs personvernforordning i norsk rett, og at forordningen dermed gjelder som norsk lov (personopplysningsloven på Lovdata).

I praksis anonymiserer eller sletter du kunde- og ordretabellene i kopien før økten med agenten, eller du gir agenten en kopi med bare de tabellene oppgaven berører. Med wp db export --tables=... og --exclude_tables=... fra referansen for eksport er det andre alternativet én kommando. Sjekk databehandlervilkårene til AI-leverandøren din opp mot artikkel 28 før ekte personopplysninger når dit.

Den samme forordningen gir støtte til gjenopprettingsøvelsen fra forrige del. Artikkel 32 nr. 1 regner “evnen til å gjenopprette tilgjengeligheten og tilgangen til personopplysninger i rett tid” og “en prosess for regelmessig testing” av sikkerhetstiltakene blant tiltakene som skal vurderes (egen oversettelse). En sikkerhetskopi ingen har gjenopprettet, oppfyller ingen av delene.

#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.

Bash-reglene har et hull til, og det bør du teste før du stoler på dem. En regel sammenlignes med kommandoteksten Claude skriver, ikke med programmet som faktisk kjører. Tabellen i dokumentasjonen viser selv at Bash(git push *) stopper git push origin main, men ikke git -C . push origin main, og at Bash(rm *) ikke stopper bash -c 'rm -rf build/'. Se på en deny-liste som en fartsdump for kommandoene agenten vanligvis skriver, og sett den virkelige muren et sted kommandoteksten ikke kan gå rundt.

Den muren er sandkassen. Den er slått av som standard; /sandbox i en økt eller "sandbox": {"enabled": true} i settings.json slår den på. Operativsystemet håndhever den (Seatbelt på macOS, bubblewrap på Linux og WSL2), og den dekker skallkommandoene Claude kjører “og prosessene de starter”, så Python-skriptet som slapp forbi en Read-regel, havner også innenfor. Skriving er begrenset til arbeidsmappen, mapper du har lagt til, og den midlertidige mappen. Nettverkstrafikken går gjennom en mellomtjener der listen over tillatte domener “starter tom”. Samme side nevner to begrensninger: direkte på Windows kjører kommandoene uten sandkasse, og kroker (hooks), lokale MCP-servere og hjelpekommandoer kjører utenfor sandkassen med alle rettighetene dine.

Til kontroller som krever logikk, finnes PreToolUse-kroken, som kjører før hvert verktøykall og kan blokkere det. Tillatelsessiden slår fast at en krok ikke kan oppheve en deny-regel: et kall som en deny-regel avviser, forblir avvist selv om kroken svarer “allow”. Dermed er kroker et trygt sted for regler som gjelder bare ditt prosjekt, for eksempel å avvise alle kommandoer som inneholder vertsnavnet til produksjonsserveren.

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.

Oppdatert 24. oktober 2026, et eksempel på bare lesetilgang: Den åpne MCP-serveren for Google Search Console (pakken open-gsc-mcp) har skriving slått på fra start. README-filen lister fire verktøy som endrer kontoen (submit_sitemap, delete_sitemap, add_site og delete_site), setter GSC_ENABLE_WRITES til 1 som standard, og innloggingen ber Google om full tilgang til Search Console. Verktøyene er merket som skrivende, men serveren spør deg ikke selv; om du får et spørsmål, avhenger av tillatelsene i klienten din. Skal agenten bare analysere klikk og søk, logger du inn med auth login --read-only eller setter GSC_ENABLE_WRITES=0, og da er de fire verktøyene borte. Sjekk standardinnloggingen til hver MCP-server på samme måte før du kobler den til.

Oppdatert 6. november 2026, e-postadresse i User-Agent-headeren: 5. november meldte en bruker i Claude Code-repositoriet (sak #107757) at agenten hadde sendt e-postadressen til kontoen sin til fremmede nettsteder i headeren User-Agent. Lydia Hallie fra Claude Code-teamet forklarte årsaken på Hacker News: kontoadressen ble lagt inn i modellens kontekst for at den skulle slutte å finne på navn i @author-tagger, og når modellen selv skrev en curl-kommando, satte den av og til adressen inn som kontakt i User-Agent. Anthropic sier at adressen fjernes fra konteksten i neste versjon. Inntil da har versjon 2.1.317 og nyere en innebygd modul som spør før et kall til et nettverktøy eller en curl-lignende kommando med adressen. Teamet skriver selv at den ikke dekker skript agenten skriver og kjører på egen hånd, og i samme sak beskriver to personer tester på 2.1.317 og 2.1.318 (macOS og Windows) der modulen ikke stoppet noe. Prinsippet er større enn denne feilen: alt agenten har i konteksten, kan havne i en utgående forespørsel, også kundedata fra en databasekopi. Oppdater Claude Code til minst 2.1.317, og legg til din egen PreToolUse-hook som avviser kommandoer med adressen din og ordet User-Agent (en bruker beskriver en slik hook i saken). Søk deretter i serverloggene etter User-Agent-headere med en e-postadresse, så ser du hva agenter sender til nettstedene dine.

#Hvilke API-nøkler og passord bør en AI-agent få i WordPress, WooCommerce, Shopify og Cloudflare

Hver plattform har en måte å utstede en tilgang som kan mindre enn din egen innlogging. Bruk den, og opprett den for agenten alene, så du kan trekke den tilbake uten å stenge deg selv ute.

I WordPress er det rollen som setter grensen. Dokumentasjonen om roller beskriver en administrator som en som har tilgang til alle administrasjonsfunksjonene på et nettsted, og en redaktør som en som kan publisere og administrere innlegg, også innleggene til andre brukere. En agent som redigerer innhold gjennom REST API, trenger høyst rollen redaktør. En agent med passordet til en administrator har alle administrasjonsfunksjonene, også installasjon av utvidelser, og en utvidelse er PHP som kjører på serveren din.

I Shopify har CLI-en en sperre som agenter aldri bør få lov til å oppheve. Referansen for theme push sier at --allow-live er “påkrevd i ikke-interaktive miljøer når målet er det aktive temaet”, og --publish gjør det opplastede temaet aktivt. En agent kjører ikke-interaktivt, så en deny-regel for begge flaggene holder den på upubliserte temaer. shopify theme push --unpublished oppretter et nytt upublisert tema og laster opp til det, og det er det målet agenten skal få i stedet.

#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å.

#Hvordan ser en trygg agentøkt i et WordPress-testmiljø ut i praksis

Oppgaven: flytt et påmeldingsskjema for nyhetsbrevet fra sidefeltet til bunnteksten på en WordPress-side med et eget tema i Git. Rekkefølgen nedenfor bruker bare verktøyene som er beskrevet over.

1. I testmiljøet kjører du git tag before-agent i temarepositoriet og wp db export before-agent.sql for databasen.
2. Start Claude Code i modusen plan og be om en plan. Les den. Nevner planen utvidelser, databasen eller filer utenfor temaet for en endring i bunnteksten, stopper du og spør hvorfor.
3. Bytt til acceptEdits med deny- og ask-reglene fra tidligere og sandkassen slått på. Agenten redigerer temafilene; hver wp-kommando må fortsatt godkjennes av deg.
4. Når den er ferdig, kjører du git diff --stat. To malfiler og et stilark er rimelig for denne oppgaven. Alt i functions.php som registrerer nye skript, leser du i sin helhet.
5. Kontroller selv: send inn skjemaet i testmiljøet, bekreft at abonnenten dukker opp i e-postverktøyet, se på bunnteksten på en mobil, og søk med grep i PHP-feilloggen etter nye oppføringer.
6. Slå sammen og rull ut temaet selv. Kjør de samme fem kontrollene i produksjon.
7. Feiler noe i produksjon: git revert på sammenslåingen, eller rull ut taggen before-agent på nytt. Databasen ble ikke rørt, så den trenger ingen gjenoppretting. Hadde den blitt rørt, ville wp db import before-agent.sql vært steget, og det måtte ha virket i testmiljøet først.

Agenten skrev koden i steg 3. Alle stegene som rørte produksjon, var dine.

#Hvorfor stemmer ikke nettsiden med det agenten rapporterer

#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.