# Purge the WordPress cache with Codex

> Purging the WordPress cache with Codex means asking it, from the terminal you deploy in, to clear the xSpeed cache on the sites you just changed through the xSpeed Hub server you added to Codex.

Page: https://xspeedcache.com/agent/codex/purge-cache/
Last updated: October 2026

You are in a Codex session in the repository for a WordPress theme, and a change just went out to the sites that share it. The live pages are still the ones built against the old templates. You tell Codex what changed and which sites use the theme, and it calls list_sites, then purge_cache with a page type, then start_preloader if you ask for a warm-up. The tool calls are listed in the session as they run.

What returns is the plugin's report for each site: the purge type, how many entries went, and for a type of all whether the object cache and a connected Cloudflare edge were cleared too. Codex works well in loops, so you can chain the purge with the rest of your deploy: after the push, purge the changed sites, then read get_cache_status and say whether the hit ratio has started to climb. For every site it passes site: all in one call and gets a result per site.

Codex has a sandbox and an approval policy for shell work, and each MCP server has its own approval mode with a per-tool override. Codex asks by default about MCP calls that advertise side effects, but the Hub's tools declare none, so that default does not stop a purge until you set the server to prompt. xSpeed Hub has no confirmation of its own, so that setting and the connection scope are the real gates. For a purge across every site the Hub also tells Codex to confirm once that it will touch all of them, which is guidance to the model rather than a lock.

## Set up Codex once

### 1. Put your sites in xSpeed Hub

Sign in at app.xspeedcache.com with Google or email; the Hub is free and has no site cap. Then connect each WordPress site from its own dashboard: click Connect Hub in the xSpeed Cache top bar, then Connect via xSpeed Hub. Each site needs the free xSpeed Cache plugin.

### 2. Add xSpeed Hub and sign in

Add the server with its URL, then log in. The login opens an xSpeed Hub page in your browser; approve access there. There is no token to paste, and Codex keeps the credentials it receives. Start Codex and type /mcp to see the server.

```bash
codex mcp add xspeedhub --url https://app.xspeedcache.com/xspeed/mcp
codex mcp login xspeedhub
```

### 3. Keep the Hub's tools on a prompt

Open ~/.codex/config.toml. Set the server to prompt for every tool, then let one read tool run without a question. The tool timeout defaults to 60 seconds, and a PageSpeed test can take up to about two minutes, so raise it.

File: `~/.codex/config.toml`

```toml
[mcp_servers.xspeedhub]
url = "https://app.xspeedcache.com/xspeed/mcp"
default_tools_approval_mode = "prompt"
tool_timeout_sec = 150

[mcp_servers.xspeedhub.tools.get_cache_status]
approval_mode = "approve"
```

Full setup: https://xspeedcache.com/agent/codex/

### Before you send a prompt that changes something

Reads change nothing on your sites, though contact_support emails xSpeed support. Writes run once your connection allows them, so your client's approval prompt and a read-only connection (the token's Read-only everywhere switch, or a Viewer sign-in) are the gates that matter. Codex has two layers for shell work: the sandbox mode limits what commands can touch, and the approval policy sets when Codex stops to ask. MCP tools have their own settings. Each server takes default_tools_approval_mode (auto, prompt, writes or approve) and each tool can override it with approval_mode. Codex also asks about MCP calls that advertise side effects or a destructive annotation, but xSpeed Hub's tool definitions do not declare either, so do not rely on that default for the Hub; set the server to prompt. approval_policy never, --yolo and an auto_review reviewer take the human out of the loop. xSpeed Hub has no confirmation step of its own, so an approved or auto-approved write runs as soon as your connection allows writes.

## Prompts

- I just pushed the checkout template to shop. Use xSpeed Hub to purge the page cache there, start the preloader and report how many URLs queued.
- With xSpeed Hub, purge the assets cache on every site that shares this theme, and list any site where it failed.
- After this deploy script finishes, use xSpeed Hub to purge shop and read the cache status so I can see the hit ratio.

## Example session

```
You: Deployed the shared theme. Use xSpeed Hub to clear the page cache on every site that uses it, which is all of them.
  → list_sites [read-only]: 3 sites: shop, blog, docs
Agent: This will touch all 3 sites with a page purge. Go ahead?
You: Yes.
  → purge_cache(site: all, type: page) [changes site]: 3 of 3 sites purged; 612 cached pages cleared in total
Agent: All three sites are clear, one result each. Want the preloader started on each of them?
```

## How it works

1. **Find the site**: The agent calls list_sites when you have more than one site, then matches the name you used to a site handle. If the name could mean two sites, the Hub tells it to ask you rather than guess.
2. **Pick the purge type**: purge_cache takes a type: all, page, assets, object or rest. all clears the page cache, the object cache and, when they are connected, the Cloudflare edge and CDN. After a theme or CSS change, assets is enough; after a content edit, page; after a deploy, all.
3. **Purge**: The call runs straight away on that site once your connection allows writes. For every site at once the agent passes site: "all", and the Hub runs the sites one after another with a one-second pause.
4. **Clear only the edge if that is all you need**: purge_cloudflare empties the Cloudflare edge cache on its own, without touching the copies on your server. A page or assets purge does not reach Cloudflare; a purge of type all does when Cloudflare is connected.
5. **Warm it again**: start_preloader rebuilds the cache in the background so the first visitors after the purge are not the ones paying for it.

## Reference

| | |
| --- | --- |
| Tool | purge_cache (write) |
| Purge types | all, page, assets, object, rest |
| What all covers | Page cache, object cache, plus the Cloudflare edge and CDN when connected |
| Every site at once | site: "all" or a list of handles, one result per site |
| Fan-out pacing | Sites run one after another with a 1 second pause |
| Edge only | purge_cloudflare, a separate write tool |
| Re-warm | start_preloader after the purge |
| Read-only access | purge_cache is refused on a connection token with Read-only everywhere on, and for a Viewer sign-in |
| Confirmation | None on the Hub; your client's prompt is the gate |

## Rules

- Name the site. With several sites, an unclear name should make the agent ask, and the Hub tells it to.
- A purge of every site is one call with site: "all". The Hub tells the agent to confirm it with you once before it runs.
- Purge the narrowest type that fixes the problem, then warm the cache, so visitors do not all hit uncached pages at once.
- A fan-out result is reported per site. Treat some sites failing as a partial result, not a failure of the whole call.

## Good to know with Codex

The Hub's tool definitions carry no read-only or destructive annotation, so Codex's default prompt for side effects does not cover them and a purge can run without stopping. Set the xspeedhub server to prompt, and let only the read tools run quietly. An approval policy of never, the yolo flag and an auto-approving reviewer take you out of the loop, and then toggle_cache or update_settings would go through as well, so use a connection token with Read-only everywhere on for any run started that way and for codex exec in scripts. The sandbox limits shell commands, not the connection to the MCP server, so it is not a gate for the Hub.

## More prompts for this job

They work in any client connected to xSpeed Hub.

- Use xSpeed Hub to purge the page cache on blog.
- I just changed the theme CSS on shop. Use xSpeed Hub to purge only the assets cache there.
- With xSpeed Hub, purge every site in my workspace and tell me which ones failed.
- Use xSpeed Hub to purge shop, then purge its Cloudflare edge cache too.
- With xSpeed Hub, purge the docs site and start the preloader so it is warm again.
- Using xSpeed Hub, what purge type should I use after updating a plugin that changes the checkout page?

## Frequently asked questions

### Can Codex purge the WordPress cache after a deploy?

Yes. With xSpeed Hub added as an MCP server in Codex, ask it in the same session to purge the sites you deployed. It calls purge_cache with the type that fits the change and reports what was cleared.

### Will Codex stop for approval before a purge?

Not by default. Codex asks by default about MCP calls that advertise side effects, and the Hub's tools do not declare any, so you need to set the server to prompt. xSpeed Hub has no confirmation of its own, so with an approval policy of never, the yolo flag or an approve setting on purge_cache, a purge runs as soon as the connection allows writes. A connection token with Read-only everywhere on, or a Viewer sign-in, refuses every purge whatever the Codex mode is.

### What is the difference between the purge types?

all clears every cache xSpeed manages for the site, including a connected Cloudflare zone or CDN. page clears the stored HTML pages, assets clears minified and combined CSS and JavaScript, object clears the Redis or Memcached object cache, and rest clears cached REST API responses.

### Does purging xSpeed also clear Cloudflare?

A purge of type all does, when the site has Cloudflare connected in xSpeed: it clears the page cache, the object cache and the Cloudflare edge, and reports each one. A page, assets or rest purge stays on your server. purge_cloudflare clears only the edge.

### Can I purge all of my sites with one prompt?

Yes. The agent passes site: "all" to purge_cache and the Hub purges every site in the workspace one after another, returning a result per site. The Hub tells the agent to confirm a write across every site with you once before it runs it.

### Will a purge slow my site down?

The next request to each purged page builds it fresh, which is slower than a cached hit. Starting the preloader right after the purge rebuilds the cache in the background so visitors mostly land on warm pages.

## Purge the cache with other agents

[Claude Code](https://xspeedcache.com/agent/claude-code/purge-cache/) · [Claude](https://xspeedcache.com/agent/claude/purge-cache/) · [Claude Cowork](https://xspeedcache.com/agent/claude-cowork/purge-cache/) · [ChatGPT](https://xspeedcache.com/agent/chatgpt/purge-cache/) · [Cursor](https://xspeedcache.com/agent/cursor/purge-cache/) · [GitHub Copilot in VS Code](https://xspeedcache.com/agent/github-copilot/purge-cache/) · [Windsurf](https://xspeedcache.com/agent/windsurf/purge-cache/) · [Gemini CLI](https://xspeedcache.com/agent/gemini-cli/purge-cache/) · [Antigravity](https://xspeedcache.com/agent/antigravity/purge-cache/) · [Zed](https://xspeedcache.com/agent/zed/purge-cache/) · [Kiro](https://xspeedcache.com/agent/kiro/purge-cache/) · [OpenCode](https://xspeedcache.com/agent/opencode/purge-cache/) · [OpenClaw](https://xspeedcache.com/agent/openclaw/purge-cache/) · [Hermes Agent](https://xspeedcache.com/agent/hermes-agent/purge-cache/) · [Grok Build](https://xspeedcache.com/agent/grok-build/purge-cache/) · [ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/purge-cache/) · [Grok](https://xspeedcache.com/agent/grok/purge-cache/) · [Grok Bot](https://xspeedcache.com/agent/grok-bot/purge-cache/) · [Muse](https://xspeedcache.com/agent/muse/purge-cache/) · [Manus](https://xspeedcache.com/agent/manus/purge-cache/) · [Kimi Code](https://xspeedcache.com/agent/kimi/purge-cache/) · [Paperclip](https://xspeedcache.com/agent/paperclip/purge-cache/) · [NanoClaw](https://xspeedcache.com/agent/nanoclaw/purge-cache/)

## More with Codex

- [Find out why WordPress pages are not cached with Codex](https://xspeedcache.com/agent/codex/troubleshoot-cache/)
- [Scan a website for speed problems with Codex](https://xspeedcache.com/agent/codex/speed-scan/)
- [Run and track PageSpeed tests with Codex](https://xspeedcache.com/agent/codex/pagespeed-tests/)
- [Raise a WordPress site's PageSpeed score with Codex](https://xspeedcache.com/agent/codex/optimize-site/)
- [Tune WordPress cache settings with Codex](https://xspeedcache.com/agent/codex/cache-settings/)
- [Warm the WordPress cache with Codex](https://xspeedcache.com/agent/codex/preload-cache/)
- [Set up the Redis object cache with Codex](https://xspeedcache.com/agent/codex/object-cache/)
- [Manage Cloudflare caching with Codex](https://xspeedcache.com/agent/codex/cloudflare/)
- [Manage every WordPress site at once with Codex](https://xspeedcache.com/agent/codex/fleet/)

## Documentation

- How to enable Page Cache: https://xspeedcache.com/docs/page-cache/
- How to warm your cache ahead of visitors: https://xspeedcache.com/docs/preloader/
- Managing your fleet with xSpeed Hub: https://xspeedcache.com/docs/managing-your-fleet-with-xspeed-hub/