Jonathon's AI Wiki

OpenAI Codex Sites — Building Autonomous Self-Updating Apps

7 min read

Source: raw/OpenAI_Codex_-_Build_Apps_That_Work_For_You_24_7.md — Greg Isenberg, Startup Ideas podcast (YouTube tUeSxXHmE9w, 2026-06), a live-build walkthrough of OpenAI’s Codex Sites with a 6-prompt worked example. Single creator-demo source (no OpenAI affiliation); confidence medium.

OpenAI Codex Sites is an app-builder that lives inside Codex (invoked as a plugin with @sites). Its differentiator vs Replit / Lovable / Bolt is not one-shot scaffolding — it’s autonomous, self-updating apps: products an agent keeps operating and editing for you after launch. The tradeoff is that it ships bare (no database, payments, email, analytics, or secrets vault out of the box — you prompt those in), so it rewards people who already live in Codex and understand a little auth/DB/payments. The transferable value for any agentic builder is the four-pattern discipline Isenberg teaches — memory → safe actions → skills → save gates → prove-the-loop — which generalizes well beyond Codex.

Key Takeaways

  • What it is: an app builder invoked inside Codex as a plugin (@sites). Builds internal/team apps that an agent can keep updating autonomously after they ship — the headline use case is a product that edits itself (e.g. a personal site that auto-updates subscriber counts and generates guides from your content).
  • vs Replit / Lovable / Bolt: those win for simple one-prompt apps — they bundle editor, database, server, hosting, and domain registration. Codex Sites ships without database, payments, email sending, analytics, or a secrets vault; you prompt each in. Pick Codex Sites when you live in Codex and want autonomy over turnkey simplicity.
  • The reusable discipline (4 patterns): an app is “just a demo” until you add memory (persistent storage), safe actions (a named-mutation boundary so agents can’t run arbitrary SQL), skills (a reusable instruction manual so future chats can operate the app), and save gates (explicit checkpoints — it does not auto-save). Then prove the loop from a fresh chat.
  • “Safe actions” is the load-bearing idea — explicit named mutations (add idea, move idea, score idea) so the agent calls a tightened action boundary instead of arbitrary database writes. This is what lets you (or a cron agent) safely edit a live app from any other Codex chat with @ add idea ….
  • Storage is BYO but Codex picks a default: prompted for persistent storage, Codex proposed Cloudflare D1 as the durable store. The community is also pairing Codex Sites with Convex.
  • Built-in plugins extend a site: Figma, Canva, HeyGen (avatar video — see Hyperframes), Remotion, Game Studio, FAL AI (image gen), Hugging Face (open models).
  • Known limitations at record time: apps deploy to a random URL — no custom domains yet; they’re internal/team-share only; auth is built in (sign-up required). Isenberg expects custom domains “very soon.”

The 6-prompt worked example — “Startup Ideas OS”

A live Kanban board (columns: inbox → researching → validating → building → killed); each card carries idea, buyer, pain, proof, next step, and score. Built in six prompts, each teaching one pattern:

  1. Shell — invoke @sites, “Build a startup OS.” Tips: ask for realistic sample data, and add “save for review, do not deploy” (Codex sometimes auto-deploys). This “unlocks building a real product, not a homepage.”
  2. Memory — “Add persistent storage so ideas stay saved between visits. Before coding, show me the data model and which records and actions the app needs.” Codex inspects the schema and proposes Cloudflare D1, one record type (idea: full card content, current column, owner email) and the actions list (list / add / update / move / score / archive). Asking for the data model first is what surfaces the safe-action set.
  3. Safe actions — “Create safe actions for add idea, update idea …” Codex tightens routing into “an explicit safe action boundary so the agent can only call named mutations rather than arbitrary SQL.” If you don’t know what safe actions to create, ask Codex (the data-model step already enumerated them).
  4. Skills — “Create a Codex skill called Startup Ideas Admin. It should explain how to read the board, add ideas, move cards, score ideas, and include five example commands.” Codex writes it into the local skill directory and validates it on creation (“Validation pass. The skill is valid”). The skill is the reusable manual that lets later chats operate the app.
  5. Save gates — “Save this as V1 review. Do not deploy. Confirm build status, storage choice, access setting, and the exact version I should review.” Because Codex does not auto-save, you set explicit checkpoints (like video-game saves) before a live URL.
  6. Prove the loop — in a new chat: “Use Startup Ideas Admin to add [idea]. Put it in inbox with a first-pass score and next step.” Codex spins up a fresh thread, loads the skill, and updates the board using only the safe board API (“no raw SQL, no generic database writes, and no deploy”). From here you can wire a cron/automation to auto-add ideas weekly — the “app that works for you 24/7.”

Transferable patterns (steal these even outside Codex)

  • Data-model-first prompting. Asking the agent to show the records + actions before writing code is what makes the rest deterministic — it forces an explicit interface instead of letting the agent improvise schema.
  • Named-mutation boundary (“safe actions”). Constrain an agent to a small set of named operations rather than arbitrary DB/SQL access. This is the same least-privilege instinct as MCP tool whitelisting — it’s what makes “let an agent edit my live app” safe.
  • Operation manual as a skill. Encode “how to operate this app” once as a reusable skill so any future agent session can drive it correctly — the same reusable-instruction pattern Claude Code uses (see Skills Ecosystem).
  • Save gates + prove-the-loop. Don’t trust auto-save; checkpoint explicitly, then validate the whole loop from a cold start (fresh chat) before trusting autonomy.

Try It

  • Decide the fit first: choose Codex Sites for an internal, self-updating tool you’ll let an agent maintain — not for a polished public site needing a custom domain today (use Replit/Lovable for that).
  • Run the 6-prompt sequence on a real internal need (a triage board, a personal-site auto-updater): shell → memory (data-model-first) → safe actions → skill → save gate → prove-the-loop-in-a-fresh-chat.
  • Lock the boundary: insist on named safe actions and verify the prove-the-loop run reports “only the safe API, no raw SQL, no deploy” before wiring any cron automation.
  • Bring your own data layer (Cloudflare D1 or Convex) and expect to prompt in payments/email/analytics/secrets yourself.
  • Agents & Agentic Systems — the topic hub for autonomous-agent tooling and patterns.
  • Claude Opus 4.8 — the launch-week operator consensus that “Codex vs Claude Code is the real war” (the harness matters as much as the model); Codex Sites is part of that harness race.
  • Dynamic Workflows in Claude Code — the Claude-side autonomous-orchestration primitive; Codex Sites is the OpenAI-side autonomous-app analog.
  • Claude Code Skills Ecosystem — Codex “skills” mirror Claude skills as reusable instruction manuals for agents.
  • HeyGen Hyperframes — HeyGen (a Codex Sites plugin) for agent-authored avatar/motion-graphics video.

Open Questions

  • Custom domains + public deploy. Internal/random-URL-only at record time; custom domains were predicted “soon” but unconfirmed.
  • Single-source / creator-demo. All specifics trace to one Greg Isenberg walkthrough; the safe-action routing internals, D1 schema details, and skill-validation mechanics are creator-reported, not from OpenAI docs. Verify against official Codex Sites documentation before relying on exact behavior.
  • Cron/automation surface. Isenberg references wiring a weekly auto-add automation but defers the how-to; the actual scheduling primitive inside Codex Sites is uninventoried here.

Graph View

Backlinks