OpenAI has introduced Sites, a new Codex plugin that lets Codex create, save, deploy, and inspect hosted websites, web apps, dashboards, internal tools, and lightweight games.
The feature was announced as part of OpenAI's June 2 update, "Codex for every role, tool, and workflow." The important shift is that Codex is no longer only helping users write code or edit a repository. With Sites, it can also turn a prompt or compatible existing project into a hosted work artifact that teammates can open by URL.
That makes Sites one of the clearer signs that OpenAI wants Codex to become useful beyond software engineering.
What Sites does
Sites is built for creating and hosting web-based artifacts directly through Codex. OpenAI's examples include:
- customer review pages
- financial scenario planners
- launch hubs
- project trackers
- service-rep guides
- creative brief repositories
- dashboards
- planners
- galleries
- lightweight internal tools
- simple games and interactive experiences
That list matters because it points Codex toward everyday knowledge work. Analysts, sales teams, marketers, product managers, operators, designers, investors, and researchers may not want a codebase first. They often want a working page, calculator, tracker, dashboard, or review room that can be shared with the team.
Sites gives Codex a direct path to create that kind of artifact.
How publishing works
Sites uses a two-step publishing model.
First, Codex can save a version of the site. That gives the team a deployable candidate to review. Then, once the saved version is approved, Codex can deploy that version and return a production URL.
That distinction is important. OpenAI's docs say every Sites deployment URL should be treated as production. If a team needs review, approval, or internal testing first, the safer workflow is to save a version before deploying it.
Once a Sites project exists, Codex can also inspect saved versions, check deployment status, change access settings, and manage hosted environment variables and secrets.
Sharing and access
Sites are designed around workspace sharing. The preview supports several access modes:
- owner and workspace admins only
- all active users in the workspace
- specific active users or workspace groups
That makes Sites most immediately useful for internal apps, team dashboards, controlled prototypes, review surfaces, and planning tools.
The public-web details are less clear. OpenAI has not yet published enough information to make strong claims about public sharing, custom domains, traffic limits, storage quotas, production SLAs, or long-term hosting economics.
What builders need to know
Sites can start from a prompt, but it can also work with existing projects if they are compatible.
The key technical constraint is that Sites hosts projects that build to Cloudflare Worker-compatible ES module output. Builders bringing an existing app into Sites should ask Codex to check compatibility before assuming it will deploy cleanly.
The docs also describe support for durable app needs through D1-style relational database storage and R2-style object storage for files. That gives Sites a more practical shape than a static-page generator, especially for dashboards, planners, galleries, and internal tools that need to remember records or handle uploads.
Availability and pricing
Sites is currently in preview for ChatGPT Business and Enterprise workspaces.
Business workspaces have Sites enabled by default. Enterprise admins must enable it through role-based access controls before members can use it. OpenAI says more plans will roll out later, but has not given dates.
Sites is free while in preview. OpenAI's pricing page says pricing information will be available soon.
Why this matters
Sites matters because it collapses several steps that usually slow down internal software work.
A team can move from "we need a tracker, calculator, dashboard, or review page" to a working hosted URL without immediately setting up a deployment pipeline or waiting for a full engineering cycle.
That does not make engineering irrelevant. Serious production systems still need security review, reliability work, data governance, and maintainability. But for many internal workflows, the first useful version does not need to start as a full software project.
The bigger shift is that Codex is moving from coding assistant toward work artifact builder. Instead of only helping write the thing, Codex can now help host the thing.
What to watch
Because Sites is still in preview, teams should be careful about treating it as permanent infrastructure too quickly.
The open questions include:
- hard usage limits
- storage and traffic quotas
- custom domain support
- public sharing behavior
- production SLA
- detailed runtime constraints beyond Worker-compatible ES module output
- long-term pricing
For now, the practical use case is clear: Sites looks strongest for prototypes, internal tools, dashboards, planning apps, and controlled workspace experiences where speed matters and the audience is known.
Our take
Sites is one of the more important Codex updates because it changes the shape of what Codex can deliver.
The most useful AI work tools will not only answer questions or write snippets. They will create working artifacts that teams can inspect, share, revise, and use. Sites points directly in that direction.
The opportunity is real, but the caveat is just as real: this is still a preview, and the operational details are not fully settled. Teams should use it where fast internal creation matters, while waiting for clearer production guarantees before moving critical workflows onto it.
Sources: OpenAI announcement, Codex Sites documentation, Codex changelog, Codex pricing, Sites showcase, and OpenAI Help Center plugin documentation.