# Find out why WordPress pages are not cached with Codex

> Finding out why pages are not cached with Codex means asking it, in your terminal, to read xSpeed cache status and health checks through xSpeed Hub and trace the cause back to your deploy or your repository.

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

A release went out and the site is slower. You are in the terminal with Codex and the repository checked out, so you ask it there: pages on shop are not cached since the last release, find out why. Codex lists your sites, reads get_cache_status, then get_health, and compares what it finds with your working tree.

A common finding after a release is a configuration file that was replaced. If get_health reports that the WP_CACHE constant is not defined, or that the advanced-cache.php drop-in is missing, page caching silently does nothing even though it is switched on, because WordPress only loads the drop-in when WP_CACHE is true. Codex can then check the wp-config.php your deploy ships and see that the line is gone. run_benchmark confirms the effect: the cached request is not a hit.

Codex also runs shell commands, under its own approval modes and sandbox. If you ask it to confirm with curl that a page returns the X-XSpeed-Cache header, use a plain GET and not curl -I, which sends a HEAD request and reports BYPASS on a healthy site. The sandbox's network rules apply to a command like that curl, not to Codex's connection to the Hub, so the Hub tools work either way. It helps to tell Codex what changed in the release. A line such as: we replaced the config files and moved the theme, gives it a place to look when get_health reports a warning. Without that, it can only describe the warning, and the link to your repository stays a guess. Ask it to state which file it checked, so you can verify the claim.

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

- Pages on shop stopped caching after this release. Read get_health from xSpeed Hub and compare it with the wp-config.php in this repository.
- Use xSpeed Hub to run the benchmark on shop, then request the home page twice with curl and show me the X-XSpeed-Cache header each time.
- If the xSpeed Hub health report names a missing drop-in or constant, tell me which file in this repository should carry the fix.

## Example session

```
You: Pages on shop stopped being cached after this morning's release. Use xSpeed Hub to find out why.
  → get_cache_status(site: shop) [read-only]: page cache on, 0 cached pages, hit ratio 0% since 09:12
  → get_health(site: shop) [read-only]: 1 warning: WP_CACHE constant is not defined; drop-in present
Agent: WordPress only loads the cache drop-in when WP_CACHE is true. The live site does not define it. If this morning's release ships wp-config.php, a missing define there would explain it, but I have not seen that file. Add define( 'WP_CACHE', true ); to the wp-config.php the site uses, then I will run the benchmark.
You: It was missing from the one we deploy. Added it and redeployed.
  → run_benchmark(site: shop) [read-only]: home page: 588 ms uncached, 66 ms cached, cached request was a hit
Agent: Fixed. The home page hits the cache again. The rest rebuild as visitors request them.
```

## How it works

1. **Start with the quick summary**: get_cache_status returns whether page caching is on, the stats (cached pages, size, hit ratio, last purge) and the web server xSpeed detected. It is a glance. If caching is off, or the hit ratio is far below what you expect, the agent moves on to the diagnostic.
2. **Run the diagnostic**: get_health is the tool for troubleshooting. It returns the environment checks with pass or warn tones (the advanced-cache.php drop-in, the WP_CACHE constant, rewrite rules, PHP and WordPress versions, caching plugin conflicts), the cache stats, 24 hourly hit and miss buckets and a 30-day hit-ratio series. The Hub tells the agent to use it, not get_cache_status, when you are troubleshooting rather than glancing.
3. **Time cached against uncached**: run_benchmark requests the home page once with the cache bypassed and once normally, after a warm-up request, and returns the timings. If the second request still is not a cache hit, the page cache is not serving the home page, and the result says so. It measures xSpeed's own response time. It does not return a Lighthouse score.
4. **Read what the checks mean**: A warn is a lead, not always a fault. A static-file rewrite warning, for example, can mean the nginx snippet is not in your server config yet, or that xSpeed could not verify it, which is not evidence the config is wrong. The agent reads the detail line and tells you which one it is.
5. **Fix it or hand it over**: If caching is simply off, toggle_cache turns it on. If another caching plugin owns the drop-in, the site refuses to enable xSpeed and says why; removing the other plugin is yours to do. If nothing explains it, contact_support emails xSpeed support with the agent's summary, after the agent has confirmed the message with you.

## Reference

| | |
| --- | --- |
| Quick check | get_cache_status (read): cache on or off, stats, detected web server |
| Diagnostic | get_health (read): environment checks, 24 hourly buckets, 30-day hit-ratio series, recent activity |
| One site per call | get_health does not accept site: "all"; call it for each site you care about |
| Benchmark | run_benchmark (read): home page only, cache bypassed against cache served, timings in milliseconds |
| Benchmark on every site | run_benchmark accepts site: "all" or a list of handles, one result per site |
| Benchmark history | get_benchmark_history reads past runs and the settings changes on the same timeline |
| Pro suggestions | get_pro_audit (read): which Pro features would help this site, from its settings and stats |
| Hit ratio scope | Counts requests that reach your server; pages answered by a CDN or Cloudflare edge are not counted |
| Support | contact_support emails xSpeed support with your account email and site list attached; classed read |
| Turning caching on | toggle_cache (write); refused by the site when another plugin owns the cache drop-in |

## Rules

- Diagnose with the read tools first. get_cache_status, get_health, run_benchmark and get_pro_audit change nothing on the site, so a read-only connection can run all of them. For clients that send the connection token, that means Read-only everywhere on; an OAuth sign-in gets the scopes the client asks for, unless the member is a Viewer.
- Do not answer a PageSpeed question with run_benchmark. It measures cached against uncached response time and returns no Lighthouse score; for a score, use the speed test or scan jobs.
- toggle_cache is a write. It runs as soon as your connection allows writes, and the Hub tells the agent to confirm the target site first. That is guidance to the agent, so your client's approval prompt is the gate that matters.
- contact_support sends a real email. The Hub tells the agent to confirm the message with you before sending, but the tool is classed read, so even a read-only connection can send one.
- The agent cannot edit your server configuration or another plugin's settings. When a check needs an nginx snippet or a conflicting plugin removed, it tells you what to do and you do it.

## Good to know with Codex

Your approval policy and sandbox shape what Codex may run from the shell, such as that curl check. MCP tools have their own setting. Codex prompts by default only for MCP calls that advertise side effects or a destructive annotation, and the Hub's tools declare neither, so that default does not cover them. Set default_tools_approval_mode to prompt for the server and Codex asks before each call, reads included. The Hub has no prompt of its own: a write tool such as toggle_cache runs as soon as your connection allows writes and you approve it, and approval_policy never or an auto-approving reviewer removes even that. If you only want Codex to look, use the connection token with Read-only everywhere on, or sign in as a Viewer member. Either refuses every write tool.

## More prompts for this job

They work in any client connected to xSpeed Hub.

- Using xSpeed Hub, why is the cache hit ratio so low on shop? Run the full health check and tell me the most likely cause.
- Using xSpeed Hub, is page caching actually working on blog? Benchmark cached against uncached and tell me if the second request was a hit.
- xSpeed Hub's get_health on docs shows a warning about the static-file rewrite. What does it mean and do I need to act?
- Use xSpeed Hub to check whether another caching plugin is conflicting with xSpeed on shop.
- Caching looks off on the staging site. Use xSpeed Hub to turn it on and tell me if the site refuses.
- Using xSpeed Hub, which Pro features would help the shop site, based on how it is set up now?
- With xSpeed Hub, compare the last few benchmark runs on blog and tell me whether my settings changes helped.

## Frequently asked questions

### Can Codex trace an uncached WordPress page back to my repository?

Partly. xSpeed Hub tells it which check fails, for example a missing WP_CACHE constant, and Codex can then look in your repository for the file your deploy ships. It cannot see inside a server it has no access to, so a cause that lives only on the host stays a finding for you.

### Does Codex need to run curl to troubleshoot with xSpeed?

No. The Hub tools alone give cache status, health checks and a benchmark. Curl is an optional extra when you want to see the X-XSpeed-Cache header for one URL, and it needs a plain GET rather than curl -I.

### Why are my WordPress pages not being cached?

The common causes are that page caching is switched off, the advanced-cache.php drop-in or the WP_CACHE constant in wp-config.php is missing, another caching plugin owns the drop-in, or the pages set cookies or headers that make them uncacheable. An agent can read all of these from get_health through xSpeed Hub and tell you which one applies to your site.

### What is the difference between get_cache_status and get_health?

get_cache_status is a quick summary: whether caching is on, the stats and the detected web server. get_health is the diagnostic. It adds the environment checks with pass or warn tones, 24 hourly hit and miss buckets and a 30-day hit-ratio series. The Hub tells the agent to use get_health when you are troubleshooting.

### Does run_benchmark give me a PageSpeed score?

No. run_benchmark measures how fast your own cache answers compared with an uncached request for the home page. For a Lighthouse score, ask for a speed test or a speed scan instead.

### Can the agent check every site at once?

Only partly. run_benchmark accepts every site in one call. get_cache_status and get_health take one site per call, and get_health does not accept site: "all", so for a fleet the agent calls them site by site or you use the Hub dashboard for the rollup.

### Will troubleshooting change anything on my site?

Not with the diagnostic tools. They are read tools and change nothing. Changes only happen if the agent calls a write tool such as toggle_cache, which runs once your connection allows writes, so your AI client's approval prompt and a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in) are the gates.

## Find out why pages are not cached with other agents

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

## More with Codex

- [Purge the WordPress cache with Codex](https://xspeedcache.com/agent/codex/purge-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 read your cache diagnostics: https://xspeedcache.com/docs/cache-diagnostics/
- Understanding cache hits and misses: https://xspeedcache.com/docs/hits-and-misses/
- How to check your site health: https://xspeedcache.com/docs/health/
- Common problems and troubleshooting: https://xspeedcache.com/docs/common-problems-and-troubleshooting/
- How to enable Page Cache: https://xspeedcache.com/docs/page-cache/