How to Connect Codex to WordPress

Codex can work with WordPress through a local code repository, a purpose-built REST tool or an MCP server. Codex CLI and the IDE extension support MCP servers and share their MCP configuration on the same Codex host. The WordPress connection still needs its own authentication and permission model.

Begin with a trusted project and a dedicated Read Only WordPress identity. Keep credentials in environment variables or an approved secret store, not in .codex/config.toml or the repository.

In one sentence: Connect Codex to a defined WordPress tool surface, but let a separate WordPress identity determine what it is actually allowed to do.

What this guide helps you accomplish

This guide separates Codex configuration from WordPress authentication and requires runtime proof before any compatibility claim becomes public.

A useful AI workflow is not defined only by the quality of the answer. It is also defined by the data the assistant can reach, the actions it is permitted to take, the evidence you can inspect afterward and the ease with which access can be withdrawn.

Why this matters

Codex is often used in repositories, so users may assume that opening a WordPress codebase is equivalent to connecting to the live site. It is not. Repository access can change code files; WordPress REST or MCP access can retrieve and change site records. Those surfaces require different credentials and review processes.

OpenAI’s current Codex documentation stores MCP configuration in ~/.codex/config.toml or a project-scoped .codex/config.toml for trusted projects. That configuration should identify how to launch or reach the server, while secrets remain external.

Expected output

A successful run should produce:

• A selected Codex workflow for code, data or actions.
• A trusted project scope and documented MCP configuration when used.
• A separate Read Only WordPress identity.
• A successful read test, a refused write test and a revocation test.
• A version-bound compatibility record.

Separate repository access from site access

Codex may inspect and modify a plugin or theme repository without any connection to WordPress production. Conversely, a REST or MCP tool can manipulate WordPress content without granting filesystem access. Decide which surface the task needs and do not expose both by default.

Prepare Codex MCP configuration

Current official documentation supports STDIO and streamable HTTP MCP servers. Codex can be configured through CLI commands or config.toml. Project-level configuration is loaded only for trusted projects, which helps prevent an arbitrary repository from silently supplying tools.

Capture the active client version, the configured server identity and the tools Codex sees in the session.

Keep WordPress credentials out of configuration

Use an environment variable or approved secret mechanism for an Application Password or connector token. The configuration file may contain the name of the environment variable, but not its value. If the server supports OAuth or another mechanism, document its revocation and storage separately.

Prove the effective boundary

Ask Codex to list a known set of content using the connected tool. Then ask it to perform an operation outside the identity’s mode. Capture the tool call and WordPress response. A polished response from Codex is not enough; the environment must enforce the refusal.

A safe workflow

1. Classify the task as local code work, WordPress data access or WordPress action.
2. Choose a trusted connector and verify its primary documentation.
3. Create a dedicated Read Only WordPress identity.
4. Place credentials in environment variables or a secret manager.
5. Configure the MCP server in a trusted Codex project or user scope.
6. Inspect the available tools before running the task.
7. Run a known read and an intentionally forbidden write.
8. Revoke the WordPress credential and confirm the next call fails.

Prompt recipe

Before copying this prompt, replace every value in square brackets. Do not paste credentials, customer data or private information into the instruction.

Use the connected WordPress tools only.

Goal: verify read-only access.

1. List the five newest published pages.
2. Return ID, title, URL, status and last-modified timestamp.
3. Do not change any record.
4. Do not use shell, browser automation or repository files as a substitute for the WordPress tool.
5. Report the exact tool names used and any unavailable fields.
6. Stop after the table and tool summary.

Why the prompt is structured this way

The prompt keeps Codex on the intended WordPress tool surface and prevents it from using broader local capabilities as an accidental workaround. Tool names and unavailable fields create an evidence trail for the integration test.

Recommended access boundary

Use a Read Only identity. The assistant may inspect the WordPress data included in its scope, but any attempt to create, edit, delete or publish content should be refused.

This workflow can influence editorial decisions or create unpublished changes. Keep the scope narrow and review every proposed change.

The access level is a starting recommendation, not a universal entitlement. The exact WordPress capabilities available to an identity must come from the installed product version and its published coverage, not from this article alone.

What must remain outside the task

• Do not trust project-scoped configuration in an untrusted repository.
• Do not store WordPress credentials in config.toml or commit them.
• Do not let repository write access substitute for a controlled WordPress content workflow.
• Do not claim compatibility from generic Codex MCP support alone.

How WP Agent Control fits

The guided private folder for Claude Code or Codex uses WordPress REST and an Application Password with a dedicated read-only profile. Existing Read Only, Draft, Content Editor and Publisher profiles remain under Advanced. They are not automatically converted to OAuth and do not inherit the remote task and exact-approval model.

Get structured site information and inspect selected published pages after connecting. No temporary task is needed for this public reading. You can also browse public pages without the plugin; Agent Control adds structured access and a path toward authorized WordPress work.

Connect your AI: docs first profile · See features and compatibility: coverage

Verification checklist

• ☐ The Codex project is trusted and its scope is documented.
• ☐ The connector package or endpoint is versioned.
• ☐ Secrets are external to the configuration and repository.
• ☐ The available MCP tools are captured.
• ☐ Read, refusal and revocation tests pass.
• ☐ The public guide names every version in scope.

Common failure modes

• Assuming the repository is the live site: Code access and WordPress data access are separate surfaces.
• Putting credentials in TOML: A convenient configuration becomes a secret-distribution problem.
• Using a broader Codex tool as a workaround: Shell or browser access can bypass the intended WordPress boundary and invalidate the test.
• Treating tool discovery as execution proof: Seeing a tool name does not prove authentication, permission enforcement or correct output.

Advanced note

A rigorous Codex test should pin the connector package where possible, record the MCP initialization instructions, capture the server tool schema and compare it with the WordPress identity’s effective capabilities. Tool exposure should be narrower than or equal to the policy, never the sole source of policy.

Related guides

• WordPress MCP Explained in Plain Language
• How the Official WordPress MCP Adapter Works
• WordPress Application Passwords for AI Connections
• Which WordPress Access Level Should You Give an AI?

Continue

Next step: open Which WordPress Access Level Should You Give an AI?, choose the smallest suitable access level, then follow the relevant connection guide. When you are ready to create a separate and revocable identity, review Product or begin the 7-day Solo trial.