You can use Claude Code with WordPress through a project folder, WP-CLI, MCP, the REST API or SSH. A route may reach several installations, including local and live copies. Inventory its reachable targets, then bind the intended operation to one verified site before the first write.
For example, you start Claude Code in a local copy and ask for a new About page heading. The project references a securely stored Application Password for the live site. Your request names a page, not a copy, so either route could make the change.
This check is for owners, marketers, in-house teams and agencies running existing sites. Whichever way you connect Claude to WordPress, inventory its reach, verify the intended copy, then enforce the task’s access limits.
Signing in to Claude doesn’t give it access to a WordPress site
A Claude or Claude Code sign-in authorizes your Claude account and the models you use. It selects no WordPress site. Site access comes through separately configured routes that may cover several installations:
- a folder on your disk holding site files
- a WP-CLI target, alias or alias group
- an MCP server entry with its token or approval
- an Application Password and request endpoint
- an SSH key or desktop connection to a server account
Claude and WordPress meet only through one of these. A working sign-in doesn’t decide which site a request changes. Before any task, tie each login to the correct WordPress installation and identify the site and authorize the access for the copy you mean.
In a team or agency, access to a workspace or an account isn’t authority over a particular site. Check both when work moves between people or between copies of a site.
Check which installations each way you connect Claude to WordPress can reach
Connecting Claude Code to WordPress creates a route that may reach several installations. Claude can edit your WordPress website through an authorized write route. Bind the operation to one verified target; an MCP service URL alone doesn’t identify that site.
In a WordCamp Portugal 2026 talk on WordPress’s YouTube channel, one Claude Code session mixed routes: it reached a production site through a hosting MCP server and local sites through a command-line tool.
| Route | What decides which site it reaches | Read-only check | How to limit it |
| Project folder | Launch directory; access may extend beyond it | Verify path and each command’s target | Separate configuration; enforce filesystem/OS limits |
| WP-CLI, local or remote | Flags, config files, aliases and alias groups | wp option get home for the selected target | One alias per copy; disabled_commands; permission rules |
| MCP server (plugin or host) | Service endpoint, authorization and selected site/environment | Inspect scopes, list/get/status; read target identity | Scope organizes loading; enforce tool/server permissions |
| REST API with an Application Password | Endpoint and accepted user credential; clones may retain hashes | Check endpoint and returned site identity | Separate secure credentials; enforce OS/network/server limits |
| SSH, including desktop SSH sessions | Server account’s permissions and selected path | wp option get home with –path | Run as the site’s own server account |
| Web fetch of public pages | The public URL; it may be blocked or stale | Compare with a shell route’s answer | Use it to check a release |
Inventory each route’s reachable targets, then verify the selection for this operation. One correct answer says nothing about other routes.
The project folder holds the copy Claude Code was started in
Claude Code works on the files in the folder you start it in. In the WordCamp Portugal talk, the presenter says: “because I’m asking that from a specific folder, it’s getting me the information from the folder of my project.”
A folder holds files; the database runs separately. Copies may come from Local, WordPress Studio, wp-env or Docker. Separate folders organize copies without fencing access. Curtis Noble, describing his personal sites, writes: “I made a new root folder just for them, with a subfolder for each site.”
Claude Code’s WP-CLI target comes from flags, config files and aliases
WP-CLI is WordPress’s command-line tool. WP-CLI’s configuration reference lists what picks the target, in order: flags such as –path, –url, –ssh and –http; then wp-cli.local.yml and wp-cli.yml in the working directory or a folder above it; then ~/.wp-cli/config.yml. For –url, it notes: “In multisite, this argument is how the target site is specified.” So when Claude Code runs WP-CLI, the same command can reach a different installation depending on the folder it runs from.
Aliases such as @staging and @production name installs, and an alias group such as @both runs one command against several. With –ssh and only an SSH host, “the path will be the SSH user’s home directory”, so give an explicit path.
Aslam Doctor asks: “Ever tried running WP-CLI from Claude Code while using Local by Flywheel and it just… fails?” A reply in a Reddit thread points to a Local add-on for this. The read-only check is wp option get home, which returns the home URL.
Check the endpoint and site identity for each saved REST credential
The REST API is WordPress’s web interface for reading and changing site data. Since version 5.6, an Application Password generated on a user’s Edit User page lets a tool act as that user. WordPress stores its hash in user metadata and checks supplied passwords against it. Inference from that code, not a test here: a database clone can retain those hashes and may accept the same password if authentication permits. Verify endpoint and returned identity independently; give copies separate credentials.
A local Docker user reported reaching the live site through REST. Secure storage and project-specific credential references reduce accidental reuse; file placement alone restricts no access. Enforced filesystem/network/OS or server-side controls supply isolation. Keep raw secrets outside model-visible files and output.
An SSH session reaches whatever the server account can reach
SSH is an encrypted remote login to a server. One r/ProWordPress poster describes their staging setup: “Since it has access to ssh, it can access logs, the database, files, the WP CLI, everything.” In Claude Code’s desktop app, SSH sessions work the same way: “Claude runs on the remote machine with access to its files and tools” (checked October 17, 2026).
The server account decides which sites a session can change. One VPS owner found Claude Code gated to one website as that site’s user; running it as root left root-owned files. A host of about 30 sites lists “running the session with the website user so it can’t write outside their directory” among his safeguards.
Web fetch reads the public site, which may not be the copy you edit
A web fetch reads whatever a public URL serves, so it can’t see a copy on your computer, and its answer can be blocked or stale. One poster’s fetch was blocked, and “The home page loaded once, but it showed posts from 2016.” The poster suspected an old cached copy, and the thread didn’t confirm a cause. Use a fetch to check the public result after a release; identify copies through other routes.
A Claude Code WordPress plugin reaches the installation it runs on
The plugins people pair with Claude Code, such as Easy MCP AI, AI Engine, Novamira and the WordPress MCP Adapter, run MCP servers inside one WordPress installation. MCP, the Model Context Protocol, is an open standard that lets Claude Code call a server’s tools. The project folder, WP-CLI and a REST credential need no Claude Code plugin for WordPress.
Check which copy issued the plugin’s connection
A plugin connection acts with the access granted on its installation. AI Engine’s announcement warns: “MCP gives Claude Code full admin access to your WordPress site.” Easy MCP AI’s documentation says: “The connection acts as the WordPress user who approved it (or the token’s assigned user).”
The same page checks the connection by asking, “Which are the five most recent posts on my WordPress site, and which of them are still drafts?” That shows the connection works, not which copy answered: a freshly cloned staging site can hold the same recent posts as the live site. Ask for the site’s address instead.
Claude Code’s WordPress MCP servers: list them and check their scope
To inspect Claude Code’s WordPress MCP servers, use claude mcp list and /mcp for status. The MCP documentation, checked October 17, 2026, says a project entry rejected through disabledMcpjsonServers appears only in claude mcp get. Inspect relevant configuration scopes and use claude mcp get followed by the known name for an entry absent from list. Keep details sanitized. Configured means saved; loaded means included in the session; connected means a connection exists. Cached tools don’t prove a live connection.
Local scope, the default, loads a server in the project where added; project scope shares configuration through .mcp.json; user scope makes it available across projects, subject to approvals and settings. Scope controls loading without revoking REST credentials, SSH or other routes.
A hosting MCP can expose several sites. Its service endpoint differs from the selected site/environment identifier: check the tool’s target and returned site identity independently.
How to use Claude Code with WordPress: ask each route which site it reaches
Using Claude Code with WordPress starts with reads. Inventory every reachable target, verify the selection for the intended operation against the copy you mean, and stop if identity is unclear.
Four read-only answers identify a WordPress copy
- Home URL: run wp option get home on the WP-CLI side. On the REST side, add ?_fields=name,url,home to the REST API root, /wp-json/, to get the site’s name, site URL and home URL (checked against developer.wordpress.org on October 17, 2026).
- Environment type: wp_get_environment_type() returns local, development, staging or production, and “If not set, the type defaults to ‘production’.” An unlabelled local copy reports production, so this answer means something only where WP_ENVIRONMENT_TYPE is set. Set it on every copy. The REST root doesn’t include it.
- Active theme and WordPress version: second signals when two copies look alike.
All four are reads; verify the selected target before writing.
Compare the answers with the copy you meant before any write
If a route reaches an unintended site, stop. Rescoping configuration reduces accidental use; enforced credential, tool, network or server limits prevent access. A CLAUDE.md note alone doesn’t bind the operation to your verified copy.
The team behind Tracy, a site-editing agent built with Claude Code, reports that during an import, a request to remove a banner disabled a plugin on a customer’s live site. “The files, the shell and the address all pointed at the copy. One write path still pointed at production.” Their first lesson: “Don’t trust where the agent thinks it is.” It’s a vendor’s unverified account of its own product’s bug.
In a team or agency, keep the website and environment explicit in every handoff.
One read-only request catches a live route in a local session
This illustration uses reserved placeholder domains; it isn’t a transcript or a test we ran. From the local copy’s folder, you send:
“Before changing anything, inventory this session’s WordPress routes and reachable targets, including relevant MCP scopes and known entries missing from list. Select example.local for this operation, verify its endpoint and returned identity with read-only checks, and stop on ambiguity. Show sanitized output, never credentials.”
A possible answer:
- WP-CLI with an explicit local target: http://example.local, environment type local
- User-scoped MCP service, selected site-live target: https://example.com
- Secure REST credential reference, checked endpoint: https://example.com (the REST root has no environment type)
Two selections reach live; they don’t establish each route’s full reach. Remove the live configuration and credential reference from this workflow, enforce access limits, then recheck scopes and target identity. Read the output alongside the model’s summary.
How to give Claude access to WordPress one copy at a time
To give Claude access to WordPress one copy at a time, organize configuration to reduce mistakes and enforce the required access limits. Folder placement and MCP scope alone provide no isolation.
CLAUDE.md describes the site; permission rules enforce the limits
Claude Code’s memory documentation (checked October 17, 2026) says “Claude treats CLAUDE.md files as context, not enforced configuration”, and “To block an action regardless of what Claude decides, use a PreToolUse hook instead.” The permissions page adds: “Permission rules are enforced by Claude Code, not by the model.” Rules are evaluated in order: deny, then ask, then allow.
A Bash rule matches the command text Claude writes, so it covers the usual form of a command and isn’t a security boundary around the program. For filesystem and network limits that don’t depend on command text, the docs point to sandboxing, and to a PreToolUse hook for your own checks.
Several guides set the environment boundary in CLAUDE.md. That line describes the setup without enforcing it, and CLAUDE.md is still the right place to record the environment and its dependencies, such as which copy this folder holds.
Load a live site’s MCP configuration only where you intend to use it
Use local or project scope for live-site configuration. Check relevant scopes, list/status and get for known missing entries; absence from list alone proves no isolation. Scope doesn’t revoke credentials or other routes. Enforce tool, network and server permissions separately. A Lytbox tutorial scopes a local site: “That way the MCP is just with the site and not for every single website that we have on our device.”
Give each copy its own credentials and server account
Give each copy separate credentials, including after cloning. Keep secrets outside model-visible files/output and use project-specific references; enforced OS/network/server controls restrict access. Give WP-CLI one named alias per copy. disabled_commands in wp-cli.yml can switch off commands such as db drop. Run server sessions as the site’s own user. Before writing, know what you can restore.
FAQ
Does Claude Code support HTTP MCP servers?
Yes. Claude Code’s MCP documentation, checked October 17, 2026, recommends HTTP for remote servers; local servers use stdio, and SSE is deprecated. The URL identifies the service endpoint, which may expose several sites. Check the selected site/environment identifier and returned identity independently of configuration scope.
How do I integrate Claude into my website?
These are two different jobs. Putting Claude in front of visitors, such as a chat window on your pages, is a separate, visitor-facing product decision. Working on the site with Claude Code means connecting a folder, WP-CLI, MCP, the REST API or SSH. Decide which job you mean before you connect Claude and WordPress.
Run these checks before the first real request
If a route can’t identify the selected target, it doesn’t get write access yet. That holds whichever way you use Claude Code with WordPress. Bind the operation to the verified copy, then begin with one page and one clear change.
Shuttle by MoonPress is our AI workspace for existing WordPress sites. It works with your own Claude Code or Codex account and is pre-MVP, so the checks above are general practice, not features it runs today. Our product rules require real provider authorization, verification of the server’s identity and hosting credentials kept out of AI prompts. To see what Shuttle needs from your hosting route, check your site’s fit.
