Haydi — Your AI Autopilot

Use any AI provider (via WordPress 7.0 Connectors) to inspect and modify WordPress files directly from WP-Admin — within strict guardrails. No shell, no SSH.

Inspired by Matt Mullenweg to build this. Props to Cem Ünalan for the original idea of a plugin-generating plugin.

Try it in WordPress Playground →

UI

The page is a single full-screen chat. There is no built-in file browser or editor — file references in the AI's replies are clickable and adapt to what your site actually allows:

• If WordPress core's plugin-editor.php / theme-editor.php are available for the file type, the AI links straight to them so you can hand-edit in a new tab.
• Otherwise (e.g. on managed hosts that set DISALLOW_FILE_EDIT or DISALLOW_FILE_MODS, or for files outside plugin/theme dirs), the link expands a read-only inline viewer below the message and the AI is told to point you at SFTP / WP-CLI / your local IDE for edits.

A fresh chat greets you with a row of suggestion chips spanning the assistant's capabilities (one prompt each from file-ops, database, plugins, and PHP). Click a chip to drop the prompt into the input. The chips disappear once you send your first message, and a different set is rolled the next time you start a new chat.

When the AI proposes a file change a panel slides in above the chat showing a unified diff against the live on-disk content (so the diff is always current, not whatever you happen to have open in another tab). The panel disappears as soon as you approve, reject, or move on.

Configuration

The AI assistant always has access to wp-content/plugins/ and wp-content/themes/. Nothing else is ever accessible (not core, not wp-config.php, not .htaccess).

Optionally create wp-content/uploads/ai-edits/ as a scratch directory.

If Jetpack is installed and connected, the plugin enriches the system prompt with site-specific context (stats, top posts, referrers, search terms, active modules, plan tier, speed scores, social connections, security data) so suggestions are tailored to the site rather than generic. Without Jetpack, a dismissable banner appears at the top of the chat panel pointing to install/connect; everything else still works.

You can also launch the assistant from anywhere in WP-Admin via the command palette (Cmd/Ctrl+K → "Interact with AI").

Access control

Haydi requires WordPress's mapped edit_plugins capability as a hard floor, plus manage_options by default. On a normal single site this admits trusted Administrators. On Multisite, core denies edit_plugins to ordinary site Administrators, so only Super Admins can use Haydi. Core also denies this capability when file editing or file modifications are disabled.

Haydi includes tools that can modify files, run SQL and PHP, and change plugin state — run_php in particular can be used to grant the calling user any capability, including manage_options itself, so a lower floor is not a meaningful boundary. Mutating actions still require approval in the browser, but that approval comes from the same user who already has full access.

The additional capability is filterable when a site needs to restrict access further:

add_filter( 'haydi_access_capability', static fn() => 'manage_network_options' );

This filter cannot lower the edit_plugins floor. Use Settings → Haydi to restrict which model non-administrators with code-editing authority can pick. This is a browser-interface policy only and does not add model authorization to REST or MCP requests.

Remote Access (MCP / REST API)

Generate an API token under Advanced settings in the Haydi sidebar (Tools → Haydi) to connect local AI tools directly to your site.

Claude Code (and any MCP-compatible tool): add to ~/.claude/claude_code_config.json:

{
  "mcpServers": {
    "haydi": {
      "url": "https://yoursite.com/wp-json/haydi/v1/mcp",
      "headers": { "Authorization": "Bearer <your-token>" }
    }
  }
}

Claude Code can then use all Haydi tools (haydi_list_files, haydi_list_posts, haydi_write_file, haydi_run_query, etc.) as MCP tools — no browser needed.

The same token also works against the REST API directly: GET /wp-json/haydi/v1/files, GET /wp-json/haydi/v1/file, etc. Write operations execute immediately when authenticated via token; the token is the approval gate. Tokens are bound to the user who generated them, and that user's Haydi access is rechecked on every request. Tokens created before issuer binding was introduced are invalid and must be regenerated.

GET /wp-json/haydi/v1/status returns site info plus an allowed_roots array — the same paths exposed by the haydi_get_allowed_roots MCP tool — so clients can discover valid write targets without guessing.

How it works

Browser                   PHP (this plugin)           AI Connector (WP Connectors)
  │                             │                              │
  │── user message ────────────►│                              │
  │                             │── messages + tools ─────────►│
  │                             │◄── tool_use (list / read)    │
  │                             │   [execute locally]          │
  │                             │── tool_result ──────────────►│
  │                             │  (loop until done or approval needed)
  │                             │◄── tool_use (fetch / write / query …)
  │                             │   [NOT executed yet]         │
  │◄── Action Proposal ─────────│                              │
  │   [one approval card: URL, diff, SQL, PHP, …]              │
  │── "Approve" ────────────────►│                              │
  │                             │   [backup + write / execute] │
  │◄── success ─────────────────│                              │

list_files, read_file, search_files, list_plugins, list_posts, list_users, and list_options run automatically. In browser chat, fetch_url pauses so the user can inspect and approve the exact outbound URL before any request is sent. Everything that mutates the filesystem, database, or plugin state also pauses for human approval.

Token-authenticated MCP and REST requests execute fetch_url immediately; the token is the approval gate for those remote transports.

Tools

Built-in tools

Workflows

1. See a site → build a plugin

Fetch https://example.com/pricing and create a WordPress plugin that renders
the same pricing table as a [pricing_table] shortcode.

The AI proposes the URL fetch first. After you approve the exact URL, it reads the markup and proposes plugin files one at a time. You review each proposal and click Apply.

2. Modify an existing plugin

Open a file in the browser panel, then describe the change:

Add a $limit parameter (default 10) to list_posts() and pass it to WP_Query.

The AI reads the file, proposes the updated version, you diff and apply.

3. Reorganise plugin files

Rename class-old-name.php to class-new-name.php and update the class name inside it.

The AI reads the file, proposes a move_file to rename it, then a write_file with the updated class name. Each step requires your approval.

4. Create and query a database table

Create a table called wmp_feedback (id, post_id, rating, comment, created_at)
using the WordPress table prefix, then insert a test row.

Each CREATE, INSERT, or SELECT is shown to you before it runs. Results are fed back to the AI so it can continue automatically.

5. Install and configure a plugin

Install and activate WooCommerce, then configure it for selling digital products.

The AI checks what is already installed (list_plugins), proposes installing WooCommerce, activating it, and then uses run_php or run_query to apply configuration — one approved step at a time.

6. Restore a file from backup

My functions.php is broken after the last edit — restore it to the previous version.

The AI calls list_backups to find available backups for that file, presents what it found, and proposes restore_backup. A new backup of the current (broken) file is created first so the restore is itself reversible.

Security