How to use Claude Code on a WooCommerce store

Claude Code works on a WooCommerce store the same way it works on WordPress: on a staging or local copy, through files (your child theme and custom plugins) and through commands (WP-CLI and WooCommerce's own WC-CLI). What changes with a store is the stakes. Orders, customers and payments live in the database, a broken checkout costs sales, and customer records are personal data. WooCommerce's own update guide says it plainly: "Do not test updates directly on your production site."

WooCommerce also now ships a native MCP integration that lets AI clients such as Claude query and change products and orders. It's labeled a developer preview, off by default, and it exposes personal data, so it belongs on staging. This guide builds on our Claude Code for WordPress guide and covers what's specific to stores, as of October 2026.

Where store data lives, and why it matters

WooCommerce's update guide explains that a store "keeps data in two places": the wp-content folder, which holds themes, extensions and uploads, and the database. Claude Code reads and edits files. For anything in the database, it needs a command, an API call or an MCP connection.

Claude Code's checkpoints can undo its file edits, but not changes it makes through commands or to remote systems such as a database. That's why database work starts on a copy.

Staging first: WooCommerce's own rule

WooCommerce tells store owners to "make a current backup and test the update on a staging site whenever possible," and to update WooCommerce, extensions, payment gateways and the theme together on staging. A staging site is "a clone of your production site," and WooCommerce notes most hosts can help set one up, or you can use a staging plugin. Our guides to WordPress staging sites and WordPress backups cover both steps.

For Claude Code work, add two store-specific rules:

• Keep real customer data off staging where you can. A cloned database contains real names, emails and addresses. Ask your host whether staging copies can be anonymized, or use test orders and test customers.
• Turn off outgoing email and live payments on staging. Otherwise a test order or a status change can email a real customer or attempt a real charge. Use your gateway's test mode.

WC-CLI and the REST API

For product and order data, WooCommerce gives you two scriptable routes that Claude Code can drive.

WC-CLI. WooCommerce says the tool "is a part of WC from version 3.0.0 onwards" and builds on the WC REST API, so most REST API tasks can also run from the command line. Commands run through wp wc, for example wp wc product list, wp wc product update 123 and wp wc product delete 123 --force. Two gotchas from WooCommerce's FAQ: you must pass a user to run as with --user, and "WC-CLI doesn't directly handle backups," so back up with other tools first.

The REST API. The current version is v3. It needs pretty permalinks ("default permalinks will not work"), and WooCommerce recommends HTTPS. You create keys under WooCommerce, Settings, Advanced, REST API, for a chosen WordPress user, with Read, Write or Read/Write access. WooCommerce notes the secret is hidden if you view the key again, so store it right away. See WooCommerce's REST API docs.

A safe pattern for bulk product changes, such as fixing 300 product descriptions or adjusting categories:

1. Export the current data with a read-only command and commit the export to git.
2. Ask Claude to write the changes as a script, not to run commands one by one.
3. Have the script print a before-and-after table for review, without writing anything.
4. Run it on staging, check a sample of product pages, cart and checkout.
5. Back up production, run the same reviewed script there, and check again.

Use a read-only REST key for audits and a separate read/write key for the approved job. Keep keys in environment variables, never in prompts or CLAUDE.md; our guide to keeping secrets away from Claude Code shows how to block reads of key files.

WooCommerce's native MCP (developer preview)

MCP (Model Context Protocol) lets Claude call tools in another system. WooCommerce's MCP docs say it now "includes native support," built on the WordPress Abilities API and the WordPress MCP Adapter. As of October 2026:

• Status: "The MCP implementation in WooCommerce is currently in developer preview," and WooCommerce warns future updates "may introduce breaking changes."
• Off by default: enable it with the mcp_integration feature flag, for example wp option update woocommerce_feature_mcp_integration_enabled yes.
• Abilities: query, create, update and delete products; query orders, update order status and add order notes.
• Deprecated endpoint: an older /wp-json/woocommerce/mcp endpoint still exists for compatibility but is deprecated. New setups use the WordPress MCP Adapter.
• Logs: WooCommerce, Status, Logs, entries with source woocommerce-mcp.

WooCommerce documents two ways to add it to Claude Code:

Two corrections to the copied commands. First, WooCommerce's local example runs as --user=admin; WooCommerce's own advice is a dedicated WordPress user with only the capabilities the client needs, so swap that in. Second, WooCommerce's remote example puts the server name straight after the last --env value, and Claude Code's MCP docs say the CLI then reads the name as another value and rejects it. Claude Code documents the name first: claude mcp add woocommerce_store --env WP_API_URL=… --env WP_API_USERNAME=… --env WP_API_PASSWORD=… -- npx -y @automattic/mcp-wordpress-remote@latest.

For the remote option, WooCommerce says to authenticate with a WordPress username and an Application Password, created under Users, Profile, and not your account password or a REST API key. It also says: "Do not commit a configuration containing an Application Password to version control." The default local scope stores the server, password included, in your private ~/.claude.json, so don't add this one at project scope, which writes a shared .mcp.json file. Revoke the Application Password when the job ends.

Two more choices make it safer. Use that limited WordPress user rather than an administrator, since each ability enforces its own permission check. And put the write tools behind Claude Code ask rules, so creating, updating or deleting a product always needs your approval.

Customer data and privacy

WooCommerce's data privacy notice says order and customer operations "may expose personally identifiable information (PII) including names, email addresses, physical addresses, and payment details," and that you are responsible for complying with data protection rules. It advises least-privilege API scopes and rotating and revoking REST API keys regularly.

In practice: don't point Claude Code, through MCP, the REST API or a database export, at production customer data unless there's a real need and someone has checked how your Claude plan handles data. Our guide to what happens to your code and data covers training and retention by plan. This is general information, not legal advice; ask counsel about your obligations.

Testing a store change before it ships

WooCommerce lists what to test after an update. It's a good checklist for any Claude Code change too:

Have a person run through checkout on staging after Claude's change, on mobile and desktop. Automated checks help, but a test purchase is the proof. Our guide to Claude Code for ecommerce teams covers how store teams split this work.

Good jobs and poor fits

• Good: child theme fixes to product and cart templates, custom plugins with clear specs, bulk product data clean-up by reviewed script, store audits, and page speed work on product and category pages.
• Poor: anything run directly on production, payment gateway code you don't fully understand, changes during a sale, and connecting an agent to live orders "to see what it can do."

For the wider safety settings, including ask rules on commands that touch production, read whether Claude Code is safe for a live website.

Conclusion

Claude Code can do real work on a WooCommerce store: theme and plugin code, scripted product clean-ups through WC-CLI or the REST API, and, in preview, MCP access to products and orders. Do all of it on staging with backups, outgoing email and payments switched off, least-privilege keys and users, and a person running a test checkout before anything reaches production. If you'd like a team to handle store development or maintenance this way, see our Claude Code development services. More guides are in our Claude Code Guide.

Frequently asked questions