How Codex handles this
You have just landed a change from a Codex session, and the live site still shows the previous version for logged-out visitors. That points at a cache in front of your server. You ask Codex to look at Cloudflare for that site. It matches the name with list_sites, calls cloudflare_verify to check that the stored token and zone still resolve, and reports the answer in the terminal before it touches anything.
Next, Codex can run purge_cloudflare to empty the edge copy, or set_cloudflare_dev_mode to bypass the edge for about three hours so you see origin output while you iterate. Both writes need Cloudflare connected in xSpeed on that site, and neither accepts site: "all". If you ship to several sites, ask Codex to loop over them, and it will call the tool once per site and show each result in order.
Codex adds its own layer, and its default does not cover the Hub. Codex prompts by default for MCP calls that advertise side effects or a destructive annotation, and the Hub's tool definitions declare neither, so that default does not cover purge_cloudflare or set_cloudflare_dev_mode. Set default_tools_approval_mode to prompt for the xspeedhub server, then give cloudflare_verify an approve override so the read runs quietly. The sandbox limits what shell commands can touch, not these tool calls. approval_policy never, the yolo flag and an auto_review reviewer take you out of the loop, and then your connection scope is the only thing between a request and a Cloudflare write.
Set up Codex once
Already connected? Skip to the prompts. Alternatives and troubleshooting are on the Codex guide.
1Put 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.
2Add 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.
codex mcp add xspeedhub --url https://app.xspeedcache.com/xspeed/mcp codex mcp login xspeedhub
3Keep 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.
[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 Codex setup, sign-in options and FAQ
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.
What do I ask?
Three prompts written for Codex. More for this job are below.
Use xSpeed Hub to run a Cloudflare check on shop and show me the raw result. Do not purge.
I merged the template fix to blog. With xSpeed Hub, purge the Cloudflare edge for blog only.
Use xSpeed Hub to turn Cloudflare development mode on for shop while I iterate, and turn it off when I say so.
What happens, step by step
When Cloudflare sits in front of a WordPress site, it keeps its own copy of your files at the edge. Through xSpeed Hub an agent can check that the site's Cloudflare credentials still work, purge the edge cache, and turn development mode on or off. All three need Cloudflare connected in xSpeed on that site, and each works on one site at a time.
01
Verify the connection
cloudflare_verify calls Cloudflare's API with the credentials stored on the site and checks that the token and zone still resolve. It purges nothing and works on a read-only connection. If Cloudflare is not connected on that site, the call comes back as an error and the agent should tell you rather than retry.
02
Purge the edge
purge_cloudflare empties the Cloudflare edge cache for the site's zone. It does not touch the copies on your server. When Cloudflare is in front of a site, a content change usually needs both, so the agent runs purge_cache first and purge_cloudflare after it, or one purge_cache of type all, which reaches the edge when Cloudflare is connected.
03
Turn development mode on to see origin changes
set_cloudflare_dev_mode with enabled true bypasses the edge for about three hours, so changes on the origin show immediately. It slows the site for real visitors the whole time. Your client's prompt is the gate here, because the Hub's instructions do not name this tool in their confirm list.
04
Turn it off when you finish
set_cloudflare_dev_mode with enabled false switches development mode off. Cloudflare also ends it on its own after about three hours. No Hub tool reads whether it is currently on, so note when you turned it on.
05
Read a failure
A rejected token, an empty zone ID or a refused call comes back as an error that names the action, the HTTP status and Cloudflare's message when it gave one. It is not reported as a success. The credentials themselves are set in the xSpeed Cache panel in wp-admin, not through the Hub.
Reference
| Read tool | cloudflare_verify; purges nothing and works on a read-only connection |
|---|---|
| Write tools | purge_cloudflare and set_cloudflare_dev_mode (enabled true or false) |
| Needs | Cloudflare connected in xSpeed on that site: integration on, an API token (or the legacy key and email) and a Zone ID |
| Edge purge scope | Everything Cloudflare holds for the site's zone; the server copies stay |
| Development mode | Bypasses the edge for about 3 hours, then Cloudflare switches it off |
| Token permissions | Zone Cache Purge, and Zone Settings Edit for development mode |
| What verify proves | The token and zone resolve; a token without Zone Settings Edit still verifies |
| Through purge_cache | Type all also clears the edge when Cloudflare is connected; page, assets, object and rest do not |
| Every site at once | None of the three accept site: "all"; one site per call |
| Failure shape | An error with the action, the HTTP status and Cloudflare's message |
| Read-only connection | The connection token with Read-only everywhere on, or a Viewer member's sign-in; purge_cloudflare and set_cloudflare_dev_mode are refused and cloudflare_verify works. An OAuth sign-in gets the scopes the client asks for, so the switch does not make it read-only |
| Confirmation | None on the Hub; your client's prompt is the gate |
Rules worth keeping
- Run cloudflare_verify first, but do not read a pass as proof that every call will work. A token that lacks Zone Settings Edit verifies and purges fine, then fails the first time development mode is switched.
- Purge the server and the edge together after a content change. Purging only the site leaves visitors on the old page until the edge copy expires.
- Turn development mode off as soon as you are done. It slows the site for real visitors for up to about three hours, and no tool reports its state.
- Never paste a Cloudflare token or Global API Key into the chat. Connect Cloudflare in the xSpeed Cache panel in wp-admin, and use a scoped API token rather than the Global API Key.
- purge_cloudflare and set_cloudflare_dev_mode are write tools. The Hub runs them as soon as your connection allows writes, so your client's approval prompt and a read-only connection (the connection token with Read-only everywhere on, or a Viewer member's sign-in) are the gates that matter.
Good to know with Codex
Do not rely on Codex's default prompt for these tools, because the Hub's definitions carry no side-effect annotation. Set default_tools_approval_mode to prompt for the xspeedhub server. If your session runs with approval_policy never or the yolo flag, set_cloudflare_dev_mode can switch on without any prompt from Codex, and the Hub will not add one. Development mode slows the site for real visitors until it is turned off or runs out after about three hours. For sessions that should only inspect, and for codex exec in scripts, use the connection token with Read-only everywhere on, set through bearer_token_env_var, or a Viewer member's sign-in: cloudflare_verify still works and both write tools are refused.
More prompts for this job
They work in any client connected to xSpeed Hub.
Use xSpeed Hub to check that the Cloudflare connection on shop still works.
With xSpeed Hub, purge the Cloudflare edge cache on blog.
I changed the checkout page on shop. Use xSpeed Hub to purge the site cache and the Cloudflare edge.
Use xSpeed Hub to turn Cloudflare development mode on for shop. I am editing the theme.
With xSpeed Hub, turn Cloudflare development mode off on shop.
Ask xSpeed Hub to verify Cloudflare on shop and tell me what is wrong if it fails.
Using xSpeed Hub, which of my sites have a working Cloudflare connection? Check them one at a time.
Frequently asked questions
Keep going
Manage Cloudflare with other agents
More with Codex
Documentation
- How to connect Cloudflare
- How to serve assets from a CDN
- How to enable Page Cache
- How to write prompts for xSpeed Hub
- Codex + xSpeed
- Every AI agent that works with xSpeed
From the blog