On a WooCommerce store, the dangerous work an agent can do is rarely in git. WP-CLI can rewrite the database, push plugin updates to live, and delete files no version control has ever seen. Sara Nóbrega wrote a useful piece on what AI coding agents should never do on their own, and her categories hold up. Her blocked commands, though, are git, terraform and kubectl, and none of those appear in my terminal.
So this is the list I work from instead, category by category, plus the places where WordPress tooling is safer than her setup assumes.
What AI coding agents should never touch on a store
- Destructive file operations. rm -rf under wp-content/uploads, rewriting wp-config.php, or clearing mu-plugins. Uploads are almost never in version control, so an agent tidying “unused images” is a loss with no revert.
- Database writes. wp db query with a DELETE or TRUNCATE in it, wp db import pointed at production, or bulk order edits on live. A missing WHERE clause on a store eats customer history.
- Production changes. wp plugin update –all and wp core update during trading hours, or a theme file deploy to live. The agent has no idea a sale starts at noon.
- Secrets. Payment gateway keys, SMTP credentials and license keys. On most stores these sit in wp_options rows or wp-config.php constants rather than .env files, so an agent grepping for config finds them.
Her test is whether a command can be undone. On a store the undo is a database dump taken before the run, because reverting code brings back none of the orders that arrived while the agent was working. That changes where you draw the line, and it makes a fresh dump the first rule on the blocklist.
The checkpoints WP-CLI already ships
Nóbrega asks for a confirmation step before destructive commands. In WordPress some of those already exist, and agents should be told to use them. wp search-replace supports –dry-run, which runs the whole operation and prints a report without writing anything, and –skip-columns=guid, which keeps feed and permalink URLs intact. The command docs list both. Run it on staging first, then on production, with the same command.
wp db export backup-$(date +%F).sql
wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables --dry-run --report-changed-only
wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables --skip-columns=guidI let the agent run the dry version and read the numbers back to me. Then I decide whether the real one runs, and often I run it myself. I don’t maintain multisite networks, so I won’t claim anything about how –network behaves with dry runs there.
An AGENTS.md file for a client repo
The source’s most practical idea is the AGENTS.md contract, and it’s now an open format that Codex, Claude Code, Cursor and Copilot all read (spec on GitHub). For client work, the valuable lines are about environments and undo rather than code style. Mine usually contain the same few rules.
- wp-cli.yml defines @staging and @prod aliases. Never run a write command against @prod without asking.
- Run wp db export before any wp db or wp search-replace command, and say where the dump landed.
- Never modify wp-config.php, mu-plugins, or anything under wp-content/uploads.
- Finish with a report: files changed, commands run, anything you skipped.
Her two-agent loop carries over as well. I wrote about running parallel Claude Code sessions on client sites before, and the reviewer setup is the same idea. A second agent reading a diff is good at catching a dropped capability check or missing nonce verification, and plain PHP WordPress code gives you very few types to catch those for you.
What stays manual on a store
A few areas I keep fully hands-off no matter how well the task is written. Order data and customer accounts, because bulk status edits and test-account cleanup on live are how VAT reports quietly stop matching. Roles and capabilities, since wp cap and wp user delete can lock out the one person able to fix it. Auth code, password resets, nonce handling and capability checks, for the reason the source gives: those bugs pass the happy path and surface in support tickets months later.
This is work I do for store owners as part of normal maintenance. If your team is starting to point agents at live sites, an audit of which commands they can currently run, plus an AGENTS.md with the rules above, is a small job that can prevent an expensive cleanup.
On the next client site I open, I’d do three things: commit the AGENTS.md with the aliases and blocked list, confirm wp db export works from the shell the agent uses, and hand it dry-run output instead of write access for the first search-replace. None of that takes long, and it keeps the two hours of cleanup from the article off the store.
