Novamira HQ in beta: all your WordPress sites, one connection for your AI. Get it free →

← All guides

Guide

How an AI agent runs PHP inside WordPress

Updated October 17, 2026 · by the Novamira team

Most AI integrations for WordPress stop at content: drafts, summaries, alt text. Running PHP is the capability that changes the category, because it means the agent can build things: a custom post type, a REST endpoint, a WooCommerce rule, a fix for the bug you could not locate. This guide explains how PHP execution by an AI agent actually works inside WordPress, what happens when code fails, and where this way of working fits.

Can an AI agent write and run real PHP inside WordPress?

Yes. Through Novamira, an agent can run PHP with the full WordPress environment loaded ($wpdb, every core function, your active plugins) and write PHP files that persist and load on every request, like a plugin. The code runs in the WordPress process on your server, with a 30-second time limit per execution, and every run is a tool call your AI client shows before it happens.

How does PHP execution inside WordPress work?

Two distinct mechanisms cover the two things code needs to do: run once, or keep existing.

Execute PHP: run once, now

The Execute PHP ability runs a snippet with full WordPress environment access and returns the output. Nothing is written to disk, nothing persists past the request, and the time limit is 30 seconds. This is the tool for questions and one-off operations: query the database, inspect a plugin’s options, migrate a batch of posts, test an idea before committing to it.

// The agent answers "which posts have no featured image?" with code, not guesses
$ids = get_posts([
    'post_type'      => 'post',
    'posts_per_page' => -1,
    'fields'         => 'ids',
    'meta_query'     => [['key' => '_thumbnail_id', 'compare' => 'NOT EXISTS']],
]);
return count($ids) . ' posts: ' . implode(', ', $ids);

The sandbox: code that persists

When the agent writes a PHP file, the file goes to one designated directory, wp-content/novamira-sandbox/. A loader, installed as a must-use plugin, includes every PHP file in that directory on each WordPress request, so a sandbox file behaves like a plugin: custom post types, shortcodes, REST endpoints, cron jobs, WooCommerce extensions, all live there. Keeping AI-written code in one place also keeps it reviewable: the Novamira > Sandbox admin page lists every file with its status, and each one can be disabled (the file stays on disk but stops loading), re-enabled, or deleted, by you or by the agent. Code in the sandbox runs with the same access as any WordPress plugin; the directory organizes the agent’s code, it does not limit what the code can do.

What happens if the code breaks the site?

Sandbox files load on every request, so a fatal error in one of them would normally take the site down. This is the part of the system built for that case.

Crash recovery

Before loading sandbox files, the loader registers a shutdown handler and keeps note of which file is loading. If PHP dies with a fatal error during that load, the handler writes a crash marker in the sandbox directory with the error details and the name of the offending file. The attribution works even when the error surfaces indirectly, three function calls away inside another plugin: the chain started in a sandbox file, so the crash is attributed to it.

Safe mode

On the next request, the loader finds the marker and skips all sandbox files: WordPress loads normally, the admin works, and the MCP connection stays available. The agent can then read the error, fix or delete the broken file, remove the marker, and the sandbox loads again. The practical effect is that a fatal error in AI-written code costs one failed request instead of a site that stays down, and the agent can repair its own mistake without you touching FTP.

What can you build with it?

The pattern is always the same: explore with Execute PHP, persist in the sandbox, review in the admin. Some real shapes of task:

  • A custom post type with its fields and an archive template, registered from one sandbox file.
  • A WooCommerce rule that core and plugins do not offer, such as conditional fees or a custom email trigger.
  • A REST endpoint feeding a widget on another site.
  • A one-time migration: Execute PHP for the dry run and the counts, a reviewed run for the real change.
  • A diagnosis: when a page misbehaves, the agent reads the code involved and tests hypotheses with real queries instead of guessing.

This walkthrough from the Novamira channel shows five WooCommerce features built this way, end to end:

Where should this run?

On a local or staging copy, with a current backup: Novamira is recommended for staging environments with backups. The agent’s changes are real, nothing rolls back on its own, and review is the step between staging and production. Sandbox files travel to production with your normal deploy, where the loader runs them like any other reviewed code; for read-only inspection on a live site, Read Mode in Novamira Pro offers read abilities only. The Claude Code guide covers the full workflow.

Common questions

Does the code run somewhere else and sync back? No. It runs in the WordPress process on your server, which is why it sees your real data, your plugins and your theme. Nothing passes through Novamira’s servers.

What stops a runaway script? The 30-second time limit per execution, and the fact that every run is a visible tool call you can refuse in your AI client.

Can I see everything the agent has written? Yes: every persistent PHP file is in wp-content/novamira-sandbox/ and listed on the Novamira > Sandbox page, individually disableable.

Which agents can do this? Any connected MCP client: Claude, ChatGPT, Cursor, OpenAI Codex, Antigravity and the rest. The tools page lists the full ability catalog, and the sandbox docs go deeper on the mechanics.