ai newsMi., 28. Okt.
EilmeldungParents sue OpenAI over ChatGPT advice to cut daughter’s seizure drug

5 safety steps before you let an AI coding agent touch WordPress

Disclosure: I make ShipPress, a Mac app, and I mention it briefly at the end. Everything before that works without my tool. Claude Code, Codex and similar agents can now do a surprising amount of work on a WordPress theme or a set of pages. They also sometimes go a little past what you asked: they

dev.toMittwoch 12:19 · 28.10.3 Min. Lesezeit
Bild: dev.to

Disclosure: I make ShipPress, a Mac app, and I mention it briefly at the end. Everything before that works without my tool.

Claude Code, Codex and similar agents can now do a surprising amount of work on a WordPress theme or a set of pages. They also sometimes go a little past what you asked: they edit files they shouldn't touch, or write straight to the database. These are five things I wish I had done from day one after a few months of pairing AI agents with WordPress.

It sounds obvious, and it's the one that saves you the most. Don't let the agent work over SSH on the live site. Make changes locally or on a staging copy, check them, then move them over.

wp-env, Local, Docker: it doesn't matter which. What matters is that it's a place where breaking things hurts nobody.

If you hand the agent the whole repo or the WordPress root, it will read wp-config.php and core files too. If you only want it working on the theme, start it inside the theme folder:

cd wp-content/themes/my-theme claude # or codex, etc. Enter fullscreen mode Exit fullscreen mode With Claude Code, a CLAUDE.md in the project that spells out what's allowed helps a lot:

## Rules - Only change files under wp-content/themes/my-theme - Don't read or change wp-config.php or core files - Suggest new plugins, don't install them yourself Enter fullscreen mode Exit fullscreen mode 3. Back up the database, not just the files git can roll back files. But posts, pages, menus and block theme template edits live in the database, and git alone won't bring back a page the AI rewrote.

So export with WP-CLI before every session:

# before wp db export backups/before-ai- $( date +%Y%m%d-%H%M ).sql # roll back if needed wp db import backups/before-ai-20261028-1300.sql Enter fullscreen mode Exit fullscreen mode And on the file side, commit after every step:

git add -A && git commit -m "before: ask agent to change header colour" Enter fullscreen mode Exit fullscreen mode 4. Keep each request small "Build me the whole website" is much harder to review and undo than "build only the hero section of the home page". If you work in small rounds (request, check, snapshot), you can see right away which instruction broke something.

Before anything goes live, I check at least this:

git diff --stat # which files changed wp plugin list --status = active # any plugins you don't recognise? wp option get siteurl # did the URL get rewritten? Enter fullscreen mode Exit fullscreen mode If siteurl or home reaches production still set to your local URL, the site stops loading. That one is worth a second look.

Steps 1 to 3 were too much manual work for me every time, so I built a free Mac app called ShipPress. It sets up a local WordPress site, lets the AI CLI you already have (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) build the site, and creates a restore point every time the AI changes something. You can publish through host integrations like InstaWP, over SSH, or as a static export.

Download: https://shippress.codotx.com/?ref=devto-en

If you have your own tricks for keeping AI agents safe around WordPress, I'd love to hear them in the comments.

Quelle: dev.to (dev.to). Original öffnen