Codex Sites Is Not No-Code. It Is Deployment Power With an Approval Problem.
Codex Sites will be tempting to describe as “no-code.” Don’t. That undersells both the feature and the risk.
OpenAI’s Sites documentation says Codex can create, save, deploy, and inspect websites, web apps, dashboards, internal tools, and games hosted by OpenAI. It can turn a prompt or compatible existing project into a hosted site without a separate deployment workflow. Sites is in preview for ChatGPT Business and Enterprise workspaces, Business has it enabled by default, and Enterprise admins must enable it through role-based access control before members can use it.
The crucial sentence is not about generation. It is this: every Sites deployment URL is a production deployment. OpenAI explicitly recommends asking Codex to save a version without deploying it when review is needed. That two-stage model — save, then deploy — is the difference between a useful agent-assisted release workflow and a prompt-to-production footgun with nice typography.
The review step is the product
Sites publishing has two stages. First, Codex saves a version: it builds the deployable site and associates that version with the source Git commit used for the build. Then, if approved, Codex deploys a saved version and reports the production URL. That is exactly the shape teams should preserve. The agent prepares the artifact. The human, or a governed release process, decides whether that artifact should become reachable by users.
If teams collapse those stages into “just deploy it,” Sites becomes another path around the deployment discipline they spent years building. The generated app might be small, but the deployment is real. It can expose internal data, persist records, accept uploads, apply workspace authentication, use external identity providers, and widen access beyond the builder. That is not a toy landing page unless the team deliberately keeps it one.
The docs make the deployment mechanics concrete. A Sites project links local source to hosting through .openai/hosting.json, including a project_id and optional D1 and R2 storage binding names. Sites hosts projects that build Cloudflare Worker-compatible ES module output. Runtime environment values and secrets belong in the Sites panel, not in .openai/hosting.json. Local .env and .env.example files should stay aligned, but secret values should not be committed.
That is enough detail to treat Sites like application delivery infrastructure. Review the source diff. Review the generated build assumptions. Review storage bindings. Review migrations. Review secrets. Review access. Review the production URL before sharing it. If this sounds like normal release engineering, good. The agent should reduce setup friction, not delete release intent.
Access control is where prototypes become incidents
OpenAI documents three access modes: owner and admins only (admins_only), the full workspace (workspace_all), and custom users or groups (custom). The default operational stance should be obvious: new Sites should start owner/admin-only until reviewed. Custom access is appropriate for pilots. Workspace-wide access should require a stronger reason than “it looked useful in the demo.”
Internal tools have a long history of becoming unofficial production systems because they solved an immediate problem. A project request dashboard, ops console, approval tracker, metrics viewer, or game with saved scores can start as a prompt and become a workflow people rely on. Once that happens, the usual questions arrive: who owns it, where is the data, how is auth enforced, what happens when the schema changes, who can redeploy it, and how do we roll back? Sites does not remove those questions. It makes them arrive faster.
Storage deserves special attention. The docs distinguish content-led sites, D1 relational database needs, R2 object storage needs, workspace-authenticated internal apps, and external-auth projects. That taxonomy matters because “site” is too vague. A static landing page and a stateful app with uploads are different risk classes. Do not request durable storage for throwaway presentation state. Do request it deliberately when users expect the hosted app to remember product data. And when you do, review the data model like you would review any other application data model.
For practitioners, the rollout checklist writes itself. Before deployment, confirm the build succeeds. Inspect source changes and database migrations in the review pane. Confirm the saved version is the intended version. Confirm only the intended audience can access the site. Confirm runtime secrets are configured through Sites and not committed to source. After deployment, ask Codex to verify status and the production URL before anybody posts the link in Slack.
Plugins make this more than hosting
Sites also sits next to Codex plugins, and that is where the broader platform story appears. OpenAI’s plugin docs describe plugins as a way to package skills, app integrations, MCP server configuration, and lifecycle hooks. Local plugins can be shared with workspace members without being publicly published. Plugin-bundled hooks are non-managed hooks and are skipped until the user reviews and trusts the current hook definition.
That is the right friction. Plugins are not just feature packs. They can shape what the agent knows, what tools it sees, what commands run around a session, and which internal systems become available. Combine that with Sites and the workflow starts to look like this: a plugin gives Codex a standardized internal capability, Sites gives it a deployment target, and a user gives it a prompt. Useful, yes. Also a platform surface that needs governance.
The comparison to conventional no-code tools is instructive but incomplete. No-code platforms usually centralize the builder environment, data connections, deployment model, and access controls inside one product. Codex Sites is different because it is attached to an agent that can inspect and modify source, talk to plugins, reason through requirements, and operate across a developer workflow. That makes it more flexible. It also means the organization has to think about code review, plugin trust, MCP access, secrets, and hosting as one connected system.
Admins should not wait for the first popular internal Sites app before writing policy. For Enterprise, decide which roles can use Sites before enabling it. For Business, where Sites is enabled by default, decide whether training and review expectations need to land immediately. Require saved-version review for anything beyond a personal prototype. Default access to owner/admins. Ban committed secrets. Require owners for apps with durable data. Treat .openai/hosting.json changes as meaningful infrastructure changes, not generated clutter.
Sites is powerful precisely because it closes the loop from idea to production URL. That is the dream version and the dangerous version. The right editorial read is not “OpenAI made no-code.” It is “OpenAI gave Codex a hosted delivery surface.” If teams keep the save/deploy boundary, access controls, storage review, and secret hygiene intact, this can make internal tool building dramatically faster. If they treat the prompt as approval, the incident report will be short and obvious.
Sources: OpenAI Developers — Sites in Codex, OpenAI Developers — Build plugins in Codex, OpenAI Developers — Plugins in Codex, OpenAI — Codex for every role, tool, and workflow, OpenAI Developers — Codex pricing / feature availability