Letting Claude Code or Codex edit your live website: staging, backups and checks

Claude Code, Codex and similar agents no longer only suggest code. They run WP-CLI, push Shopify themes, edit Astro components and open pull requests on their own. That speed is why site owners hand them the keys, and it is also why one wrong command reaches customers within seconds. This guide is the order of safeguards we use before an agent touches a client site: a copy to work on, a restore you have tested, permissions the tool enforces, credentials that cannot do more than the task needs, and checks you run yourself.

It applies to WordPress, Shopify and Git-based frontends such as Astro or Next.js. Every product behaviour quoted below comes from the vendor’s own documentation, fetched on 23 October 2026.

#Should you let an AI agent edit your live site directly

No, not as the first step. The reason is technical, not a matter of trust in the model. Claude Code’s permissions documentation puts it plainly: “Permission rules are enforced by Claude Code, not by the model.” A line in CLAUDE.md or AGENTS.md saying “never touch production” shapes what the agent tries. It does not stop a command. On a live server, the agent’s shell has whatever rights the SSH user, database user or API token has.

A reply in an r/Wordpress thread about converting an AI-made HTML design into a theme put the working rule in one sentence:

AI is great at turning your HTML into theme pieces, but I wouldn’t let it connect to and edit your live site directly.

(u/eshbanbahadur2020, r/Wordpress, 23 October 2026)

The undo button is narrower than it looks too. Claude Code’s checkpointing page says a file that only Bash commands changed “isn’t tracked and stays as it is”, and calls checkpoints “not a replacement for version control”. A wp search-replace run, a plugin update or a theme push happens outside that history entirely. So the workflow starts away from production.

#How to give the agent a copy of the site instead of production

Pick the copy that matches your platform.

WordPress. A staging site on the same host, or a local copy, with the database exported and imported through WP-CLI. Our staging workflow guide walks through the full setup. Two commands matter for agents: wp db export writes the database to a file, and wp search-replace has a --dry-run option that, in the words of the WP-CLI handbook, will “run the entire search/replace operation and show report, but don’t save changes to the database”. Make the agent run every search-replace as a dry run first and show you the report.

For throwaway experiments, Playground CLI starts WordPress locally with npx @wp-playground/cli@latest server. In that mode it keeps files and the SQLite database in temporary directories, so nothing survives the stop. The start mode keeps changes between restarts. Our article on WordPress Playground and MCP for AI agents covers the agent side of that setup.

Shopify. shopify theme dev uploads your local theme as a development theme and serves a preview at http://127.0.0.1:9292. Shopify’s CLI documentation describes development themes as “temporary, hidden themes” that do not count toward your theme limit and “are deleted from the store after seven days of inactivity”. They are also deleted on shopify auth logout. If you need a preview that lasts for client review, Shopify recommends pushing to an unpublished theme instead. Either way, the agent never needs publish rights on the live theme.

Astro, Next.js and other Git-based sites. The agent works on a branch, and the host builds a preview. On Cloudflare Pages, preview URLs “are public” by default and every preview sends X-Robots-Tag: noindex; Cloudflare Access can restrict them to your account. Vercel’s environments page has a warning worth reading twice: a staged production deployment uses production environment variables, “so testing can access production services and data”. If the agent’s preview talks to your live database or payment keys, it is not a staging environment.

#How to back up the site so the agent’s change can be rolled back

A backup counts once you have restored it. Before an agent session:

• Code: commit or tag the current state in Git. On a WordPress site without Git, copy wp-content with the date in the folder name.
• Database: wp db export before-agent.sql. The matching restore is wp db import before-agent.sql, per the WP-CLI import reference.
• Shopify: duplicate the live theme in the admin. Products, orders and settings changed through the Admin API are not in the theme, so anything the agent writes there needs its own export.
• Restore drill: run the restore on staging once and time it. Ten minutes measured beats “the host keeps backups” assumed.

The same habit protects plugin and core updates; our article on whether it is worth updating WordPress shows how to update without breaking the site.

#How to limit what Claude Code or Codex is allowed to do

Both tools have a permission layer. Use it, and do not rely on it alone.

Claude Code has modes: default (labelled Manual) asks before the first use of each tool, acceptEdits auto-accepts file edits in the working directory, plan explores without editing source files, auto lets a classifier review actions, and bypassPermissions skips prompts. The documentation says to use bypassPermissions “only in isolated environments like containers or VMs where Claude Code can’t cause damage”. Rules in settings.json are checked in a fixed order, “deny, then ask, then allow”, and an allow rule cannot carve an exception out of a deny rule. A starting point for a WordPress repository:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./wp-config.php)", "Bash(git push *)", "Bash(wp db drop *)", "Bash(ssh *)"],
    "ask": ["Bash(wp search-replace *)", "Bash(wp plugin update *)"],
    "allow": ["Bash(git diff *)", "Bash(wp plugin list *)"]
  }
}

One limit to know: Read and Edit deny rules cover Claude’s file tools and commands like cat or sed, but not “a Python or Node script that opens files itself”. For a hard wall around secrets, the documentation points to the sandbox.

Codex separates the sandbox from approvals. According to OpenAI’s approvals and security page, the agent “runs with network access turned off” by default, a folder under version control gets workspace write with on-request approvals, and a folder outside version control gets read-only. danger-full-access means no sandbox and no approvals; the page marks it as elevated risk and not recommended. Keep the default and approve network access per task.

Credentials are the layer that holds when everything else fails. Give the agent its own database user on the staging copy, and if it only needs to analyse data, grant it SELECT alone, as in MySQL’s GRANT reference. For Shopify, a custom app token with the scopes the task needs; Shopify notes in its access scopes guide that “a write scope includes read”, so write_products is already the broad option. Revoke the token when the job ends. Our audit of remote access and API keys lists where such tokens hide.

#How to review the changes an AI agent made

Read the diff before anything moves to production. git diff --stat shows which files changed; an agent asked to fix a footer link that touched forty files has done something else too. Then read the full diff of each file. Watch for:

• disabled checks: a commented-out nonce verification, a capability check replaced with is_admin(), a test deleted “because it was failing”;
• new dependencies, plugins or Composer packages nobody asked for;
• secrets or API keys pasted into code;
• changes in database migrations, .htaccess, redirects or robots.txt.

On WordPress, compare wp plugin list and wp option get active_plugins before and after: some changes live in the database, not in files. For plugin code the agent wrote, our audit checklist for AI-generated WordPress plugin code goes through eight common mistakes.

#How to check that the agent’s change actually works

The agent saying “done, tested, everything works” is a report, not proof. A check the agent wrote for itself can pass for the wrong reason. Run your own:

A post tagged [PROMO] on r/Wordpress, written by the maker of an A/B testing plugin who was promoting agent skills for it, had this as its title: “Claude made changing my WordPress site so easy I stopped checking whether my changes actually worked.” One reply:

“I stopped checking whether my changes actually worked” is how we’re in a lot of the mess we’re standing in right now. Trust, sure, if you want, but verify.

(u/SoItBegins_n, r/Wordpress, 22 October 2026)

1. curl -sI on every changed URL and on the home page: status code, redirects, cache headers.
2. The PHP error log or the browser console on the same pages.
3. A real form submission, and on a shop a test order through checkout.
4. The page on a phone, not only in the agent’s headless browser.
5. For SEO-relevant changes: the rendered title, canonical and robots meta, since agents edit templates that emit them.

Do this on staging, then again on production right after the release. If something fails on production, restore first and debug second.

#What to do when the AI agent left spaghetti code behind

Signs are familiar: the same function in three files, fixes stacked on fixes, a plugin per small feature, styles inline because the agent could not find the stylesheet. A self-described beginner who had not coded in 20 years described two weeks with Codex on r/Wordpress as “a nightmare loop: breaking, patching, breaking again, and patching again” (thread, 21 October 2026). One reply summed up the fix:

Use Codex for small, reviewable changes on staging, not open-ended rewrites of the live site.

(u/NakanoNoNeko, r/Wordpress, 22 October 2026)

Do not ask the same agent to “clean everything up” on the live site; that multiplies the diff you have to review. Freeze the current state in Git, list what the site has to do, and decide per area whether to refactor or rebuild.

Our article on vibecoding and WordPress explains why AI-built sites become hard to maintain. If you would rather hand it over, our AI-built website rescue service takes the site over from that point, and a maintenance plan keeps staging, backups and update checks running afterwards. When you want agents in your workflow for good, AI implementation covers setting up permissions, tokens and review steps.

#Which access to give an agent at each stage

The agent does the typing. Production stays a step you take yourself.