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 I 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. My 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. My article on WordPress Playground and MCP for AI agents covers the agent side of that setup.

Update, 4 November 2026. The Playground team described how WordPress Playground can now clone a live site into your browser, with no local server. You choose New Playground > Clone a live site, enter the address and check the site. The source site needs the Reprint plugin active, and you need an administrator account. The address alone grants no access to files or the database: you paste the migration key shown in Playground into Tools > Reprint Server > Migration Token and select Authorize client. Changes in the copy do not reach the live site, and the finished copy is saved in your browser. Reprint transfers files and database content in small parts and adjusts the stored site addresses. The browser import currently accepts up to 2 GiB. Playground runs WordPress in a different environment from your host, so some plugins and external services can behave differently; the post advises using these checks alongside testing on your hosting. For agent work this gives you a one-session copy without a server of your own. The post also warns that a copy can contain private content, user data and plugin credentials, so treat it like any database copy with customer data and remove that information before sharing an export.

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.
• Dev and staging sites (update 24 October 2026): the SnapShots plugin, version 3.0.0, saves the database and, by default, the uploads folder, and restores both in one click from the admin bar or with wp snapshot restore. Plugins, themes and core are not part of a snapshot, and the files stay on the same server: the plugin page says it “is not an off-site backup” and calls it a development tool for rolling a site back while you test. It needs WP-CLI and PHP exec, which many hosts disable. Use it between agent attempts on a local or staging copy, and keep the export above plus an off-site backup for production.
• 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; my article on whether it is worth updating WordPress shows how to update without breaking the site.

#Can you give an AI agent a copy of the customer database

A staging copy of a WooCommerce or Shopify store is a copy of customer names, addresses and orders. If the agent sends file contents to a cloud model, that data leaves your server. In the EU, the GDPR applies to this like any other processing. Article 5(1)(c) requires personal data to be “limited to what is necessary in relation to the purposes for which they are processed”, and Article 28(1) lets a controller use “only processors providing sufficient guarantees”. Fixing a header template does not need real customers in the database.

In practice: anonymise or delete customer and order tables in the copy before the agent session, or give the agent a copy with only the tables the task touches. wp db export --tables=... and --exclude_tables=... in the export reference make the second option a single command. Check your AI vendor’s data processing terms against Article 28 before any real personal data reaches it.

The same regulation backs the restore drill from the previous section. Article 32(1) lists “the ability to restore the availability and access to personal data in a timely manner” and “a process for regularly testing” security measures among the measures to consider. A backup nobody has restored meets neither.

#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.

Bash rules have a second gap worth testing before you rely on them. A rule matches the command text Claude writes, not the program that runs. The documentation’s own table shows that Bash(git push *) stops git push origin main but not git -C . push origin main, and Bash(rm *) does not stop bash -c 'rm -rf build/'. Treat a deny list as a speed bump for the commands the agent usually writes, and put the real wall somewhere the command text cannot route around.

That wall is the sandbox. It is off by default; /sandbox in a session or "sandbox": {"enabled": true} in settings.json turns it on. The operating system enforces it (Seatbelt on macOS, bubblewrap on Linux and WSL2), and it covers the shell commands Claude runs “and the processes they start”, so the Python script that slipped past a Read rule is inside it too. Writes are limited to the working directory, added directories and the temp directory. Network traffic goes through a proxy whose allowed domains “start empty”. Two limits from the same page: on native Windows commands run unsandboxed, and hooks, local MCP servers and helper commands run outside the sandbox with your full access.

For checks that need logic, a PreToolUse hook runs before every tool call and can block it. The permissions page states that a hook cannot loosen a deny rule: a call a deny rule refuses stays refused even if the hook returns “allow”. That makes hooks a safe place for project-specific rules, such as refusing any command that contains the production hostname.

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. My audit of remote access and API keys lists where such tokens hide.

Update 24 October 2026, an example of read-only scoping: the open-source Google Search Console MCP server (package open-gsc-mcp) ships with writes switched on. Its README lists four tools that change the account (submit_sitemap, delete_sitemap, add_site and delete_site), sets GSC_ENABLE_WRITES to 1 by default, and says logins “ask Google for full Search Console access”. The tools are marked as writes, but the server does not ask you before running them; whether you see a prompt depends on your client’s permission settings. For an agent that only analyses clicks and queries, sign in with auth login --read-only or set GSC_ENABLE_WRITES=0, and the four tools are left out. Check the default login of any MCP server the same way before you connect it.

Update 6 November 2026, an email address in the User-Agent header: on 5 November a user reported in the Claude Code repository (issue #107757) that the agent had sent their account email address to third-party sites in the User-Agent header. Lydia Hallie of the Claude Code team explained the cause on Hacker News: the account address was added to the model’s context so it would stop inventing names for @author tags, and when the model wrote a curl command itself, it sometimes put that address in the User-Agent as a contact. Anthropic says the address will be removed from the context in the next release. Until then, version 2.1.317 and later ship a built-in mod that asks before a web tool call or a curl-style command containing the address. The team says it does not cover scripts the agent writes and runs on its own, and in the same issue two people describe tests on 2.1.317 and 2.1.318 (macOS and Windows) where the mod stopped nothing. The general rule behind the bug: anything the agent holds in its context can end up in an outgoing request, including customer data from a database copy. Update Claude Code to at least 2.1.317 and add your own PreToolUse hook that rejects commands containing your address together with the word User-Agent (one user in the issue describes such a hook). Then search your server logs for User-Agent headers that contain an email address to see what agents send to your sites.

#Which credentials to give an AI agent on WordPress, WooCommerce, Shopify and Cloudflare

Each platform has a way to issue a credential that does less than your own login. Use it, and create it for the agent alone, so you can revoke it without locking yourself out.

On WordPress the role does the limiting. The roles documentation describes an Administrator as somebody with access to all administration features of a site, and an Editor as somebody who can publish and manage posts, including other users’ posts. An agent that edits content through the REST API needs Editor at most. An agent with an Administrator password has every administration feature, plugin installation included, and a plugin is PHP that runs on your server.

On Shopify, the CLI has a guard that agents should never be allowed to lift. The theme push reference says --allow-live is “required in non-interactive environments when targeting the live theme”, and --publish makes the uploaded theme live. An agent runs non-interactively, so a deny rule for both flags keeps it on unpublished themes. shopify theme push --unpublished creates a new unpublished theme and pushes to it, which is the target to give the agent instead.

#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, my 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 I’m in a lot of the mess I’m 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.

#When the agent says it worked but the site disagrees

#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.

My article on vibecoding and WordPress explains why AI-built sites become hard to maintain. If you would rather hand it over, my 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.

#A worked example: one agent session on a WordPress staging site

Task: move a newsletter form from the sidebar to the footer of a WordPress site with a custom theme in Git. The sequence below uses only the tools described above.

1. On staging, git tag before-agent in the theme repository and wp db export before-agent.sql for the database.
2. Start Claude Code in plan mode and ask for a plan. Read it. If the plan mentions plugins, the database or files outside the theme for a footer change, stop and ask why.
3. Switch to acceptEdits with the deny and ask rules from earlier and the sandbox on. The agent edits theme files; any wp command still asks you.
4. When it is done, git diff --stat. Two template files and a stylesheet are plausible for this task. Anything in functions.php that registers new scripts gets a full read.
5. Check yourself: submit the form on staging, confirm the subscriber arrives in the mailing tool, look at the footer on a phone, and grep the PHP error log for new entries.
6. Merge and deploy the theme yourself. Run the same five checks on production.
7. If anything fails on production: git revert the merge or redeploy the before-agent tag. The database was not touched, so it needs no restore. If it had been, wp db import before-agent.sql would be the step, and it had to work on staging first.

The agent wrote the code in step 3. Every step that touched production was yours.

#Which access to give an agent at each stage

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