Undo AI changes in WordPress: how rollback works for AI agents
Can you undo what an AI agent did to your WordPress site?
Yes — in most cases, and from two directions. Cowboy MCP keeps a per-change undo journal that records the before-state of every write an agent makes, so a single wrong edit rolls back on its own, and it takes one-click database checkpoints for the operations no journal can invert. Both live on the Activity tab in wp-admin, and both are callable by the agent itself.
This page is about mechanics: what is captured, how an undo is applied, where a checkpoint takes over, and what cannot be reversed. The wider guardrails are on the security page and the operating habits in the safe-operations playbook. All of it ships in the free plugin on WordPress.org (opens in new tab), which turns a site into a WordPress MCP server with 168 tools.
How does per-change undo work?
Every journaled change is captured when it is dispatched, not reconstructed later. The undo journal is a table in your own database where each mutating tool call stores a full snapshot of the object it is about to touch — the post row with its meta and terms, the option value, the file bytes — plus a hash of the state it left behind. Undo writes that snapshot back wholesale; it never replays a diff.
The capture wraps the handler: the dispatcher snapshots the target first and commits the entry only if the tool succeeds, recording the tool, the action (create, update, delete), a readable label, the key that made the call, the MCP session, and any batch. A failed call leaves no entry. Secrets are redacted whenever the journal is read, but the stored blob is faithful, so an undo restores the true value.
Three behaviours make it trustworthy. Conflict detection: before restoring, the engine re-snapshots the object and compares it with the hash recorded after the change; if anything else — a later agent call, an editor in wp-admin — touched it since, the undo stops with a conflict error instead of clobbering newer work, and you resend with force: true once you have looked. Redo: every undo is journaled as a new entry pointing at the original, so an undo can be undone (the few exceptions, such as re-creating a deleted attachment, are recorded as not undoable). Batch undo: a multi-tool run shares one batch id and reverts newest-first, stopping at the first failure.
The Activity tab lists every entry with Undo and Undo batch buttons and shows conflicts inline; the wp_list_changes tool gives an agent the same ledger, filterable by object, tool, batch, session, status, and date. Entries are kept for seven days by default (the Undo Retention setting); a daily prune removes expired rows with the backup zips and trashed media they own. A before-state over 16 MB compressed is recorded as not undoable, so the gap is visible.
When do you need a database checkpoint instead?
When the change is the whole site rather than one object, the journal is the wrong tool. A database checkpoint is a prefix-scoped SQL dump of every site table — written in pure PHP, gzipped into a protected folder under uploads — that can be swapped back in atomically to return the database to that moment. Take one before anything multi-step, and let the plugin take them automatically where undo cannot reach.
Two triggers are automatic and on by default: before any WP-CLI command not recognised as read-only (a short allowlist of verbs such as list, get, and search; unknown verbs count as mutating), and before plugin and theme updates, so a migration run by an update can be rewound even though the journal only backs up files. Both fail open — a checkpoint that cannot be written is audit-logged and the command still runs. Manual checkpoints come from the Activity tab or wp_create_checkpoint; the newest five are kept by default.
Restore is built to be boring. It takes a pre-restore safety checkpoint first and aborts if it cannot; imports the dump into temporary tables; verifies each table's row count against the count recorded at checkpoint time; then replaces the live tables in a single RENAME TABLE swap, so a failure at any step leaves the originals untouched. The plugin's own API keys, settings, and OAuth records are re-applied afterwards, so a restore can never lock you out of the connection that ran it, and the restore is journaled as not undoable, pointing at the safety checkpoint that reverses it.
The limits: a checkpoint restores database tables — not uploads, theme or plugin files, or code. It rewinds everything since that moment, including changes made outside MCP (new orders, comments, sign-ups), which is why the tool warns before running. And it lives on the same server under wp-content/uploads: a rollback point, not an off-site backup.
What can and can't be undone?
The line is whether a before-state exists to restore. A change is undoable when the tool that made it has a registered capture strategy — the large majority of the plugin's write tools — and not undoable when the action has no inverse, leaves nothing to snapshot, or happened outside MCP; either way the journal records it, so the ledger stays complete. The table is derived from the plugin's capture registry.
| Change | Undo? | How it is reversed — or why not |
|---|---|---|
| Posts, pages, custom post types, block edits, patterns, block-theme templates and global styles, SEO meta, Elementor templates | Yes | Full post row, meta, and terms restored; a deleted post keeps its original ID; a theme-file template edit is undone by removing the database override |
| Options and WooCommerce settings | Yes | Previous value restored, or the option removed if it did not exist |
| Users and roles | Yes | Row and meta restored with the original ID; content reassigned during a delete is not moved back; login sessions untouched |
| Terms, comments, order notes, classic menus | Yes | Restored; a deleted menu returns with a new ID, items and locations intact |
| Media | Yes | Uploads removed on undo; alt-text and metadata edits roll back; a deleted attachment returns from a trash-aside folder with every size and the original file |
Files in wp-content (wp_write_file, wp_delete_file) |
Yes | Previous bytes written back atomically; a file the agent created is removed; 16 MB compressed cap per entry |
| Plugin and theme activation, theme switch | Yes | Toggled back |
| Plugin and theme install, update, delete | Files only | Previous package restored from a per-change backup zip; an update's database migrations are the auto-checkpoint's job; undo never removes an active plugin or theme |
| WooCommerce products, variations, orders, refunds, customers, coupons | Yes | Object data restored; a deleted object returns with a new ID |
| ACF field values and repeater rows; Wordfence settings and firewall mode | Yes | Previous values restored |
| Search-and-replace | Yes | Captured rows re-applied to the exact posts touched |
| WP-CLI commands | No | Cannot be inverted; an automatic checkpoint precedes any command that is not read-only |
| Sent test emails, outbound HTTP requests, cache flush or preload, transient clean-up, thumbnail regeneration, table repair | No | Nothing to recall, or derived data; recorded as not undoable |
| Bulk stock updates, tax-rate creation, Wordfence scans, IP and country blocks, scan-issue changes | No | Not journaled per object; recorded as not undoable so the gap is visible |
| A checkpoint restore | No | Restore the pre-restore safety checkpoint taken first |
| Anything changed outside MCP | — | Not in the journal; a checkpoint rewinds it with everything else since |
How do you undo from your AI client?
You do not need wp-admin to roll back; the same machinery is on the agent's side. The rollback tools — wp_list_changes, wp_undo_change, and the four checkpoint tools — are ordinary MCP tools, so you can ask Claude, ChatGPT, Cursor, or Claude Code to list, undo, and restore in plain English, and safe mode asks for confirmation before an undo or restore runs. Prompts you can paste:
- "List the last 10 changes made through MCP, newest first, with their change IDs."
- "Undo change 42." — if the object was edited since, you get the conflict message and can say "force it" once you have checked.
- "Undo everything from that batch."
- "Take a checkpoint labelled 'before menu restructure', then rebuild the main menu."
- "List the checkpoints and restore the one from before the plugin update." — the response includes the id of the safety checkpoint taken first.
A read-only key cannot undo, because undoing is a write; a custom-scoped key needs the rollback tools in its list. A human always can: Settings → Cowboy MCP → Activity has Undo, Undo batch, Create checkpoint now, and Restore buttons.
How do dry run and safe mode reduce the need to undo?
The cheapest rollback is the one you never make. A dry run reports what a write tool would do — tool, target, parameters — without touching anything, and safe mode holds every tool flagged destructive, including undo and checkpoint restore themselves, until the call is resent with explicit confirmation. Together they catch misread intent before the journal has to earn its keep.
Dry run is intercepted before any handler code runs, so it is safe on every non-read-only tool; for most tools it states intent rather than simulating the outcome, while the installer tools resolve the real plan, versions included. Safe mode is on by default and keys on each tool's destructive flag, so ordinary writes still flow — and every one of them is journaled. The habits that make this pay off are in the playbook.
How does this compare with other WordPress MCP plugins?
Reversibility is where WordPress MCP servers differ most. Most WordPress MCP plugins answer "what if the agent is wrong" with an approval gate — you confirm each tool call — and a growing number advertise change tracking or rollback, some within a fixed window such as 72 hours; hosted services rely on staging copies or site snapshots. Cowboy MCP's answer is before-state journaling with conflict detection and redo, plus checkpoints, with retention you set.
When you read a rollback claim, ask: does it capture the before-state or just log the call; does it notice when something else changed the object since; can it revert files and plugin packages, or only database rows; does it cover WooCommerce and page-builder data; and how long is the window. The comparison pages go through named alternatives attribute by attribute; this page stays on mechanics.
FAQ
How long are undo entries kept?
Seven days by default, set by the Undo Retention option in Settings → Cowboy MCP. A daily prune removes expired rows along with the backup zips and trashed media files they own. Checkpoints are governed separately: the newest five are kept by default (configurable), and the automatic pre-restore safety checkpoints expire after the same retention window.
Does undo cover WooCommerce orders?
Yes. Products, variations, orders, refunds, customers, and coupons are journaled with their full object data, so an edit rolls back and a deletion is re-created, though with a new ID. Bulk stock updates and tax-rate creation are recorded as not undoable. A checkpoint restore also reverts orders placed after it, so prefer per-change undo on a live store.
Can an AI agent undo its own changes?
Yes. wp_undo_change and wp_restore_checkpoint are ordinary MCP tools, so the agent that made a change can reverse it when you ask — subject to safe mode confirmation, the conflict check, and the key's scope (a read-only key cannot undo). The undo is itself journaled, so it can be redone, and every change also appears on the Activity tab for you to undo yourself.
Are database checkpoints a backup replacement?
No. A checkpoint is a rollback point for your database tables, stored under wp-content/uploads on the same server and capped at a handful of recent snapshots. It holds no uploads, theme or plugin files, or code, and it would be lost with the server. Keep a real off-site backup; use checkpoints for the quick rewind before risky work.
What about files the agent changed?
Files written or deleted through the file tools are journaled with their full previous bytes, so undo restores a file exactly or removes one the agent created — up to 16 MB compressed per entry, and never writing an executable into the uploads folder. Plugin and theme installs, updates, and deletes keep a per-change backup zip. Files changed by a WP-CLI command are not captured; the automatic checkpoint before WP-CLI covers the database only.