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.

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

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

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.

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

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

#Welche Rechte bekommt der Agent in welcher Phase?

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