# Cursor for WordPress theme code, with the live site plugged in

Cursor writes good PHP, but it has never seen your client's database, and that's where WordPress themes go wrong.

The template looks fine in the editor. Then you upload it, load the page, and find out the "Practice Areas" section pulls from a custom field nobody mentioned, on a site that's been through three developers. So connect the live site to Cursor over MCP. The agent reads the actual pages, settings and error log before it writes anything, instead of guessing at them.

Kitepod is the MCP server in the middle. It's free, it takes about two minutes to connect, and the agent never writes to your live theme.

## A law firm's theme, start to finish

Take a classic theme for a law firm, where the partners want a new practice-area template.

```prompt
Look at how the existing practice-area pages are built, then add a page template with a sidebar listing the attorneys for that practice area.
```

The agent reads a couple of existing pages and the theme files first. It then writes the template into a draft theme, a copy of the active theme or a new child theme. Kitepod lints the PHP before saving it. The live site hasn't changed.

```prompt
Publish the draft theme, then load the homepage and two practice-area pages and tell me if anything's broken.
```

Publishing a draft theme waits for a person's approval under the default policy. Once you approve, Kitepod health-checks the home page and REST API, and on a fatal error it puts the previous theme back by itself.

```prompt
Since yesterday the contact page shows a PHP warning. Pull the last fatal error and the debug log, then propose a fix.
```

Kitepod returns the last fatal error and the end of the debug log, secrets masked, plus Site Health and any paused plugins. The agent writes its fix into the draft theme. You read it there, and publish when you're happy.

## Connecting Cursor

1. Install the Kitepod plugin on the site through Plugins → Add New → Upload (WordPress 6.4+, PHP 7.4+).
2. Press **Connect** in wp-admin and pick the WordPress user the agent works as. Theme work usually means an Administrator; the agent never exceeds that user's permissions.
3. Add Kitepod to Cursor.

The fast route for step 3 is the **Add to Cursor** install link in your Kitepod dashboard. Click it, then log in when Cursor asks.

Or do it by hand. Per Cursor's docs, MCP servers live in `~/.cursor/mcp.json` (all projects) or `.cursor/mcp.json` (one project). Add Kitepod under `mcpServers`:

```json
{
  "mcpServers": {
    "kitepod": { "url": "https://kitepod.com/mcp" }
  }
}
```

Cursor handles OAuth for remote servers, so there's no token to put in `headers`. The first time the agent calls Kitepod you'll get a sign-in prompt. You can switch servers on and off under **Customize** in Cursor's sidebar.

## The server copy and your repo

Kitepod edits theme files on the site, inside the draft theme. Your local checkout doesn't change.

For plenty of freelancers that's fine, because there's no repo, just the live site and a backup. A draft theme with the last 10 published generations kept is a better safety net than editing over SFTP.

But if your theme lives in Git, the server is now one more place changes happen. Copy what the agent wrote back into the repo before your next deploy, or that deploy will quietly undo its work. [WordPress version control](/wordpress-version-control) goes deeper on what Git covers and what it can't.

## Why it's safe to point Cursor at production

Cursor's agent moves fast, and a typo in `functions.php` is a white screen. The draft theme is the answer to that. **Your live theme is never the file being edited**, and a publish that throws a fatal error rolls itself back without you lifting a finger.

The rest of the site gets snapshots. Content, settings and wp-content files are saved before every write, so a bad change comes back with one request for up to 90 days.

## Who it's for, and who should skip it

Developers and technical freelancers who already work in Cursor and maintain WordPress themes, child themes or client sites. You get the real site as context, plus WordPress chores like cache flushes and search-replace without leaving the editor. Read-only WP-CLI commands run directly; ones that write need approval.

Skip it if you're building a theme from scratch on your laptop with no site attached. Your local setup is better for that. And if you want nothing hosted at all, the official MCP Adapter can run over WP-CLI on a local site, though you wire up the abilities yourself. The [WordPress MCP](/wordpress-mcp) page compares the options.

## Finer points

### Can Cursor edit my live theme files directly?

No. They land in a draft theme (a copy, or a child theme) instead. Publishing that draft is a separate step that waits for approval by default and rolls back on a fatal error.

### Does Cursor need a token or a WordPress password?

Neither. Cursor uses OAuth to log in to Kitepod, so `mcp.json` holds only the URL.

### Can it run WP-CLI commands?

Real ones, yes. Read-only commands run straight away. Anything that writes waits for a person.

### Does it work with page builders?

Yes. Kitepod saves Elementor, Bricks, Breakdance and Beaver Builder layouts using the builder's own code, and can regenerate Elementor and Breakdance CSS caches. [Elementor](/integrations/elementor) has the details.

### Can I keep Kitepod in one project's config only?

Yes. Cursor reads `.cursor/mcp.json` inside a project as well as the global file in your home folder. Putting Kitepod in the project file means it only shows up when that client's repo is open.

### Is there a version for OpenAI's Codex?

Same server, different client. [Codex and WordPress](/codex-wordpress) has the setup.

A child theme you were scared to open is a lot less scary when the agent has read the site first.