WP-Autoplugin: an agentic coding workspace inside the WordPress admin

What problem WP-Autoplugin solves, and for whom

Most sites accumulate small, site-specific code: a custom plugin nobody remembers writing, an abandoned plugin that still runs, a child theme with three overrides. Changing any of it means leaving the admin, finding the file, and hoping the edit does not break something else. WP-Autoplugin puts that loop back inside WordPress. From the admin you describe a plugin, get a plan, generate files, inspect the diff, and then package, install, fork, apply or roll back the result from one workspace.

The audience is narrow but real. It fits administrators and developers who maintain their own or third-party code on a site they control, not people who want a generic content generator. The README frames the tool as "similar to having Claude Code or any other coding agent inside WordPress, but with a workflow designed specifically for plugins and themes." That framing matters: the value is not the model, it is the WordPress-specific staging and release path around it.

It is also explicitly bring-your-own-key. You connect it to OpenAI, Anthropic, Google Gemini, xAI or a compatible endpoint, and it can alternatively use a ChatGPT subscription's Codex credits instead of an OpenAI API key. There is no bundled inference.

How the agent reads a codebase without one giant prompt

The mechanism the README describes is progressive, bounded exploration. Rather than placing an entire plugin into a single prompt, supported models call read-only source tools: inspect target metadata and project structure, list and page through source files, read only relevant sections of a file, search for literal text, and discover WordPress actions and filters with their locations and surrounding code. A child theme project also exposes the installed parent theme separately.

That design has a concrete consequence. A task that starts at a REST route can continue into the callback, supporting classes, validation logic and related hooks without resending every project file on every request. The trade-off is that the agent must decide where to look, and the README states the loop is deliberately bounded: agents receive a limited source scope and a tool budget rather than unrestricted access to the WordPress installation.

The tool loop spans PHP, JavaScript, the WordPress REST API and durable background jobs. It can pause between model turns, survive a page reload, and resume with the same model, reasoning effort, instructions, source fingerprint and remaining tool budget. Background work runs through the bundled Action Scheduler integration, so long operations do not depend on one open browser request. That is the part that makes multi-step work practical in a browser tab, and it is also the part most likely to fail on a host that interferes with WP-Cron or Action Scheduler.

Focused edits and the Plan, Code, Review staging model

Version 2 replaced the v1 behaviour of regenerating an entire file for a small change. For existing plugins and themes, it can generate exact, bounded search-and-replace operations. The server applies those operations to an immutable snapshot of the original file, validates the complete result, and stages only approved Add, Update and Delete paths. The README's stated goals are fewer unrelated changes, easier diffs, and less risk of the model replacing working code outside the requested scope. That is a real architectural claim, and it is the strongest argument for v2 over v1.

The workflow separates three stages. Plan decides what should change. Code produces it. Review evaluates the result. The README says nothing is modified on a live target unless an administrator explicitly approves the release, and that Plans, revisions, manual edits, Reviews, conversations, usage records and release actions are retained as part of the project. You can reopen a closed project, compare revisions, restore an earlier result as a new revision, and see which Review applied to which version of the code.

One honest limitation is stated in the README itself, and it is worth repeating because it is the kind of thing vendors usually hide: when requested behaviour cannot be implemented reliably through a plugin's available hooks, the Plan explains the limitation instead of pretending an extension is possible. Hook-based extension work is therefore not a universal escape hatch, and the quality of that judgement depends on the model you connect.

Installing WP-Autoplugin and running a first project

The repository README does not contain install commands. It links a homepage at wp-autoplugin.com and describes the plugin as free, so treat the release archive or the site's distribution page as the source of the installable build. What the repository does tell you is the runtime floor: version 2 is a rewrite for WordPress 6.6+ and PHP 8.0+. Confirm both before you start.

Once the plugin is active, the first step is connecting a provider. The README lists OpenAI, Anthropic, Google Gemini, xAI and compatible API endpoints, plus the ChatGPT subscription path. The admin bundle is built from two entry points, which tells you where the settings screen comes from:

npm run build

That script runs wp-scripts against assets/v2/src/index.tsx and assets/v2/src/settings.ts with output to assets/v2/build. You only need it if you are working from a source checkout; an installed release ships the built assets.

After a provider is configured, open a new project and pick the type: a new plugin, an installed plugin, a standalone or child theme, a hook-based extension, or an Explain project. For a first run, an Explain project against a small installed plugin is the lowest-risk choice, because it only reads. A new plugin is the canonical path: write a description, refine the Plan, generate the files, inspect the changes, then download or install the result. The README notes the output is a normal WordPress plugin you can maintain with or without WP-Autoplugin.

For a modification, the sequence is the same but the release step matters more. The agent inspects the target, stages the result separately, and waits for explicit approval before anything touches the installed files. Use the revision list to compare against the original before you approve.

Where WP-Autoplugin is the wrong tool

The bounded tool budget is a genuine constraint, not a footnote. If your task requires reasoning across a very large codebase in one pass, or a change whose correctness depends on runtime behaviour the agent cannot observe, the read-only source tools will not get you there. The README says the agent can inspect metadata, page through files, read sections, search literal text and find hooks. It does not claim the ability to execute code, run the test suite, or observe the site at runtime.

There is also a hard dependency on durable background processing. The README attributes long operations to the bundled Action Scheduler integration. On hosts where scheduled events are unreliable, the pause-and-resume behaviour the README describes will not hold, and multi-turn work becomes fragile.

Finally, WP-Autoplugin is not a content generator. Several of the phrases people search around this project point at AI writing tools; this one writes PHP against your installed code. If you want post drafting or SEO copy, you are looking at the wrong plugin. And if you need a fully managed service where someone else holds the API key and the bill, the bring-your-own-key model is the opposite of what you want.

How it compares with a general coding agent

A general terminal agent such as Claude Code operates on a filesystem you point it at. You clone the plugin, run the agent, edit locally, then move files back to the server yourself. WP-Autoplugin inverts that: the code never leaves WordPress, the agent reads the installed plugin or theme in place through the REST API and PHP, and the release step is a workspace action with an approval gate. The difference is not intelligence, it is where the working copy lives and who applies the change.

That inversion cuts both ways. You gain the staging model, the revision history, the hook discovery against the actual installed version, and the ability to work on a site you cannot easily clone. You lose the shell: no composer install, no phpunit run, no git history, no code editor, no arbitrary tooling. The repository ships phpunit.xml.dist, phpcs.xml and a tests directory, which tells you the maintainers test their own code, but that tooling is not part of the agent's loop as described.

A second comparison point is v1 of this same plugin. V1 regenerated whole files; v2 generates bounded search-and-replace operations against an immutable snapshot. If you used v1 and found the diffs noisy, the v2 approach is a direct answer to that complaint rather than a cosmetic release.

Maintenance, upgrades and licence status

The repository is not archived, and the last push was on 2026-08-02, the same day as the 2.0.1 release. The release cadence visible in the metadata is 1.8.0 on 2026-06-09, then 2.0.0 and 2.0.1 on 2026-08-02, so the 2.x line landed as a single burst rather than a slow migration. Upgrading from 1.x to 2.x is not a drop-in: the README calls version 2 a complete rewrite and says it replaces the separate v1 workflows with one durable Plan, Code, Review workspace. Plan for a behaviour change, not just a version bump.

Upgrade cost after that is mostly environmental. The plugin needs WordPress 6.6+ and PHP 8.0+, and it ships a JavaScript admin built with @wordpress/scripts. If you build from source you need Node and the dependencies in package.json; if you install a release you do not. The PHP side has a composer.json and a vendored directory, and uninstall.php is present at the top level, so removal is handled rather than leaving tables behind.

The licence is the open question. The repository metadata does not state one, and no LICENSE file appears at the top level. The readme.txt and the plugin header in wp-autoplugin.php are the places a WordPress plugin normally declares its licence and its GPL compatibility, so read those two files before you redistribute a build or ship it inside a client project. Nothing here is legal advice, and the absence of a licence identifier in the repository listing is not proof that no licence exists.

Editorial conclusion

Adopt WP-Autoplugin if you maintain custom plugins, internal tools or site-specific modifications and want an agent that reads the installed code before proposing a change. Skip it if you need to ship a public plugin to wordpress.org today: the README does not document submission tooling, and the licence field in the repository metadata is empty, so check the readme.txt and the plugin header inside wp-autoplugin.php before you redistribute anything. Verify first that your host can run durable background jobs, since the tool loop depends on the bundled Action Scheduler integration, and confirm the release step against a staging copy before you let it apply a revision to a live target.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. WP-Autoplugin/wp-autoplugin on GitHub