Claude Code oder Codex an der Live-Website: Testumgebung, Sicherung und Kontrolle

Claude Code, Codex und ähnliche Agenten schlagen längst nicht mehr nur Code vor. Sie führen WP-CLI aus, laden Shopify-Themes hoch, bearbeiten Astro-Komponenten und öffnen selbstständig Pull Requests. Genau dieses Tempo ist der Grund, warum Website-Betreiber ihnen die Schlüssel überlassen, und zugleich der Grund, warum ein einziger falscher Befehl binnen Sekunden bei den Kunden ankommt. Dieser Leitfaden beschreibt die Reihenfolge der Schutzmaßnahmen, die wir einhalten, bevor ein Agent eine Kundenwebsite anfasst: eine Kopie zum Arbeiten, eine erprobte Wiederherstellung, Berechtigungen, die das Werkzeug selbst durchsetzt, Zugangsdaten, die nicht mehr können als die Aufgabe verlangt, und Prüfungen, die Sie selbst durchführen.

Das gilt für WordPress, Shopify und Git-basierte Frontends wie Astro oder Next.js. Jedes hier zitierte Produktverhalten stammt aus der Dokumentation des jeweiligen Herstellers, abgerufen am 23. Oktober 2026. Zitate daraus sind eigene Übersetzung.

#Darf ein KI-Agent direkt an der Live-Website arbeiten?

Nein, jedenfalls nicht als erster Schritt. Der Grund ist technisch, keine Frage des Vertrauens in das Modell. Die Berechtigungsdokumentation von Claude Code sagt es klar: “Berechtigungsregeln werden von Claude Code durchgesetzt, nicht vom Modell.” Eine Zeile in CLAUDE.md oder AGENTS.md wie “fass niemals die Produktion an” beeinflusst, was der Agent versucht. Einen Befehl hält sie nicht auf. Auf einem Live-Server hat die Shell des Agenten genau die Rechte, die der SSH-Benutzer, der Datenbankbenutzer oder das API-Token haben.

Eine Antwort in einem r/Wordpress-Thread über die Umwandlung eines KI-generierten HTML-Designs in ein Theme fasste die Regel in einem Satz zusammen:

KI ist großartig darin, HTML in Theme-Bausteine zu verwandeln, aber ich würde sie nicht direkt mit der Live-Website verbinden und dort bearbeiten lassen.

(u/eshbanbahadur2020, r/Wordpress, 23. Oktober 2026, eigene Übersetzung)

Auch die Rückgängig-Funktion reicht weniger weit, als es scheint. Laut der Seite zu Checkpoints wird eine Datei, die nur Bash-Befehle geändert haben, “nicht erfasst und bleibt, wie sie ist”, und Checkpoints sind “kein Ersatz für eine Versionsverwaltung”. Ein Lauf von wp search-replace, ein Plugin-Update oder ein hochgeladenes Theme passieren komplett außerhalb dieser Historie. Deshalb beginnt der Ablauf fern der Produktion.

#WordPress, Shopify oder Astro: wie bekommt der Agent eine Kopie statt der Live-Seite?

Wählen Sie die Kopie, die zu Ihrer Plattform passt.

WordPress. Eine Testumgebung beim selben Hoster oder eine lokale Kopie, wobei die Datenbank per WP-CLI exportiert und importiert wird. Unsere Anleitung zum Staging-Workflow geht die vollständige Einrichtung durch. Für Agenten zählen zwei Befehle: wp db export schreibt die Datenbank in eine Datei, und wp search-replace kennt die Option --dry-run, die laut WP-CLI-Handbuch “den gesamten Suchen-und-Ersetzen-Vorgang ausführt und einen Bericht zeigt, die Änderungen aber nicht in der Datenbank speichert”. Lassen Sie den Agenten jedes Suchen und Ersetzen zuerst als Probelauf ausführen und sich den Bericht zeigen.

Für Wegwerf-Experimente startet Playground CLI WordPress lokal mit npx @wp-playground/cli@latest server. In diesem Modus liegen Dateien und SQLite-Datenbank in temporären Verzeichnissen, nach dem Beenden ist also nichts mehr da. Der Modus start behält Änderungen zwischen Neustarts. Unser Artikel zu WordPress Playground und MCP für KI-Agenten behandelt die Agentenseite dieser Einrichtung.

Aktualisierung, 4. November 2026. Das Playground-Team hat beschrieben, dass WordPress Playground eine Live-Website jetzt ohne lokalen Server in den Browser klonen kann. Sie wählen New Playground > Clone a live site, geben die Adresse ein und prüfen die Website. Auf der Quell-Website muss das Plugin Reprint aktiv sein, und Sie brauchen ein Administratorkonto. Die Adresse allein gibt keinen Zugriff auf Dateien oder Datenbank: Sie fügen den in Playground angezeigten Migrationsschlüssel unter Tools > Reprint Server > Migration Token ein und wählen Authorize client. Änderungen an der Kopie erreichen die Live-Website nicht, die fertige Kopie wird im Browser gespeichert. Reprint überträgt Dateien und Datenbankinhalt in kleinen Teilen und passt die gespeicherten Website-Adressen an. Der Browser-Import akzeptiert derzeit bis zu 2 GiB. Playground führt WordPress in einer anderen Umgebung aus als Ihr Hosting, daher können sich manche Plugins und externe Dienste anders verhalten; der Beitrag rät, diese Prüfungen zusätzlich zu Tests auf Ihrem Hosting zu nutzen. Für die Arbeit mit einem Agenten ergibt das eine Kopie für eine Sitzung ohne eigenen Server. Der Beitrag warnt außerdem, dass eine Kopie private Inhalte, Nutzerdaten und Plugin-Zugangsdaten enthalten kann. Behandeln Sie sie daher wie jede Datenbankkopie mit Kundendaten und entfernen Sie diese Informationen, bevor Sie einen Export teilen.

Shopify. shopify theme dev lädt Ihr lokales Theme als Entwicklungs-Theme hoch und stellt eine Vorschau unter http://127.0.0.1:9292 bereit. Die CLI-Dokumentation von Shopify beschreibt Entwicklungs-Themes als “temporäre, verborgene Themes”, die nicht zu Ihrem Theme-Limit zählen und “nach sieben Tagen Inaktivität aus dem Shop gelöscht werden”. Auch bei shopify auth logout werden sie gelöscht. Brauchen Sie eine dauerhafte Vorschau für die Abnahme durch den Kunden, empfiehlt Shopify stattdessen, in ein unveröffentlichtes Theme hochzuladen. So oder so braucht der Agent nie das Recht, das Live-Theme zu veröffentlichen.

Astro, Next.js und andere Git-basierte Websites. Der Agent arbeitet auf einem Branch, und der Hoster baut daraus eine Vorschau. Bei Cloudflare Pages sind Vorschau-URLs standardmäßig “öffentlich”, und jede Vorschau sendet X-Robots-Tag: noindex; mit Cloudflare Access lässt sich der Zugriff auf Ihr Konto beschränken. Die Seite zu Umgebungen bei Vercel enthält eine Warnung, die man zweimal lesen sollte: Ein vorbereitetes Produktions-Deployment nutzt die Umgebungsvariablen der Produktion, “sodass Tests auf Produktionsdienste und -daten zugreifen können”. Spricht die Vorschau des Agenten mit Ihrer Live-Datenbank oder Ihren Zahlungsschlüsseln, ist sie keine Testumgebung.

#Website sichern, bevor der KI-Agent loslegt: was gehört dazu?

Eine Sicherung zählt erst, wenn Sie sie einmal wiederhergestellt haben. Vor einer Sitzung mit dem Agenten:

• Code: den aktuellen Stand in Git committen oder mit einem Tag versehen. Auf einer WordPress-Seite ohne Git kopieren Sie wp-content in einen Ordner mit dem Datum im Namen.
• Datenbank: wp db export before-agent.sql. Die passende Wiederherstellung ist laut WP-CLI-Referenz zum Import wp db import before-agent.sql.
• Entwicklungs- und Testseiten (Update vom 24. Oktober 2026): Das Plugin SnapShots in Version 3.0.0 speichert die Datenbank und standardmäßig den Uploads-Ordner und stellt beides mit einem Klick über die Admin-Leiste oder per wp snapshot restore wieder her. Plugins, Themes und der WordPress-Kern gehören nicht dazu, und die Dateien bleiben auf demselben Server. Die Plugin-Seite beschreibt es als Entwicklungswerkzeug für Tests und ausdrücklich nicht als externe Sicherung. Voraussetzung sind WP-CLI und die PHP-Funktion exec, die viele Hoster sperren. Nutzen Sie es zwischen zwei Agenten-Versuchen auf einer lokalen oder Testkopie, und behalten Sie für die Produktion den Export von oben plus eine Sicherung außerhalb des Servers.
• Shopify: das Live-Theme im Admin duplizieren. Produkte, Bestellungen und Einstellungen, die über die Admin API geändert werden, stecken nicht im Theme, also braucht alles, was der Agent dort schreibt, einen eigenen Export.
• Wiederherstellung üben: einmal in der Testumgebung zurückspielen und die Zeit stoppen. Zehn gemessene Minuten sind mehr wert als die Annahme “der Hoster hat doch Sicherungen”.

Dieselbe Gewohnheit schützt auch Plugin- und Core-Updates; unser Artikel zur Frage, ob es sich lohnt, WordPress zu aktualisieren, zeigt, wie Sie aktualisieren, ohne die Website zu beschädigen.

#Darf ein KI-Agent mit echten Kundendaten arbeiten? Die DSGVO-Frage

Eine Kopie eines WooCommerce- oder Shopify-Shops in der Testumgebung ist eine Kopie von Kundennamen, Adressen und Bestellungen. Schickt der Agent Dateiinhalte an ein Cloud-Modell, verlassen diese Daten Ihren Server. In der EU gilt dafür die DSGVO wie für jede andere Verarbeitung. Nach Artikel 5 Absatz 1 Buchstabe c müssen personenbezogene Daten “auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein”, und nach Artikel 28 Absatz 1 arbeitet ein Verantwortlicher “nur mit Auftragsverarbeitern, die hinreichend Garantien” bieten. Um die Vorlage für den Kopfbereich zu reparieren, braucht niemand echte Kunden in der Datenbank.

In der Praxis heißt das: Anonymisieren oder löschen Sie die Kunden- und Bestelltabellen in der Kopie vor der Sitzung mit dem Agenten, oder geben Sie ihm eine Kopie, die nur die Tabellen enthält, die die Aufgabe berührt. Mit wp db export --tables=... und --exclude_tables=... aus der Referenz zum Export ist die zweite Variante ein einziger Befehl. Prüfen Sie die Bedingungen Ihres KI-Anbieters zur Auftragsverarbeitung anhand von Artikel 28, bevor echte personenbezogene Daten dort ankommen.

Dieselbe Verordnung stützt auch die Wiederherstellungsübung aus dem vorigen Abschnitt. Artikel 32 Absatz 1 nennt unter den zu berücksichtigenden Maßnahmen “die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen” sowie “ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit” der Maßnahmen. Eine Sicherung, die nie jemand zurückgespielt hat, erfüllt keins von beiden.

#Berechtigungen in Claude Code und Codex einschränken: wie geht das?

Beide Werkzeuge haben eine Berechtigungsebene. Nutzen Sie sie, aber verlassen Sie sich nicht allein darauf.

Claude Code kennt Modi: default (als Manual bezeichnet) fragt vor der ersten Nutzung jedes Werkzeugs nach, acceptEdits übernimmt Dateiänderungen im Arbeitsverzeichnis automatisch, plan erkundet, ohne Quelldateien zu bearbeiten, auto lässt einen Klassifikator die Aktionen prüfen, und bypassPermissions überspringt alle Rückfragen. Laut Dokumentation sollte bypassPermissions “nur in isolierten Umgebungen wie Containern oder VMs genutzt werden, in denen Claude Code keinen Schaden anrichten kann”. Regeln in settings.json werden in fester Reihenfolge geprüft, “deny, dann ask, dann allow”, und eine allow-Regel kann keine Ausnahme aus einer deny-Regel herausschneiden. Ein Ausgangspunkt für ein WordPress-Repository:

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

Eine Grenze sollten Sie kennen: Read- und Edit-Sperrregeln gelten für die Dateiwerkzeuge von Claude und für Befehle wie cat oder sed, nicht aber für “ein Python- oder Node-Skript, das Dateien selbst öffnet”. Für eine harte Mauer um Geheimnisse verweist die Dokumentation auf die Sandbox.

Bash-Regeln haben eine zweite Lücke, die Sie testen sollten, bevor Sie sich darauf verlassen. Eine Regel prüft den Befehlstext, den Claude schreibt, nicht das Programm, das tatsächlich läuft. Die Tabelle in der Dokumentation selbst zeigt: Bash(git push *) stoppt git push origin main, aber nicht git -C . push origin main, und Bash(rm *) stoppt bash -c 'rm -rf build/' nicht. Betrachten Sie eine Sperrliste als Bremsschwelle für die Befehle, die der Agent üblicherweise schreibt, und ziehen Sie die eigentliche Mauer dort hoch, wo der Befehlstext sie nicht umgehen kann.

Diese Mauer ist die Sandbox. Sie ist standardmäßig aus; /sandbox in einer Sitzung oder "sandbox": {"enabled": true} in settings.json schaltet sie ein. Das Betriebssystem setzt sie durch (Seatbelt unter macOS, bubblewrap unter Linux und WSL2), und sie umfasst die Shell-Befehle, die Claude ausführt, “und die Prozesse, die diese starten”. Das Python-Skript, das an einer Read-Regel vorbeikam, läuft also ebenfalls darin. Schreiben ist nur im Arbeitsverzeichnis, in hinzugefügten Verzeichnissen und im temporären Verzeichnis erlaubt. Der Netzwerkverkehr läuft über einen Proxy, dessen Liste erlaubter Domains “leer beginnt” (eigene Übersetzung). Zwei Grenzen nennt dieselbe Seite: Unter nativem Windows laufen Befehle ohne Sandbox, und Hooks, lokale MCP-Server sowie Hilfsbefehle laufen außerhalb der Sandbox mit Ihren vollen Rechten.

Für Prüfungen, die Logik brauchen, läuft ein PreToolUse-Hook vor jedem Werkzeugaufruf und kann ihn blockieren. Die Berechtigungsseite stellt klar, dass ein Hook eine Sperrregel nicht lockern kann: Ein Aufruf, den eine Sperrregel ablehnt, bleibt abgelehnt, auch wenn der Hook “allow” zurückgibt. Damit sind Hooks ein sicherer Ort für projektspezifische Regeln, etwa die Ablehnung jedes Befehls, der den Hostnamen der Produktion enthält.

Codex trennt Sandbox und Freigaben. Laut der Seite zu Freigaben und Sicherheit von OpenAI “läuft der Agent mit abgeschaltetem Netzwerkzugriff”, ein Ordner unter Versionsverwaltung bekommt Schreibrechte im Arbeitsbereich mit Freigaben auf Anfrage, und ein Ordner ohne Versionsverwaltung bekommt read-only. danger-full-access bedeutet keine Sandbox und keine Freigaben; die Seite stuft das als erhöhtes Risiko ein und rät davon ab. Bleiben Sie beim Standard und geben Sie den Netzwerkzugriff pro Aufgabe frei.

Zugangsdaten sind die Ebene, die hält, wenn alles andere versagt. Geben Sie dem Agenten einen eigenen Datenbankbenutzer auf der Testkopie, und wenn er Daten nur auswerten soll, gewähren Sie ihm ausschließlich SELECT, wie in der GRANT-Referenz von MySQL beschrieben. Für Shopify ein Token einer Custom App mit genau den Scopes, die die Aufgabe braucht; Shopify weist in seinem Leitfaden zu Zugriffsbereichen darauf hin, dass “ein Schreibbereich das Lesen einschließt”, write_products ist also bereits die weitgehende Variante. Widerrufen Sie das Token, sobald die Arbeit erledigt ist. Unsere Prüfung von Fernzugriffen und API-Schlüsseln zeigt, wo sich solche Tokens verstecken.

Update vom 24. Oktober 2026, ein Beispiel für reinen Lesezugriff: Der quelloffene MCP-Server für die Google Search Console (Paket open-gsc-mcp) hat Schreibzugriff ab Werk eingeschaltet. Die README nennt vier Werkzeuge, die das Konto ändern (submit_sitemap, delete_sitemap, add_site und delete_site), setzt GSC_ENABLE_WRITES standardmäßig auf 1, und die Anmeldung fordert bei Google vollen Search-Console-Zugriff an. Die Werkzeuge sind als schreibend markiert, doch der Server fragt Sie nicht selbst; ob eine Rückfrage erscheint, hängt von den Berechtigungseinstellungen Ihres Clients ab. Soll der Agent nur Klicks und Suchanfragen auswerten, melden Sie sich mit auth login --read-only an oder setzen GSC_ENABLE_WRITES=0, dann fehlen die vier Werkzeuge ganz. Prüfen Sie die Standardanmeldung jedes MCP-Servers auf dieselbe Weise, bevor Sie ihn verbinden.

Update vom 6. November 2026, E-Mail-Adresse im User-Agent-Header: Am 5. November meldete ein Nutzer im Repository von Claude Code (Issue #107757), dass der Agent die E-Mail-Adresse des eigenen Kontos im Header User-Agent an fremde Websites geschickt hatte. Lydia Hallie aus dem Claude-Code-Team erklärte die Ursache auf Hacker News: Die Kontoadresse war in den Kontext des Modells aufgenommen worden, damit es bei @author-Tags keine Namen mehr erfindet. Schrieb das Modell selbst einen curl-Befehl, setzte es diese Adresse manchmal als Kontakt in den User-Agent. Anthropic kündigt an, die Adresse mit dem nächsten Release aus dem Kontext zu entfernen. Bis dahin enthalten die Versionen ab 2.1.317 ein eingebautes Modul, das vor einem Web-Tool-Aufruf oder einem curl-artigen Befehl mit dieser Adresse nachfragt. Nach Angaben des Teams erfasst es keine Skripte, die der Agent selbst schreibt und ausführt, und im selben Issue beschreiben zwei Personen Tests mit 2.1.317 und 2.1.318 (macOS und Windows), bei denen das Modul nichts aufgehalten hat. Das Prinzip reicht über diesen Fehler hinaus: Alles, was der Agent im Kontext hat, kann in einer ausgehenden Anfrage landen, auch Kundendaten aus einer Datenbankkopie. Aktualisieren Sie Claude Code mindestens auf 2.1.317 und ergänzen Sie einen eigenen PreToolUse-Hook, der Befehle mit Ihrer Adresse und dem Wort User-Agent ablehnt (ein Nutzer beschreibt im Issue einen solchen Hook). Durchsuchen Sie danach Ihre Server-Logs nach User-Agent-Headern mit einer E-Mail-Adresse, dann sehen Sie, was Agenten an Ihre Websites senden.

#Welche Zugangsdaten bekommt ein KI-Agent bei WordPress, WooCommerce, Shopify und Cloudflare?

Jede dieser Plattformen kann Zugangsdaten ausstellen, die weniger dürfen als Ihr eigenes Login. Nutzen Sie das, und legen Sie die Zugangsdaten nur für den Agenten an, damit Sie sie widerrufen können, ohne sich selbst auszusperren.

Unter WordPress übernimmt die Rolle die Begrenzung. Die Dokumentation zu Rollen beschreibt einen Administrator als jemanden mit Zugriff auf alle Verwaltungsfunktionen einer Website und einen Redakteur als jemanden, der Beiträge veröffentlichen und verwalten kann, auch die anderer Benutzer. Ein Agent, der über die REST-API Inhalte bearbeitet, braucht höchstens die Rolle Redakteur. Ein Agent mit einem Administrator-Passwort hat jede Verwaltungsfunktion, einschließlich der Installation von Plugins, und ein Plugin ist PHP-Code, der auf Ihrem Server läuft.

Bei Shopify hat die CLI eine Schutzvorrichtung, die ein Agent nie aufheben dürfen sollte. Die Referenz zu theme push sagt, --allow-live sei “in nicht interaktiven Umgebungen erforderlich, wenn das Live-Theme das Ziel ist”, und --publish schaltet das hochgeladene Theme live (eigene Übersetzung). Ein Agent läuft nicht interaktiv, also hält ihn eine Sperrregel für beide Optionen auf unveröffentlichten Themes. shopify theme push --unpublished legt ein neues unveröffentlichtes Theme an und lädt dorthin hoch; das ist das Ziel, das Sie dem Agenten stattdessen geben.

#Was hat der KI-Agent geändert? Änderungen richtig prüfen

Lesen Sie die Änderungen, bevor irgendetwas in die Produktion geht. git diff --stat zeigt, welche Dateien betroffen sind; hat ein Agent, der einen Link im Footer reparieren sollte, vierzig Dateien angefasst, hat er noch etwas anderes getan. Lesen Sie danach den vollständigen git diff jeder Datei. Achten Sie auf:

• abgeschaltete Prüfungen: eine auskommentierte Nonce-Prüfung, eine Capability-Prüfung, die durch is_admin() ersetzt wurde, ein Test, der gelöscht wurde, “weil er fehlschlug”;
• neue Abhängigkeiten, Plugins oder Composer-Pakete, um die niemand gebeten hat;
• Geheimnisse oder API-Schlüssel, die in den Code kopiert wurden;
• Änderungen an Datenbankmigrationen, .htaccess, Weiterleitungen oder robots.txt.

Vergleichen Sie unter WordPress wp plugin list und wp option get active_plugins vorher und nachher: Manche Änderungen liegen in der Datenbank, nicht in Dateien. Für Plugin-Code, den der Agent geschrieben hat, geht unsere Checkliste zur Prüfung von KI-generiertem WordPress-Plugin-Code acht typische Fehler durch.

#Funktioniert die Änderung des Agenten wirklich? So testen Sie selbst

Wenn der Agent “fertig, getestet, alles funktioniert” meldet, ist das ein Bericht, kein Beweis. Ein Test, den der Agent für sich selbst geschrieben hat, kann aus dem falschen Grund bestehen. Führen Sie eigene Prüfungen durch:

Ein als [PROMO] markierter Beitrag auf r/Wordpress, geschrieben vom Hersteller eines A/B-Test-Plugins, der dafür Agenten-Skills bewarb, trug den Titel: “Claude hat Änderungen an meiner WordPress-Website so einfach gemacht, dass ich aufgehört habe zu prüfen, ob sie überhaupt funktionieren”. Eine der Antworten:

‘Ich habe aufgehört zu prüfen, ob meine Änderungen überhaupt funktionieren’ ist genau der Weg, auf dem wir in einem großen Teil des Schlamassels gelandet sind, in dem wir gerade stehen. Vertrauen, klar, wenn man will, aber prüfen.

(u/SoItBegins_n, r/Wordpress, 22. Oktober 2026, eigene Übersetzung)

1. curl -sI auf jede geänderte URL und auf die Startseite: Statuscode, Weiterleitungen, Cache-Header.
2. Das PHP-Fehlerprotokoll oder die Browserkonsole auf denselben Seiten.
3. Ein echtes Absenden jedes Formulars und in einem Shop eine Testbestellung durch den Checkout.
4. Die Seite auf einem Smartphone, nicht nur im Headless-Browser des Agenten.
5. Bei SEO-relevanten Änderungen: gerenderter Title, Canonical und robots-Meta-Tag, denn Agenten bearbeiten die Templates, die diese ausgeben.

Machen Sie das in der Testumgebung und gleich nach der Veröffentlichung noch einmal in der Produktion. Schlägt dort etwas fehl, stellen Sie zuerst wieder her und suchen danach den Fehler.

#Agent meldet Erfolg, aber die Website zeigt etwas anderes: woran liegt es?

#Der KI-Agent hat Spaghetticode hinterlassen: was tun?

Die Anzeichen sind bekannt: dieselbe Funktion in drei Dateien, Korrekturen auf Korrekturen, ein Plugin für jede Kleinigkeit, Inline-Styles, weil der Agent das Stylesheet nicht gefunden hat. Bitten Sie nicht denselben Agenten, auf der Live-Website “alles aufzuräumen”; das vervielfacht die Änderungen, die Sie prüfen müssen. Frieren Sie den aktuellen Stand in Git ein, schreiben Sie auf, was die Website leisten muss, und entscheiden Sie pro Bereich, ob Sie umbauen oder neu bauen.

Ein Einsteiger, der 20 Jahre nicht programmiert hatte, beschrieb auf r/Wordpress zwei Wochen mit Codex als “Albtraumschleife: kaputt machen, flicken, wieder kaputt machen und wieder flicken” (Thread, 21. Oktober 2026, eigene Übersetzung). Eine Antwort nannte den Ausweg:

Codex für kleine, überprüfbare Änderungen in der Testumgebung nutzen, nicht für offene Umbauten der Live-Website.

(u/NakanoNoNeko, r/Wordpress, 22. Oktober 2026, eigene Übersetzung)

Unser Artikel zu Vibecoding und WordPress erklärt, warum von KI gebaute Websites schwer zu warten sind. Wenn Sie das lieber abgeben möchten, übernimmt unsere Rettung KI-erstellter Websites die Website ab diesem Punkt, und ein Wartungsplan hält Testumgebung, Sicherungen und Update-Prüfungen danach am Laufen. Wenn Agenten dauerhaft zu Ihrem Arbeitsablauf gehören sollen, umfasst die KI-Implementierung die Einrichtung von Berechtigungen, Tokens und Prüfschritten.

#Wie läuft eine Sitzung mit einem KI-Agenten in der WordPress-Testumgebung ab? Ein Beispiel

Aufgabe: ein Newsletter-Formular von der Seitenleiste in den Footer einer WordPress-Website verschieben, deren eigenes Theme in Git liegt. Der folgende Ablauf nutzt nur die oben beschriebenen Werkzeuge.

1. In der Testumgebung git tag before-agent im Theme-Repository und wp db export before-agent.sql für die Datenbank.
2. Claude Code im Modus plan starten und um einen Plan bitten. Lesen Sie ihn. Erwähnt der Plan für eine Änderung am Footer Plugins, die Datenbank oder Dateien außerhalb des Themes, halten Sie an und fragen nach dem Grund.
3. Auf acceptEdits umschalten, mit den deny- und ask-Regeln von oben und eingeschalteter Sandbox. Der Agent bearbeitet Theme-Dateien; jeder wp-Befehl fragt weiterhin bei Ihnen nach.
4. Wenn er fertig ist: git diff --stat. Zwei Vorlagendateien und ein Stylesheet sind für diese Aufgabe plausibel. Alles in functions.php, was neue Skripte registriert, lesen Sie vollständig.
5. Selbst prüfen: das Formular in der Testumgebung absenden, bestätigen, dass der neue Abonnent im Newsletter-Werkzeug ankommt, den Footer auf einem Smartphone ansehen und das PHP-Fehlerprotokoll per grep nach neuen Einträgen durchsuchen.
6. Das Theme selbst zusammenführen und veröffentlichen. Dieselben fünf Prüfungen in der Produktion wiederholen.
7. Schlägt in der Produktion etwas fehl: die Zusammenführung mit git revert rückgängig machen oder den Tag before-agent erneut veröffentlichen. Die Datenbank wurde nicht angefasst, sie braucht also keine Wiederherstellung. Wäre sie angefasst worden, wäre wp db import before-agent.sql der Schritt gewesen, und der hätte vorher in der Testumgebung funktionieren müssen.

Den Code in Schritt 3 hat der Agent geschrieben. Jeder Schritt, der die Produktion berührte, lag bei Ihnen.

#Welche Rechte bekommt der Agent in welcher Phase?

Der Agent tippt. Den Schritt in die Produktion machen Sie selbst.