What Is OpenAI Codex Sites? Prompt-to-Hosted-App, With a Catch

OpenAI shipped a new piece of Codex called Sites, and it's the kind of thing that makes me
stop and think about where this is all going. The pitch is short and bold: describe an app in plain
language, and Codex builds it, tests it, deploys it, and gives you back a live URL — no deploy
pipeline of your own, no server to provision, nothing. Prompt in, hosted app out.

That's a real step up from "an agent writes code." This is an agent that writes the code and ships
it. Worth a look — and worth an honest look at the fine print, because there's a fair bit of it.

What Codex Sites actually does

Sites is a Codex plugin. You're working in a Codex thread as usual, and when a task should end in
something deployed, you call it explicitly with @Sites. From there Codex runs the full loop for
you:

1. Builds the project from your description (or from a compatible existing project).
2. Runs it to test that it actually works.
3. Deploys it to an OpenAI-hosted URL.
4. Shares it inside your workspace via that URL.

The whole "get it onto the internet" part — the bit that's usually a separate, fiddly chore — is folded
into the agent's job. You describe the outcome; the deployment is a side effect.

What people are building with it skews toward internal, team-facing tools: dashboards built from
your own analysis, planners, review workspaces, project boards, galleries, small interactive utilities,
even little games. The recurring theme is a shared place your team can open by URL — somewhere to
explore work, drop input, and make a decision — rather than a polished public product. Think "spin up
the internal tool we keep saying we'll build someday," in the time it takes to describe it.

Why it's interesting

I've written a lot lately about the layers of building with AI
— chat, agent, harness. Codex Sites is interesting because it pushes the agent layer one notch
further than we usually see: the agent's reach now extends past "edit files in a repo" all the way to
"there is a running thing at this address." Deployment has always been the unglamorous last mile that
separates a demo from something a colleague can actually use. Collapsing that last mile into the same
prompt is a meaningful change in what "the agent did it" means.

It also fits a pattern I keep noticing: the most useful agent features aren't the flashiest models,
they're the ones that remove a whole step from the loop. No build config, no hosting account, no
"now copy this to a server." For throwaway internal tools — the ones whose value is existing today,
not being beautiful — that friction removal is the entire point.

The catch (read this before you get excited)

Here's where I keep myself honest, because the limits are significant and easy to miss in the
excitement.

It's Enterprise/Business only. As it launched, Sites is a preview for ChatGPT Business and
Enterprise customers. If you're on Plus or Pro, a solo builder, or a freelancer, you can't use
it today — even though plain Codex is already on your plan. That's a notable line in the sand: the
"agent ships your app" capability is, for now, gated behind the top tiers.

It's a walled garden, by design. The hosted apps come with real constraints out of the gate:

• No custom domain — you live on an OpenAI-hosted URL.
• No public URL — it's for sharing inside your workspace, not the open internet.
• No code export — what you build there stays there; you don't get to take the project and run.
• No payments — these aren't apps you monetize.

Put together, that tells you exactly what Sites is for right now: internal team tooling, not
shipping a public SaaS. It's "build the dashboard the ops team needs by Friday," not "launch my
startup." Which is a perfectly good use case — but it's a different one than the headline might make you
assume, and the no-export part in particular is worth weighing if you care about lock-in.

Where it sits in the bigger picture

Sites didn't arrive alone. It was part of a broader Codex update positioning the tool as an agent that
builds interactive enterprise workspaces, not just code — alongside a set of role-specific plugins
and an expanded annotations feature. The direction is clear: OpenAI wants Codex to be the thing a whole
organization uses to turn intent into running internal software, each role with its own on-ramp.

My take? The capability is the exciting part and the packaging is the cautious part. Prompt →
built → tested → deployed → shared is a genuinely strong loop, and seeing it work end-to-end is a
little glimpse of the near future. But the Enterprise-only gate and the no-export/no-public-URL walls
mean that, for most individual developers reading this, it's a "watch the space" rather than a "use it
this afternoon." If you're inside a Business or Enterprise workspace, though, it's worth trying on the
next internal tool you'd otherwise put off building.

I'll be keeping an eye on whether the walls come down — custom domains, code export, and lower tiers are
the obvious next asks. If you've gotten your hands on it, tell me how it feels in practice — I'm always
listening on the links on the about page.