{"id":114,"date":"2026-05-26T21:19:39","date_gmt":"2026-05-26T19:19:39","guid":{"rendered":"https:\/\/halawa.io\/blog\/?p=114"},"modified":"2026-05-26T21:20:57","modified_gmt":"2026-05-26T19:20:57","slug":"wordpress-7-ai-chatgpt-subscription-without-api-key","status":"publish","type":"post","link":"https:\/\/halawa.io\/blog\/wordpress-7-ai-chatgpt-subscription-without-api-key\/","title":{"rendered":"Plug WordPress 7.0 AI Into Your ChatGPT Subscription – Without an API Key"},"content":{"rendered":"\n

WordPress 7.0 ships first-class AI providers. The reaction online has been almost entirely about the bill: drop in an Anthropic or OpenAI API key, forget you did it, and discover next month that a content workflow has been quietly burning tokens at full retail.<\/p>\n\n\n\n

The warning is fair. People will get charged. But the framing, that this is WordPress’s fault, misses where the policy actually lives.<\/p>\n\n\n\n

The vendor policy WordPress can’t fix<\/h2>\n\n\n\n

Anthropic explicitly bans third-party apps from using Claude Pro\/Max session auth. Claude Code is the exception because Anthropic owns it. Everyone else is told to use an API key billed against an API account, separate from the consumer subscription. So even if WordPress wanted to ship a “use your Claude subscription” option, Anthropic’s terms wouldn’t permit it.<\/p>\n\n\n\n

OpenAI is different in a way that matters. The Codex CLI authenticates with your ChatGPT account over OAuth and routes requests through the same backend that powers chatgpt.com<\/code>, billed against your ChatGPT Plus\/Pro plan rather than an API account. The login flow lives in their public repository. There is no policy banning third-party clients from doing what Codex does. The design is just publicly documented.<\/p>\n\n\n\n

That gap is what this plugin steps into.<\/p>\n\n\n\n

What I built<\/h2>\n\n\n\n

AI Provider for ChatGPT<\/a><\/strong> is a WordPress plugin that registers ChatGPT as a first-class AI provider, the same surface as the official OpenAI, Anthropic, and Google plugins, but authenticates with your ChatGPT account instead of an API key. Once paired, every WP 7.0 AI feature on the site routes through your subscription. The server handles token refresh on its own. No API account, no per-token bills.<\/p>\n\n\n\n

The proof-of-concept I showed on LinkedIn required you to run codex login<\/code> on your laptop and paste ~\/.codex\/auth.json<\/code> into the plugin settings. It worked end-to-end on video, but it was a developer-only UX, so I never published it in that shape. The released version replaces the paste step with a companion CLI:<\/p>\n\n\n\n

npx @abdalsalaam\/chatgpt-wp-connect https:\/\/your-site.example <pairing-token><\/code><\/pre>\n\n\n\n
Click Connect with ChatGPT<\/strong> in the WordPress admin, copy the command, run it on any machine that has a browser. The CLI opens an OpenAI sign-in page, runs the OAuth PKCE flow on 127.0.0.1:1455<\/code>, then posts the resulting bundle to a one-time pairing endpoint on your site. The WordPress tab connects automatically. No copy-pasting of secrets.<\/p>\n\n\n\n
How it works<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The trick that makes the two-piece design work: OpenAI’s allowlist for the public Codex client only permits http:\/\/localhost:1455 (and 1457 as fallback)<\/code> as redirect URIs. That restriction applies to the *authorize* step only. Token refresh and API calls have no such restriction. So once the bundle is paired, the WordPress server handles refresh and every subsequent API call on its own. The laptop is out of the loop forever.<\/p>\n\n\n\n
The pairing protocol<\/h2>\n\n\n\n
A CLI on your laptop posting tokens to your server is exactly the kind of “convenience” feature that tends to be sloppy in the security model. The pairing endpoint has six properties worth naming explicitly:<\/p>\n\n\n\n
    \n
  1. 256-bit, single-use token.<\/strong> Minted by an admin-only REST route.<\/li>\n\n\n\n
  2. Hashed at rest.<\/strong> Only the SHA-256 is stored; the raw token never touches the database.<\/li>\n\n\n\n
  3. 10-minute TTL.<\/strong> Issuing a new token revokes any prior outstanding one.<\/li>\n\n\n\n
  4. Atomic redemption.<\/strong> Using delete_transient<\/code>‘s boolean return value, so two concurrent redemptions can’t both win.<\/li>\n\n\n\n
  5. Per-IP rate limit.<\/strong> 10 attempts per minute by default, filterable.<\/li>\n\n\n\n
  6. Generic error responses.<\/strong> Parser internals never leak to unauthenticated callers.<\/li>\n<\/ol>\n\n\n\n
    The OAuth bundle itself is encrypted at rest with sodium_crypto_secretbox<\/code>, using a 32-byte key derived from AUTH_KEY<\/code> and LOGGED_IN_KEY<\/code>. The plugin refuses to read or write tokens when those salts are missing, shorter than 32 chars, or still set to the wp-config placeholder. A SQL dump alone is not enough to recover the tokens.<\/p>\n\n\n\n
    What you trade for the convenience<\/h2>\n\n\n\n
    This plugin works today and the engineering is real, but the trade-offs are not subtle and they belong above the fold:<\/p>\n\n\n\n