Oxygen 6.2: The WordPress Builder Your AI Agent Operates
Oxygen 6.2 opens the builder to AI agents: an MCP server, the Abilities API, templates, design system and interactions on request. What is in it, what the changelog reveals, and where I would be careful.
by Jean Pierre Kolb ·
Six of the WordPress plugins I document here now talk to AI agents — and all six do so strictly read-only. JPKCom Post Filter tells an assistant which taxonomies and terms actually exist, JPKCom Simple Lang shows it a site's language setup, JPKCom Gutenberg Image Block Alt-Attribute reports images the plugin has no alt text to inject for. Nobody gets to write through these interfaces: an agent can understand the site with them, but not change it.
Oxygen 6.2 goes the opposite way, and goes all the way. The subtitle of the announcement (opens in a new tab) reads "Agent Connector, an MCP server, and full support for the WordPress Abilities API", the headline "build WordPress sites by talking to your agent". Your AI agent builds pages, templates, headers, footers and components, wires up custom fields, programs interactions and animations — and everything it creates stays editable in the builder canvas.
Because I maintain plugins with Oxygen integrations myself — Post Filter ships its own Oxygen elements, Simple Lang its own Oxygen conditions — I took a closer look at the announcement, the full changelog and the source code of the Agent Connector. In this article you will find out what 6.2 really does, what the changelog says between the lines, and where I would be considerably more careful than the announcement sounds.
The short version
| Question | Answer |
|---|---|
| Is Oxygen 6.2 finished? | Not quite: as of 11 October 2026 the current build is 6.2 RC 1 from 30 September 2026 — despite "Is Now Available" in the title |
| What is new? | An MCP server through which AI agents operate the builder: pages, templates, components, design system, dynamic data, interactions, animations, forms |
| Which agents? | According to Soflyy, MCP-capable clients such as Claude, Codex, Cursor, Windsurf, Cline and Gemini CLI |
| How do they connect? | Through the separate, free plugin Agent Connector for WP, which builds on the official WordPress infrastructure (Abilities API, wordpress/mcp-adapter) |
| What rights does the agent have? | Those of a super admin — that is built in and not configurable |
| What does it cost? | Oxygen itself is currently a one-time 199.50 US dollars for unlimited sites; you bring your own agent |
Status first: release candidate, not release
The announcement is titled "Oxygen 6.2 Is Now Available", but it was published back on 20 July 2026 — as the post for Beta 1. Soflyy has kept updating it with every build since, from Beta 1 through Beta 9 and finally to Release Candidate 1 from 30 September. The status box at the top of the post says so explicitly: "Status: Release Candidate".
In its own post on RC 1 (opens in a new tab), Soflyy writes that the features are done and that this is what will ship as the final 6.2 unless testing turns up a blocking issue — and recommends trying the RC on a staging site first. I would take that recommendation seriously, and for the new agent features it applies twice over, as you will see below.
For context on the versions: Oxygen 6 is not the successor to classic Oxygen in the sense of an update, but a rebuild on the same builder core as its sister product Breakdance. The final 6.0 shipped in February 2026, 6.1 in early summer. Classic Oxygen (4.x) is still maintained alongside it, but it is not compatible with 6 — Soflyy calls the break the hardest decision the team has ever made in its launch FAQ (opens in a new tab). That affects my own plugins too: Post Filter's Oxygen elements are built on the OxyEl API for classic Oxygen. Everything this article says about agents, on the other hand, applies only to Oxygen 6.
What an agent may do in Oxygen 6.2
You connect under Oxygen → Settings → Agents & MCP. From then on the agent reads the site and uses Oxygen's own tools to change it. The announcement lists what that covers:
- Pages, templates and components: create WordPress pages and build them in the builder, set the homepage, build content templates, headers and footers, set their display conditions and create reusable components.
- Design system: before styling anything, the agent can read the existing breakpoints, selectors and CSS variables and reuse them. It is meant to create new ones only when the design needs something that does not exist yet.
- Dynamic data: Oxygen shows the agent every registered data field, including ACF and Meta Box. It can bind element properties to them, configure repeaters and posts loops with a query and build the component for each result.
- Interactions: connect triggers (click, hover, key press, scrolling into view, page load, page scroll) to actions — show and hide elements, toggle classes, set attributes, scroll to sections, manage focus or call a custom JavaScript function. According to Soflyy that is enough for mobile menus, popups and toggles without custom JavaScript.
- Animations: entrance animations (fades, slides, flips, zooms) and scroll-driven animations across keyframes, plus sticky positioning.
- Forms: with the Breakdance Forms for Oxygen add-on, the agent builds forms including the actions after submission — email, storing in WordPress or a webhook.
The most important sentence of the announcement is not in that list but in the teaser: everything the agent builds stays fully editable in the canvas. So the agent does not produce HTML that runs alongside the builder; it works in the builder's data model. That is the difference between a tool that generates a page for you and one that creates a page you then keep maintaining yourself.
The point that convinces me most: the existing design system
Most AI-generated websites do not fail at layout but at consistency. Every new page gets its own colour values, its own spacing, its own classes — and after three runs you have three design systems side by side. That is exactly what Oxygen addresses by letting the agent read first and style second: reuse existing selectors, apply CSS variables to colour, spacing and typography, "instead of creating a parallel design system".
I think that is the right direction, because it is the same principle I follow on this site with a DESIGN.md: design decisions live in one place that the AI reads as well, and new colours do not come into being in passing on a single element. The changelog shows that Soflyy refined this across all the betas: since Beta 3 agents get one stable CSS class prefix per site, since Beta 8 variables can have different values per breakpoint, and the CSS importer recognises modern colour functions such as oklch() and color-mix() as colour variables.
How useful that is in practice depends on you, though: an agent can only reuse the design system that already exists in the site. On a site whose styles hang directly on elements instead of on selectors and variables, it has nothing to hold on to.
What the changelog reveals about practice
The feature list in the announcement is marketing. The changelog below it is more honest, because it shows what ten builds were spent on. A few entries are particularly revealing for working with agents:
- Self-checking: since Beta 3 there are the
preview-postandpreview-elementtools, with which an agent can render and verify its own work. Without something like that, an agent builds blind. - Semantic HTML: also since Beta 3, the element schemas know HTML tags, so agents can create containers as
<section>,<header>or<nav>. Beta 7 adds wrapper tags such asul,navorarticlefor loops. Whether an agent uses them is another question — but without the option it would inevitably produce<div>soup. - Concurrent agents: RC 1 says: "Parallel agent calls no longer overwrite each other's changes to CSS selectors, variables, and global settings." Until then, agents working in parallel could overwrite each other's changes. Good that it is fixed — and a sign of how new this territory is.
- Context budget: Beta 6 shrank the MCP tool schemas by about 35 percent. That sounds like a detail, but it matters to anyone working with agents: tool descriptions cost context, and context is the scarcest resource an agent has.
- Instructions for the agent: the new
get-skilltool provides step-by-step skills for sites, templates, mega menus and WooCommerce stores, plus a library of layout patterns. - Limits: the new
run-site-toolmay regenerate the CSS cache, create directories, replace URLs, export and import settings and trigger a soft reset — it explicitly leaves the "Total Reset" to wp-admin. That is still not harmless: an import overwrites the settings, and according to the docs the soft reset deletes icon sets you uploaded yourself. The Design Library tools are switched off by default. - Accessibility in the builder itself: Beta 4 added ARIA roles and labels to the toolbar, panels and structure tree. That has nothing to do with agents, but I am glad to see it all the same.
One entry from Beta 7 deserves a mention of its own: "Fixed an access control issue in the Design Library import flow (the security fix from Oxygen 6.1.2)". According to the 6.1.2 security update (opens in a new tab), three Design Library import endpoints were reachable without authentication, found during an internal audit. That Soflyy documents this openly speaks for them. But it also shows: the more interfaces a builder opens to the outside, the more surface there is for something like this to happen.
Then there is WebMCP, experimental since Beta 3: agents running directly in the browser are meant to be able to edit the page currently open in the builder. Soflyy itself writes that browser and agent support is still limited. That matches the state of the standard: WebMCP (opens in a new tab) is a draft of the W3C Web Machine Learning Community Group and explicitly not a W3C standard; Chrome is testing it as an origin trial from Chrome 149 (opens in a new tab). I would not plan day-to-day work around it yet.
Where I would be careful: the agent is a super admin
The announcement explains what an agent can do. How it signs in and with which rights it works is not in there. That is in the Agent Connector, and you should know it before you install it.
Agent Connector for WP is a separate, free plugin by Soflyy (GPL, source on GitHub (opens in a new tab)) that Oxygen installs at the push of a button. It runs the MCP server directly inside your WordPress installation and bundles the official wordpress/mcp-adapter (opens in a new tab) package for that. Architecturally that is clean: instead of a protocol of its own, Soflyy uses the building blocks the WordPress project is developing for AI connections itself — the same Abilities API my plugins build on. It requires WordPress 7.0 and PHP 8.1. Sign-in works via OAuth or, on local sites for example, via an application password through a small local proxy.
The README answers the question of rights unmistakably. Abilities are always executed with super admin rights only; that is enforced and cannot be configured, and a connected agent can do anything a super admin can. You are therefore told to treat the access password "like an SSH key". The project's GitHub description is blunter still: "Give agents unrestricted execution capability on WordPress (shell, PHP eval, filesystem, process) via the WordPress MCP stack. Trusted dev environments only."
In fairness: the direct system access — shell commands, PHP eval, reading and writing files, WP-CLI — lives in the separate Universal Abilities add-on plugin, which Oxygen does not install by default. Without it, the connector only exposes the abilities other plugins register, such as Oxygen's builder tools. But those change your site too — and because Oxygen has a PHP Code element that puts server-side code into a page, I would not rely on an agent without Universal Abilities being unable to run code. On top of that, the safeguards are almost all opt-in:
- On a production environment the plugin shows a red warning notice — nothing more. Blocking operation on production is something you have to switch on yourself.
- The domain lock, which prevents a database copied to another domain from granting access there along with its credentials, is also off until you enable it.
- The audit log, which records every executed ability with user, IP and an input summary, only writes if you define a constant in
wp-config.php.
For a development environment that is a sensible default. For a production site with customer data in the WooCommerce back end it is not. Whether an agent with super admin rights should work on a live site is not a question of technology but one of responsibility — and for the vast majority of projects I would answer it with no.
How I would use Oxygen 6.2 with an agent
I still consider the feature real progress — provided you draw the boundaries yourself instead of relying on the defaults:
- Staging or local only. The agent builds on a copy, you review, and only then do changes go to the live site. Soflyy recommends this for the RC anyway, and the connector's project description says the same for agent access.
- Switch the safeguards on. Enable "Block on production environments" and the domain lock, and set up the audit log via the constant outside the web root. Also check that
wp_get_environment_type()really reportsstagingon your staging site — without configuration, every installation counts asproduction. - Leave out Universal Abilities unless you have a concrete reason. Building pages does not require a shell.
- Design system first, agent second. Create selectors, CSS variables and breakpoints before the agent starts — otherwise it invents them.
- Review the results like someone else's code. Semantics, heading hierarchy, alt texts, focus order in interactions, contrast. An agent that wires up a mobile menu "without custom JavaScript" has not thereby built an accessible menu. How I check AI output in general is described in Who Checks the Checker?.
- Revoke access again. Revoke application passwords and OAuth connections after the work is done instead of leaving them in place forever.
Who it is worth it for
You benefit most if you already work with Oxygen 6 and build recurring structures: archive templates with loops and custom fields, landing pages to a fixed pattern, WooCommerce templates. That is where an agent that knows the design system saves real manual work — and because the result stays editable in the builder, you can take over at any point.
Little changes if you are still on classic Oxygen: moving to 6 is a rebuild, not an update, and an AI feature alone is not reason enough for that. And if you build WordPress sites without a builder, 6.2 is above all a signal: Soflyy is betting on the official Abilities API and the WordPress project's MCP adapter. The more large plugins do that, the more likely the Abilities API becomes the standard way AI agents talk to WordPress. My own plugins already build on it — read-only for now.
On price: Oxygen currently costs a one-time 199.50 US dollars for unlimited sites, with no renewal, and the agent tools are included; the checkout link does carry a discount code, though, so this is a promotional price. The agent itself is not included: according to the pricing page you bring your own, and Soflyy does not resell AI credits.
Its sister product Breakdance gets the same features with version 3.0, which is also at the release candidate stage — with one difference you should know about: the new setup wizard in Breakdance 3.0 RC 2 (opens in a new tab) installs and activates Agent Connector and Universal Abilities in one click. So there, the agent gets shell, PHP eval and file system access right away if you simply follow the wizard.
FAQ
Has Oxygen 6.2 been released as a stable version yet?
As of 11 October 2026, no. The current build is 6.2 RC 1 from 30 September 2026. Soflyy has said this build will ship as the final 6.2 unless testing finds a blocking issue, and until then recommends testing on a staging site.
Do the agent features work with classic Oxygen too?
No. The agent tools belong to Oxygen 6, which was rebuilt on the Breakdance core. Classic Oxygen 4.x is still maintained, but it is a separate product line and not compatible with Oxygen 6.
Which AI agents can I connect?
Any client that speaks the Model Context Protocol. Soflyy names Claude, Codex, Cursor, Windsurf, Cline and Gemini CLI. The Agent Connector ships setup instructions for many more clients. Important: an agent running in the cloud cannot reach a site on your local machine.
What rights does a connected agent have?
Those of a super admin — on a single site, that means an administrator. This is hard-wired into the Agent Connector and cannot be lowered. Direct shell, PHP eval and file system abilities are only added by the optional Universal Abilities add-on, which Oxygen does not install — the Breakdance 3.0 setup wizard, however, does.
Can I switch the agent features off?
Yes. Under Oxygen → Settings → Agents & MCP you can uncheck "Allow agents to access this site over MCP"; Oxygen then stops providing its tools without you having to deactivate the Agent Connector. You are entirely free of the AI connection if you never install the Agent Connector in the first place.
Further reading
What a design system that humans and AI read alike looks like is covered in DESIGN.md: The Design System as a File the AI Can Read Too. How I check AI output before it goes live is described in Who Checks the Checker?; how I configure my own agent in Configuring Claude Code: From Defaults to Engineering Partner. Read-only abilities in practice are shown in the guides to JPKCom Post Filter, JPKCom Simple Lang and JPKCom ACF Jobs.
Soflyy's original sources: the Oxygen 6.2 announcement (opens in a new tab) with the full changelog, the RC 1 post (opens in a new tab) and the Agent Connector repository (opens in a new tab) with its README and safeguards.