Oxygen 6.2: Der WordPress-Builder, den dein KI-Agent bedient

Oxygen 6.2 öffnet den Builder für KI-Agenten: MCP-Server, Abilities API, Templates, Design-System und Interaktionen per Auftrag. Was drinsteckt, was der Changelog verrät und wo ich vorsichtig wäre.

von ·

Sechs der WordPress-Plugins, die ich hier dokumentiere, sprechen inzwischen mit KI-Agenten — und alle sechs tun das ausschließlich lesend. JPKCom Post Filter verrät einem Assistenten, welche Taxonomien und Terme es wirklich gibt, JPKCom Simple Lang zeigt ihm das Sprach-Setup einer Site, JPKCom Gutenberg Image Block Alt-Attribute meldet Bilder, für die das Plugin keinen Alt-Text einsetzen kann. Schreiben darf über diese Schnittstellen niemand: Ein Agent kann die Site damit verstehen, aber nicht verändern.

Oxygen 6.2 geht den umgekehrten Weg, und zwar mit voller Konsequenz. Der Untertitel der Ankündigung (öffnet in neuem Tab) (englisch) lautet „Agent Connector, an MCP server, and full support for the WordPress Abilities API", die Überschrift „build WordPress sites by talking to your agent". Dein KI-Agent baut Seiten, Templates, Header, Footer und Komponenten, verdrahtet Custom Fields, programmiert Interaktionen und Animationen — und alles, was er anlegt, bleibt im Canvas des Builders editierbar.

Weil ich selbst Plugins mit Oxygen-Integration pflege — Post Filter bringt eigene Oxygen-Elemente mit, Simple Lang eigene Oxygen-Bedingungen —, habe ich mir die Ankündigung, den vollständigen Changelog und den Quellcode des Agent Connectors genauer angesehen. In diesem Artikel erfährst du, was 6.2 wirklich kann, was im Changelog zwischen den Zeilen steht und an welcher Stelle ich deutlich vorsichtiger wäre, als die Ankündigung klingt.

Die Kurzfassung

Frage Antwort
Ist Oxygen 6.2 fertig? Noch nicht ganz: Stand 11. Oktober 2026 ist 6.2 RC 1 vom 30. September 2026 der aktuelle Build — trotz „Is Now Available" im Titel
Was ist neu? Ein MCP-Server, über den KI-Agenten den Builder bedienen: Seiten, Templates, Komponenten, Design-System, dynamische Daten, Interaktionen, Animationen, Formulare
Welche Agenten? Laut Soflyy MCP-fähige Clients wie Claude, Codex, Cursor, Windsurf, Cline und Gemini CLI
Wie verbunden? Über das separate, kostenlose Plugin Agent Connector for WP, das auf der offiziellen WordPress-Infrastruktur (Abilities API, wordpress/mcp-adapter) aufsetzt
Welche Rechte hat der Agent? Die eines Super-Admins — das ist fest eingebaut und nicht einstellbar
Was kostet es? Oxygen selbst derzeit einmalig 199,50 US-Dollar für beliebig viele Sites; den Agenten bringst du selbst mit

Erst der Status: Release Candidate, nicht Release

Die Ankündigung trägt den Titel „Oxygen 6.2 Is Now Available", erschienen ist sie aber schon am 20. Juli 2026 — als Beitrag zur Beta 1. Soflyy hat sie seitdem mit jedem Build fortgeschrieben, von Beta 1 bis Beta 9 und schließlich bis zum Release Candidate 1 vom 30. September. Der Statuskasten oben im Beitrag sagt es auch ausdrücklich: „Status: Release Candidate".

Im eigenen Beitrag zum RC 1 (öffnet in neuem Tab) (englisch) schreibt Soflyy, die Features seien fertig und das sei, was als finale 6.2 erscheine, sofern die Tests kein blockierendes Problem zutage fördern — und empfiehlt, den RC zuerst auf einer Staging-Site zu testen. Diese Empfehlung würde ich ernst nehmen, und für die neuen Agent-Funktionen gilt sie doppelt, wie du weiter unten siehst.

Zur Einordnung der Versionen: Oxygen 6 ist nicht der Nachfolger des klassischen Oxygen im Sinne eines Updates, sondern ein Neubau auf demselben Builder-Kern wie das Schwesterprodukt Breakdance. Die finale 6.0 erschien im Februar 2026, 6.1 im Frühsommer. Das klassische Oxygen (4.x) wird parallel weiter gepflegt, ist aber nicht kompatibel mit 6 — Soflyy nennt den Bruch in der Launch-FAQ (öffnet in neuem Tab) (englisch) die schwerste Entscheidung, die das Team je getroffen habe. Das betrifft auch meine eigenen Plugins: Die Oxygen-Elemente von Post Filter sind über die OxyEl-API für das klassische Oxygen gebaut. Alles, was in diesem Artikel über Agenten steht, gilt dagegen nur für Oxygen 6.

Was ein Agent in Oxygen 6.2 darf

Verbunden wird unter Oxygen → Settings → Agents & MCP. Danach liest der Agent die Site und nutzt Oxygens eigene Werkzeuge, um sie zu verändern. Die Ankündigung zählt auf, was dazugehört:

  • Seiten, Templates und Komponenten: WordPress-Seiten anlegen und im Builder aufbauen, die Startseite festlegen, Content-Templates, Header und Footer bauen, ihre Anzeigebedingungen setzen und wiederverwendbare Komponenten erstellen.
  • Design-System: Bevor der Agent stylt, kann er die vorhandenen Breakpoints, Selektoren und CSS-Variablen lesen und weiterverwenden. Neue soll er erst anlegen, wenn das Design etwas braucht, das es noch nicht gibt.
  • Dynamische Daten: Oxygen zeigt dem Agenten alle registrierten Datenfelder, inklusive ACF und Meta Box. Er kann Element-Eigenschaften daran binden, Repeater und Posts Loops mit Query konfigurieren und die Komponente für jedes Ergebnis bauen.
  • Interaktionen: Auslöser (Klick, Hover, Tastendruck, Sichtbarwerden beim Scrollen, Seitenaufruf, Scrollen) mit Aktionen verbinden — Elemente ein- und ausblenden, Klassen umschalten, Attribute setzen, zu Abschnitten scrollen, den Fokus verwalten oder eine eigene JavaScript-Funktion aufrufen. Laut Soflyy reicht das für mobile Menüs, Popups und Toggles ohne eigenes JavaScript.
  • Animationen: Einblendungen (Fades, Slides, Flips, Zooms) und scrollgesteuerte Animationen über Keyframes, dazu Sticky-Positionierung.
  • Formulare: Mit dem Add-on Breakdance Forms for Oxygen baut der Agent Formulare samt Aktionen nach dem Absenden — E-Mail, Speichern in WordPress oder Webhook.

Den wichtigsten Satz der Ankündigung finde ich nicht in dieser Liste, sondern im Teaser: Alles, was der Agent baut, bleibt im Canvas voll editierbar. Der Agent erzeugt also kein HTML, das neben dem Builder herläuft, sondern arbeitet im Datenmodell des Builders. Das ist der Unterschied zwischen einem Werkzeug, das dir eine Seite generiert, und einem, das dir eine Seite anlegt, die du danach selbst weiterpflegst.

Der Punkt, der mich am meisten überzeugt: das vorhandene Design-System

Die meisten KI-generierten Websites scheitern nicht am Layout, sondern an der Konsistenz. Jede neue Seite bekommt ihre eigenen Farbwerte, ihre eigenen Abstände, ihre eigenen Klassen — und nach drei Durchläufen hast du drei Design-Systeme nebeneinander. Genau das adressiert Oxygen, indem der Agent erst lesen und dann stylen kann: vorhandene Selektoren wiederverwenden, CSS-Variablen auf Farben, Abstände und Typografie anwenden, „instead of creating a parallel design system".

Ich halte das für die richtige Richtung, weil es dasselbe Prinzip ist, das ich bei dieser Seite mit einer DESIGN.md verfolge: Design-Entscheidungen stehen an einer Stelle, die auch die KI liest, und neue Farben entstehen nicht beiläufig in einem einzelnen Element. Der Changelog zeigt, dass Soflyy daran über alle Betas gefeilt hat: Seit Beta 3 bekommen Agenten pro Site ein stabiles CSS-Klassenpräfix, seit Beta 8 können Variablen pro Breakpoint unterschiedliche Werte haben, und der CSS-Importer erkennt moderne Farbfunktionen wie oklch() und color-mix() als Farbvariablen.

Was das in der Praxis taugt, hängt allerdings an dir: Ein Agent kann nur das Design-System weiterverwenden, das es in der Site schon gibt. Auf einer Site, deren Stile direkt an Elementen hängen statt an Selektoren und Variablen, hat er nichts, woran er sich halten könnte.

Was der Changelog über die Praxis verrät

Die Feature-Liste der Ankündigung ist Marketing. Der Changelog darunter ist ehrlicher, weil er zeigt, woran in zehn Builds gearbeitet wurde. Ein paar Einträge sind für die Arbeit mit Agenten besonders aufschlussreich:

  • Selbstkontrolle: Seit Beta 3 gibt es die Werkzeuge preview-post und preview-element, mit denen ein Agent seine Arbeit rendern und prüfen kann. Ohne so etwas baut ein Agent blind.
  • Semantisches HTML: Ebenfalls seit Beta 3 kennen die Element-Schemata HTML-Tags, damit Agenten Container als <section>, <header> oder <nav> anlegen können. Beta 7 ergänzt Wrapper-Tags wie ul, nav oder article für Loops. Ob ein Agent das nutzt, ist eine andere Frage — aber ohne diese Option würde er zwangsläufig <div>-Suppe produzieren.
  • Gleichzeitige Agenten: Im RC 1 steht: „Parallel agent calls no longer overwrite each other's changes to CSS selectors, variables, and global settings." Bis dahin konnten sich parallel arbeitende Agenten also gegenseitig Änderungen überschreiben. Gut, dass es behoben ist — und ein Hinweis darauf, wie neu dieses Terrain ist.
  • Kontextbudget: Beta 6 hat die Schemata der MCP-Werkzeuge um etwa 35 Prozent verkleinert. Das klingt nach Detail, ist aber für jeden relevant, der mit Agenten arbeitet: Werkzeugbeschreibungen kosten Kontext, und Kontext ist bei Agenten die knappste Ressource.
  • Anleitungen für den Agenten: Das neue Werkzeug get-skill liefert Schritt-für-Schritt-Anleitungen für Sites, Templates, Mega-Menüs und WooCommerce-Shops, dazu eine Bibliothek von Layout-Mustern.
  • Grenzen: Das neue run-site-tool darf den CSS-Cache neu erzeugen, Verzeichnisse anlegen, URLs ersetzen, Einstellungen exportieren und importieren und einen Soft Reset auslösen — den „Total Reset" überlässt es ausdrücklich dem Admin-Bereich. Harmlos ist das trotzdem nicht: Ein Import überschreibt die Einstellungen, und der Soft Reset löscht laut Doku selbst hochgeladene Icon-Sets. Die Design-Library-Werkzeuge sind standardmäßig abgeschaltet.
  • Barrierefreiheit im Builder selbst: Beta 4 hat Toolbar, Panels und Strukturbaum mit ARIA-Rollen und -Labels versehen. Das hat mit Agenten nichts zu tun, freut mich aber trotzdem.

Ein Eintrag aus Beta 7 verdient eigene Erwähnung: „Fixed an access control issue in the Design Library import flow (the security fix from Oxygen 6.1.2)". Laut dem Sicherheitsupdate 6.1.2 (öffnet in neuem Tab) (englisch) waren drei Import-Endpunkte der Design Library ohne Anmeldung erreichbar, gefunden bei einem internen Audit. Dass Soflyy das offen dokumentiert, spricht für sie. Es zeigt aber auch: Je mehr Schnittstellen ein Builder nach außen öffnet, desto mehr Fläche gibt es, auf der so etwas passieren kann.

Dazu kommt WebMCP, seit Beta 3 als experimentelle Funktion: Agenten, die direkt im Browser laufen, sollen die gerade im Builder geöffnete Seite bearbeiten können. Soflyy schreibt selbst, dass Browser- und Agent-Unterstützung noch begrenzt sind. Das passt zum Stand des Standards: WebMCP (öffnet in neuem Tab) (englisch) ist ein Entwurf der W3C Web Machine Learning Community Group und ausdrücklich kein W3C-Standard; Chrome testet ihn als Origin Trial ab Chrome 149 (öffnet in neuem Tab) (englisch). Für den Alltag würde ich das noch nicht einplanen.

Wo ich vorsichtig wäre: Der Agent ist Super-Admin

Die Ankündigung erklärt, was ein Agent kann. Wie er sich anmeldet und mit welchen Rechten er arbeitet, steht dort nicht. Das steht im Agent Connector, und den solltest du kennen, bevor du ihn installierst.

Agent Connector for WP ist ein eigenes, kostenloses Plugin von Soflyy (GPL, Quellcode auf GitHub (öffnet in neuem Tab)), das Oxygen auf Knopfdruck nachinstalliert. Es betreibt den MCP-Server direkt in deiner WordPress-Installation und bündelt dafür das offizielle Paket wordpress/mcp-adapter (öffnet in neuem Tab). Architektonisch ist das sauber: Statt eines eigenen Protokolls nutzt Soflyy die Bausteine, die das WordPress-Projekt selbst für KI-Anbindungen entwickelt — dieselbe Abilities API, auf der auch meine Plugins aufsetzen. Vorausgesetzt werden WordPress 7.0 und PHP 8.1. Angemeldet wird per OAuth oder, etwa auf lokalen Sites, per Anwendungspasswort über einen kleinen lokalen Proxy.

Die Rechtefrage beantwortet die README unmissverständlich. Ausgeführt werden Abilities immer nur mit Super-Admin-Rechten, das ist erzwungen und nicht einstellbar, und ein verbundener Agent kann alles, was ein Super-Admin kann. Das Zugangspasswort sollst du deshalb „like an SSH key" behandeln. Die GitHub-Beschreibung des Projekts ist noch deutlicher: „Give agents unrestricted execution capability on WordPress (shell, PHP eval, filesystem, process) via the WordPress MCP stack. Trusted dev environments only."

Fairerweise gehört dazu: Die direkten Systemzugriffe — Shell-Befehle, PHP-Eval, Dateien lesen und schreiben, WP-CLI — stecken im separaten Zusatz-Plugin Universal Abilities, das Oxygen standardmäßig nicht mitinstalliert. Ohne es stellt der Connector nur die Abilities bereit, die andere Plugins registrieren, also etwa Oxygens Builder-Werkzeuge. Aber auch die verändern deine Site — und weil Oxygen ein PHP-Code-Element kennt, das serverseitig ausgeführten Code in eine Seite bringt, würde ich mich nicht darauf verlassen, dass ein Agent ohne Universal Abilities keinen Code ausführen kann. Die Schutzmechanismen sind zudem fast alle Opt-in: und die Schutzmechanismen sind fast alle Opt-in:

  • Auf einer Produktivumgebung zeigt das Plugin einen roten Warnhinweis an — mehr nicht. Den Betrieb auf Produktion blockieren musst du selbst einschalten.
  • Der Domain-Lock, der verhindert, dass eine auf eine andere Domain kopierte Datenbank samt Zugangsdaten dort Zugriff gewährt, ist ebenfalls aus, bis du ihn aktivierst.
  • Das Audit-Log, das jede ausgeführte Ability mit Benutzer, IP und einer Zusammenfassung der Eingabe protokolliert, schreibt nur, wenn du eine Konstante in der wp-config.php definierst.

Für eine Entwicklungsumgebung ist das eine vernünftige Voreinstellung. Für eine Produktivsite mit Kundendaten im WooCommerce-Backend ist es keine. Ob ein Agent mit Super-Admin-Rechten auf einer Live-Site arbeiten soll, ist keine Frage der Technik, sondern eine der Verantwortung — und ich würde sie für die allermeisten Projekte mit Nein beantworten.

So würde ich Oxygen 6.2 mit einem Agenten einsetzen

Ich halte das Feature trotzdem für einen echten Fortschritt — vorausgesetzt, du ziehst die Grenzen selbst, statt dich auf die Voreinstellungen zu verlassen:

  1. Nur auf Staging oder lokal. Der Agent baut auf einer Kopie, du prüfst, und erst dann gehen Änderungen auf die Live-Site. Das empfiehlt Soflyy für den RC ohnehin, und die Projektbeschreibung des Connectors sagt dasselbe für den Agent-Zugang.
  2. Schutzmechanismen einschalten. „Block on production environments" und Domain-Lock aktivieren, das Audit-Log per Konstante außerhalb des Web-Roots anlegen. Prüfe außerdem, ob wp_get_environment_type() auf deiner Staging-Site wirklich staging meldet — ohne Konfiguration gilt jede Installation als production.
  3. Universal Abilities weglassen, solange du keinen konkreten Grund hast. Für das Bauen von Seiten braucht der Agent keine Shell.
  4. Erst das Design-System, dann den Agenten. Selektoren, CSS-Variablen und Breakpoints anlegen, bevor der Agent loslegt — sonst erfindet er sie.
  5. Ergebnisse wie fremden Code reviewen. Semantik, Überschriftenhierarchie, Alt-Texte, Fokusreihenfolge bei Interaktionen, Kontraste. Ein Agent, der ein mobiles Menü „ohne eigenes JavaScript" verdrahtet, hat damit noch kein barrierefreies Menü gebaut. Wie ich KI-Ergebnisse grundsätzlich prüfe, steht in Wer prüft den Prüfer?.
  6. Zugang wieder entziehen. Anwendungspasswörter und OAuth-Verbindungen nach der Arbeit widerrufen, nicht für immer stehen lassen.

Für wen sich das lohnt

Am meisten profitierst du, wenn du ohnehin mit Oxygen 6 arbeitest und wiederkehrende Strukturen baust: Archiv-Templates mit Loops und Custom Fields, Landingpages nach festem Muster, WooCommerce-Templates. Dort spart ein Agent, der das Design-System kennt, echte Handarbeit — und weil das Ergebnis im Builder editierbar bleibt, kannst du jederzeit übernehmen.

Wenig ändert sich, wenn du noch auf dem klassischen Oxygen bist: Der Umstieg auf 6 ist ein Neubau, kein Update, und dafür ist ein KI-Feature allein kein ausreichender Grund. Und wenn du WordPress-Sites ohne Builder baust, ist 6.2 vor allem ein Signal: Soflyy setzt auf die offizielle Abilities API und den MCP-Adapter des WordPress-Projekts. Je mehr große Plugins das tun, desto eher wird die Abilities API zum Standardweg, über den KI-Agenten mit WordPress reden. Meine eigenen Plugins setzen schon darauf auf — vorerst eben nur lesend.

Zum Preis: Oxygen kostet derzeit einmalig 199,50 US-Dollar für beliebig viele Sites, ohne Verlängerung, die Agent-Werkzeuge sind enthalten; der Bestelllink trägt allerdings einen Rabattcode, der Preis ist also ein Aktionspreis. Der Agent selbst ist nicht enthalten: Laut Preisseite bringst du deinen eigenen mit, Soflyy verkauft keine KI-Guthaben weiter.

Das Schwesterprodukt Breakdance bekommt dieselben Funktionen mit Version 3.0, die ebenfalls im Release-Candidate-Stadium ist — mit einem Unterschied, den du kennen solltest: Der neue Einrichtungsassistent aus Breakdance 3.0 RC 2 (öffnet in neuem Tab) (englisch) installiert und aktiviert mit einem Klick Agent Connector und Universal Abilities. Dort bekommt der Agent Shell, PHP-Eval und Dateisystem also gleich mit, wenn du dem Assistenten einfach folgst.

FAQ

Ist Oxygen 6.2 schon als stabile Version erschienen?

Stand 11. Oktober 2026 nein. Der aktuelle Build ist 6.2 RC 1 vom 30. September 2026. Soflyy hat angekündigt, dass dieser Stand als finale 6.2 erscheint, sofern die Tests kein blockierendes Problem finden, und empfiehlt bis dahin, auf einer Staging-Site zu testen.

Funktionieren die Agent-Funktionen auch mit dem klassischen Oxygen?

Nein. Die Agent-Werkzeuge gehören zu Oxygen 6, das auf dem Kern von Breakdance neu gebaut wurde. Das klassische Oxygen 4.x wird zwar weiter gepflegt, ist aber eine eigenständige Produktlinie und mit Oxygen 6 nicht kompatibel.

Welche KI-Agenten kann ich verbinden?

Jeden Client, der das Model Context Protocol spricht. Soflyy nennt Claude, Codex, Cursor, Windsurf, Cline und Gemini CLI. Der Agent Connector bringt für viele weitere Clients Einrichtungsanleitungen mit. Wichtig: Ein Agent, der in der Cloud läuft, kann eine Site auf deinem lokalen Rechner nicht erreichen.

Welche Rechte hat ein verbundener Agent?

Die eines Super-Admins — auf einer Einzelsite also die eines Administrators. Das ist im Agent Connector fest verankert und lässt sich nicht herabsetzen. Direkte Shell-, PHP-Eval- und Dateisystem-Abilities kommen erst mit dem optionalen Zusatz-Plugin Universal Abilities dazu, das Oxygen nicht mitinstalliert — der Einrichtungsassistent von Breakdance 3.0 dagegen schon.

Kann ich die Agent-Funktionen abschalten?

Ja. Unter Oxygen → Settings → Agents & MCP lässt sich die Option „Allow agents to access this site over MCP" abwählen; dann stellt Oxygen seine Werkzeuge nicht mehr bereit, ohne dass du den Agent Connector deaktivieren musst. Ganz ohne KI-Anbindung bist du, wenn du den Agent Connector gar nicht erst installierst.

Weiterlesen

Wie ein Design-System aussieht, das Mensch und KI gleichermaßen lesen, steht in DESIGN.md: Das Design-System als Datei, die auch die KI liest. Wie ich KI-Ergebnisse prüfe, bevor sie online gehen, beschreibt Wer prüft den Prüfer?; wie ich meinen eigenen Agenten konfiguriere, Claude Code richtig konfigurieren. Lesende Abilities in der Praxis zeigen die Anleitungen zu JPKCom Post Filter, JPKCom Simple Lang und JPKCom ACF Jobs.

Soflyys Originalquellen: die Ankündigung zu Oxygen 6.2 (öffnet in neuem Tab) mit vollständigem Changelog, der Beitrag zum RC 1 (öffnet in neuem Tab) und das Repository des Agent Connectors (öffnet in neuem Tab) mit README und Schutzmechanismen.