Plato Artifacts

AI Provider for Codex (page title)

(Paragraph — deck)
A local-runtime Codex provider for the WordPress AI Client. WordPress workflows get Codex text generation; authentication and billing stay on each user’s own ChatGPT-managed account; no Codex or ChatGPT secret ever enters WordPress.

Problem

When a WordPress site uses an external AI runtime, the architectural question isn’t the model — it’s where authentication, billing, and runtime state live. The default answer is an API key in the database, which turns one credential into a shared site secret and turns WordPress into a token store. My constraints ruled that out from the start: no Codex or ChatGPT secrets in WordPress — not in options, not in user meta, not in custom tables; one user’s account must never become the site’s account; and the browser never talks to the runtime directly.

Build

The answer is a boundary, then code that enforces it. The plugin registers a codex provider with the WordPress AI Client and owns only the WordPress side: a Connectors card, site runtime settings, per-user connection metadata, cached account snapshots. Everything sensitive lives across a hard line — a localhost sidecar that wraps codex app-server, runs the device-code login, and holds each user’s account state in isolated runtime storage. WordPress talks to that sidecar over loopback HTTP with bearer auth, and to nothing else. And when WordPress’s experimental Connector Approval gate is active, the provider registers through it — if approval is revoked, runtime calls stay blocked until an administrator re-approves. Governance primitives respected, not routed around.

The design came from a deliberate divergence-first pass: five candidate architectures — direct calls, WordPress-stored tokens, a hosted broker, callback OAuth, a local sidecar — collapsed against seven rejection criteria. The sidecar survived as the simplest boundary that satisfied every constraint. Then the boundary became enforceable: regression coverage in the verify pipeline specifically protects the loopback transport, so the architecture is part of the release contract, not a diagram. The full ideation record ships in the repo.

Outcome

1. Architectural boundary enforced: Five tagged releases in 23 days — v0.1.1 (May 22, 2026) through v0.1.5 (June 13, 2026) — each shipped from a green gate: verify suite, PHPStan, release-lane Plugin Check with zero errors, and a clean WordPress 7.0 Playground install from the release zip. The shipped build proves the boundary it claims: sidecar smoke test returns health 200, rejects a bad bearer with 401, serves the authorized route 200.
2. Isolation by construction: Zero Codex or ChatGPT credentials stored in WordPress; per-user account isolation by construction.
3. Flat billing as consequence: Because auth and billing ride each user’s own ChatGPT-managed account, the workflows this plugin serves run on flat subscription economics — no metered API spend in the loop.
4. Scope stated honestly: Self-managed hosts only, text generation only — stated in the readme, not the fine print.

(Buttons block — artifact row)
GitHub repository · v0.1.5 release · Ideation record

(Paragraph — close)
Same rule as everything else on this site: trust is structural. Here it’s applied to credentials — where state lives is a design decision, and the boundary has tests.

Note: the author’s first paste-ready draft listed the Outcome as four flat facts; the published page reorders them into the causal sequence above (boundary enforced → isolation → flat billing → scope). Reproduced here in the published order.

Expose, Govern, Attest — WordPress’s AI stack as a trust model

WordPress’s AI features look like scattered experiments until you see the stack underneath — three nested layers, each doing what the one before it can’t. The Abilities API exposes WordPress as discoverable, schema-described capabilities an agent can invoke. A governance plane — connector approvals and request logs today, a unified permissions layer next — governs what those capabilities may do and records every call inside your own walls. And a C2PA provenance layer attests to the output itself, signing it so its origin survives after it leaves the site. Exposure makes WordPress usable by agents; governance makes that use accountable to you; attestation makes the result verifiable to everyone else. Read as a stack rather than a feature list, that’s one trust model in three rings — and it’s the project’s own direction, visible on the public roadmap, not a thesis I’m imposing on it.

Expose — capabilities an agent can discover

The foundation already shipped. WordPress 6.9 introduced the Abilities API as a PHP registry that lets core, plugins, and themes declare their capabilities in a standardized, machine-readable format (Make Core, Nov 2025), and 7.0 added the client-side JavaScript counterpart and folded it into the WP AI Client so abilities can be chained into workflows (Make Core, Mar 2026; 7.0 Field Guide). The agent-facing layer on top is still converging in the open: a foundational `core/*` ability set (#40), a proposal to map “Skills” into the WordPress admin (#430), and the open question of how to expose thousands of abilities to an external agent without drowning its tool selection (#21). The shape is consistent: a capability declares its own contract — name, description, JSON schema — so what WordPress can do is inspectable, not asserted.

Govern — accountable to the owner

This is the only ring with primitives already in users’ hands. AI 1.0.0, released 19 May 2026, shipped two of them: Request Logging, observability into every AI request and response generated through core, plugins, and themes; and Connector Approvals, letting an administrator gate which plugins may use a configured AI provider (What’s new in AI 1.0.0). The next step is in active discussion — a Unified AI Management Layer for Core (#348) consolidating permissions, usage metering, and capability-aware provider routing into one plane, with a live design debate over whether access should be allow- or deny-by-default, where the maintainers lean deny. There’s even a live gap that maps onto my own work: request logging currently can’t see providers that use a custom transport rather than the SDK’s HTTP path (#732) — the exact sidecar boundary my `ai-provider-for-codex` plugin sits on. The principle of the ring: you read the audit log to know what an agent did, rather than trusting that it behaved.

Attest — verifiable to everyone else

The newest ring, and entirely in flight — which is itself the tell that it matters. A deliberate C2PA family is in review: read-only detection of Content Credentials on upload (#459), cryptographic signing of post text (#294), and signing of images with CDN edge-worker templates (#302), under an umbrella issue to detect provenance manifests on upload (#421). By code volume it is the single largest in-flight theme on the AI board. The reason is structural. A governance log proves something to you, the owner; a signed manifest proves origin to a stranger who was never inside your system and never saw your logs. Once content leaves the site — into a search result, a repost, a dataset you’ll never see — an inward control can’t follow it; the claim has to travel with the artifact. That is a different primitive from governance, and it’s the one that regulated AI-labeling rules actually require, because a label is worthless the moment it stops surviving redistribution. Worth stating plainly, because the honesty is the point: these three rings are at different maturities by design. Govern has shipped primitives, Expose is shipped at its foundation with the agent-facing layer still in proposals, and Attest is entirely in-review pull requests. That’s where core is, not where I wish it were.

Why this is the same idea I was trained on

The reason I read the stack this way comes from the program I’m in. Foundation 5 was about measuring impact, and Blake Bertuccelli-Booth’s argument for the whole AI Leaders model sharpens it: workforce-development programs carry the strongest causal evidence of any category of economic investment not because they’re virtuous, but because they’re measured against instruments they don’t control — standardized federal performance indicators, unemployment-insurance wage records, decade-long randomized trials — while startup incubators grade their own homework on self-reported, survivorship-biased numbers. Real impact is whatever survives an external instrument. Read through that lens, the three rings are an accountability architecture, and each ring is an instrument someone other than the author can read: a schema others can inspect, a log others can audit, a signature a stranger can verify. My ethics position in the program was already this — trust isn’t a disclaimer you append after the model answers, it’s built into the workflow — and I’d worked it out in the cohort channel from people solving nothing like my problem: battery governance in Mongolia, AI in the classroom, what a portfolio should actually prove. Same shape every time. The test of whether I hold the principle or just describe it is how I measure my own work: I don’t claim my core contributions are good, I point at the open review state and the changelog line, and I check a pull request’s merged-or-open status against GitHub rather than my own notes — impact read off someone else’s instrument, not a dashboard I built. I did the same a level up inside the program, in a tooling proposal that handed the workforce-outcome framing real measurement infrastructure: a day-one baseline survey, an engagement floor, opt-outs treated as a comparison group — because without a baseline, “confidence shifted” is unverifiable.

How I navigate the change

I work in the part of WordPress that changes faster than my knowledge of it can settle — the 7.0 AI stack is still stabilizing, and anything I “know” about it is one release from stale. So I don’t navigate it by holding a confident model of the field; I navigate it by refusing to assert and reading instruments I didn’t write. No single source is complete, so I run several in parallel: changelogs from the major providers, model releases and software both, read against the primary docs by hand and through scripts; ChatGPT’s Pulse for curated digests in the niches I care about, WordPress among them; Perplexity and Google for the wider net; and GitHub, which is effectively my homepage on desktop and mobile, where I watch my own work and other developers’ in one view. For the projects that matter I keep living roadmap documents — the WordPress AI one runs a repo census on every refresh, because even the official board misses pull requests. I hold the agents I rely on to the same standard, grounding them in vector databases I build with Cloudflare’s AI Search so they answer from retrieved sources instead of improvising. And I build the discipline into what I ship: suggestions stay review-first, every applied change leaves an audit row, the proof bar on my site renders state and never intent. When a fact carries weight I read it off GitHub’s merged-or-open state, not my notes, and I’ll correct a same-day snapshot against the live page rather than defend it — the same logic that has me measure a program with baseline surveys instead of sentiment. Rapid change doesn’t push me to move faster or guess better; it pushes me to trust instruments over assertions, mine included.

AI Leadership 5 Ideation Artifact: AI Provider for Codex

Artifact status

This artifact documents the AI-assisted ideation and iteration process behind `ai-provider-for-codex`, a shipped WordPress AI Client provider plugin.

The ideation prompts below are labeled as reconstructed prompts because the exact private AI chat transcripts are not confirmed recoverable. They are grounded in repo artifacts including `CLAUDE.md`, `LOCAL-SIDECAR-SPEC.md`, and the Superpowers specs/plans under `docs/superpowers/`.

1. Original problem

I wanted WordPress AI workflows to use Codex without requiring direct API billing, exposed secrets inside WordPress, or a fragile custom authentication flow.

The core architectural problem was deciding where authentication, billing, runtime state, and WordPress provider integration should live. The defining constraint became: the PHP plugin never talks to OpenAI or Codex directly. It talks only to a localhost sidecar runtime.

2. Reconstructed ideation prompts

Prompt 1: Architecture option space

I am building a WordPress AI Client provider that lets WordPress workflows use Codex. I do not want WordPress to store Codex or OpenAI secrets or require direct API billing. What architectural patterns could connect a WordPress plugin to Codex while preserving security, user isolation, and a WordPress.org-style provider experience?

Why this prompt was structured this way: This was the divergent prompt. I needed AI to widen the architecture space before committing to implementation. The goal was not to get code. The goal was to surface patterns I could compare.

Options this helped generate: (1) WordPress calls Codex directly. (2) WordPress stores auth state locally. (3) A hosted broker handles auth and runtime behavior. (4) A callback-based login flow connects users. (5) A localhost sidecar handles Codex runtime and auth.

Resulting decision: The local sidecar survived because it kept secrets out of WordPress, preserved per-user isolation, avoided a hosted control plane, and let WordPress remain a normal provider plugin.

Prompt 2: Authentication and per-user isolation

How should a WordPress plugin isolate per-user authentication state for an external AI runtime if the plugin should not store access tokens in WordPress options, user meta, or the database?

Why this prompt was structured this way: This narrowed the problem from general architecture to the hardest constraint: auth state. I needed to know where account state should live and how to prevent one user’s Codex account from becoming a shared site credential.

Options this helped evaluate: (1) Store tokens in WordPress user meta. (2) Store encrypted tokens in a custom WordPress table. (3) Use one shared site-wide Codex account. (4) Store per-user auth outside WordPress in runtime-owned storage. (5) Let a separate local process own device-code login and account snapshots.

Resulting decision: The sidecar owns per-user `CODEX_HOME` storage. WordPress only stores connection metadata and cached account/model snapshots. That preserves account separation and avoids storing Codex auth secrets in WordPress.

Prompt 3: Account connection UX

For a WordPress admin user connecting a Codex or ChatGPT account, what are the tradeoffs between device-code login, callback-based OAuth, and a manual setup flow? The browser should never talk directly to the localhost sidecar, and the flow needs to work from wp-admin.

Why this prompt was structured this way: This prompt focused on user experience and browser constraints after the sidecar architecture was selected. I needed to decide how users would actually connect accounts without violating the runtime boundary.

Options this helped evaluate: (1) Full callback-based OAuth. (2) Manual copy/paste setup. (3) Redirecting users to a separate connection page. (4) Device-code login with WordPress REST polling. (5) Progressive enhancement from the Connectors screen and user connection page.

Resulting decision: Device-code login was the best fit. It avoided public callback endpoints, worked inside wp-admin, kept browser traffic routed through WordPress REST, and allowed the sidecar to own Codex auth.

3. Rejection criteria

The weaker options were rejected using these criteria: (1) Preserve WordPress AI Client compatibility. (2) Keep each WordPress user’s Codex account isolated. (3) Do not store Codex auth secrets in WordPress options, user meta, or custom tables. (4) Do not let browser JavaScript talk directly to the localhost sidecar. (5) Preserve a WordPress.org-style provider UX. (6) Avoid a hosted control plane unless it is actually required. (7) Make the architecture enforceable through repeatable verification.

4. Chosen architecture

The selected direction was a local sidecar architecture. WordPress stays the provider plugin. It owns provider registration, wp-admin UX, local settings, cached metadata, and WordPress REST endpoints. The localhost sidecar owns Codex runtime behavior, ChatGPT/Codex authentication, and per-user account state.

flowchart LR
    A[WordPress AI Client] --> B[AI Provider for Codex plugin]
    B -->|Loopback HTTP, bearer auth| C[Localhost sidecar runtime]
    C -->|JSON-RPC / stdio| D[codex app-server]
    D --> E[ChatGPT / Codex]

    B -. stores .-> F[Connection metadata and cached snapshots]
    C -. stores .-> G[Per-user CODEX_HOME auth state]

Core boundary: The important architectural boundary is that WordPress does not own Codex auth. WordPress only coordinates provider UX and local metadata. The sidecar owns runtime/auth behavior.

5. Iteration trail: local runtime generation transport

I selected the local runtime generation transport fix as the iteration trail because it shows AI-assisted refinement from review finding to architectural correction to regression-proof enforcement.

Exchange 1: Diagnose the transport regression. Me → AI: “Review the generation transport change. I want Codex to remain registered as a normal WordPress AI Client provider, but generation needs to reach the documented localhost sidecar URL.” AI → Me: identified that routing generation through the WordPress AI Client HTTP transporter was wrong for this runtime boundary because that path used `wp_safe_remote_request()`, which rejected `http://127.0.0.1:4317`. The local sidecar was reachable through `wp_remote_request()`, so the issue was not the sidecar — it was the safe transporter path. Annotation: This exchange separated the actual bug from the architecture.

Exchange 2: Preserve provider registration while fixing runtime traffic. Me → AI: “Do not bypass the WordPress AI Client provider/model contract. Fix the local transport problem while keeping Codex available as a normal provider.” AI → Me: proposed keeping provider registration and model creation inside the WordPress AI Client, but sending actual sidecar generation requests through the plugin’s existing `Runtime\Client::post()` path. Annotation: The key architectural refinement — the provider interface and the runtime transport did not need to be the same abstraction.

Exchange 3: Turn the fix into a regression-proof change. Me → AI: “Make this release-safe. I do not want the same loopback transport mistake to come back later.” AI → Me: produced a plan to add verification coverage in `scripts/verify.php`, remove the unused transporter helper, update the readiness checklist, and run release-style checks; the regression test specifically covered text generation through the default loopback runtime URL. Annotation: This moved the work from “patch the bug” to “protect the boundary.”

Exchange 4: Scope control. Me → AI: “Do not expand this into AI request logging, global transporter replacement, or broader provider behavior changes.” AI → Me: added explicit non-goals — do not change admin/auth/snapshot traffic, do not widen the sidecar beyond loopback, do not register a global replacement HTTP transporter, and do not claim AI Request Logging support in this fix. Annotation: This prevented control-plane complexity from creeping back in.

6. Reflection

AI was most useful when I used it to widen the architecture space before implementation. It helped generate options I might have collapsed too quickly. The value was not that every option was good — the value was that I had a broader set of possibilities to reject using concrete constraints. AI was weaker when the conversation drifted toward more control-plane complexity; without constraint pressure, the design accumulated extra layers. The project improved when I forced every idea through the same criteria. The meta-lesson is divergence first, then constraint-driven convergence: ask AI for competing designs, define rejection criteria, choose the simplest boundary that satisfies the constraints, then encode that boundary in specs and verification scripts. AI is most useful when it produces options I can eliminate, not just code I can accept.

7. Evidence sources

Primary repo artifacts: `CLAUDE.md` (the defining sidecar constraint and runtime boundary); `LOCAL-SIDECAR-SPEC.md` (implementation spec, goals, non-goals, sidecar contract); `docs/superpowers/plans/2026-05-21-local-runtime-generation-transport.md` (iteration plan for the loopback generation transport correction); `docs/superpowers/specs/2026-05-22-codex-connect-ux-design.md` (UX architecture spec); `docs/superpowers/plans/2026-05-22-codex-connect-ux.md` (implementation plan for the connection controller and Connectors/user-page flow); `docs/superpowers/plans/2026-05-22-connection-flow-review-remediation.md` (review remediation plan with regression coverage). GitHub repo: https://github.com/henryperkins/ai-provider-for-codex

Positioning paragraph (ports to /about):

I’ve always been drawn to the systems underneath things — infrastructure, online communities, and the tools people rely on every day. The customer-facing work shaped how I approach problems: let people speak, assume positive intent, and meet them where they are, because the first version of the problem usually isn’t the real one. That’s the kind of work I want to do — helping people navigate complex systems and making those systems better because I understand the people using them.

Cohort intro (final posted version):

Hey everyone — I’m Henry. I tried to start a hosting company for vBulletin forums when I was 20, and I’ve been chasing the systems behind communities ever since. That took me through repair triage at Micro Center, writing tutorials and onboarding developers at PageLines, running Starbucks shifts, and now building AI workflows and web tools. Customer-facing work taught me to let people speak, assume positive intent, and remember that the first version of the problem usually isn’t the real one. I’m here to learn from people doing thoughtful work and build AI that actually helps.

Planned About evidence tier (from the WordPress 4/6 outline — not yet drafted as final prose): present-tense positioning first; operations backstory compressed as relevance (“the customer doesn’t care about your stack”); ecosystem history stated plainly — former Automattic Happiness Engineer / WordPress.com support (scoped 2012 engagement), PageLines developer community, WordCamp participation; the generalizing sentence for the FDE reader; resume as HTML + PDF, one click from anywhere.

⚠ Unresolved inside the planned About tier: the outline carries “six WordCamp talks,” but participation was as a PageLines sponsor/booth representative, not a speaker. Correct before drafting the final About prose.