OpenAI Sites: A Detailed Guide to Codex’s New Hosted Website and App Builder

OpenAI has just introduced Sites, a new Codex capability for creating, saving, deploying, and inspecting hosted websites, web apps, dashboards, internal tools, and lightweight interactive experiences. The most important thing to understand up front is that the official launch language frames Sites as part of Codex, not as a standalone consumer website builder.

OpenAI’s launch post describes it as “a preview of the ability to create interactive websites and apps you can share with your workspace using a URL,” and the developer docs describe Sites as a Codex plugin for building and deploying hosted sites from Codex.

That distinction matters. Sites is not simply “ask ChatGPT for HTML.” It is closer to a work-product publishing surface inside Codex: you can ask Codex to turn a business review, launch plan, product dashboard, financial model, creative brief, project tracker, or lightweight app idea into something your team can open, use, and iterate on through a URL.

Official links:

• OpenAI launch post: Codex for every role, tool, and workflow
• OpenAI developer docs: Sites – Codex
• OpenAI terms: ChatGPT Sites Terms
• OpenAI broader context post: Codex is becoming a productivity tool for everyone

Useful background reading:

• Kingy AI: The Complete Guide to OpenAI Codex
• Kingy AI: OpenAI Codex Command Guide
• Kingy AI: Codex vs. Claude Code vs. Cursor: The Definitive 2026 Guide
• Kingy AI: Best AI Coding Tools for Non-Developers in 2026
• Medium background on adjacent Codex web capabilities: OpenAI Codex’s browser use feature

What OpenAI Sites Is

Sites is a Codex-powered way to create and host interactive web experiences through OpenAI-managed hosting. According to OpenAI’s developer documentation, Sites lets Codex “create, save, deploy, and inspect websites, web apps, and games hosted by OpenAI.” You use the Sites plugin when you want Codex to turn either a prompt or a compatible existing project into a hosted site without setting up a separate deployment workflow.

In plain English: you describe what you want, Codex builds or adapts the site, validates the build, saves a deployable version, and can deploy it to a production URL.

OpenAI’s launch examples are practical and work-oriented. The company mentions dashboards, planners, review workspaces, project boards, galleries, and lightweight tools. The launch post also gives concrete examples such as customer review pages, scenario planners built from financial models, and launch hubs where teams can track messaging, milestones, owners, and decisions.

Who Can Use It at Launch

As of June 2, 2026, Sites is in preview. OpenAI’s developer docs say it is currently available for ChatGPT Business and Enterprise workspaces, with more plans rolling out later.

There is one important admin difference:

• ChatGPT Business: OpenAI says Sites is enabled by default.
• ChatGPT Enterprise: an admin must enable Sites through role-based access control before members can use it.

This means many individual ChatGPT users should not assume they have access yet. If you do not see Sites in Codex, that does not necessarily mean anything is broken. It may simply not be available for your plan or workspace yet, or your Enterprise admin may not have enabled it.

Why Sites Matters

The biggest shift is that Codex is moving from “agent that edits code” toward “agent that produces usable work surfaces.” OpenAI says more than 5 million people now use Codex weekly, and that non-developers such as analysts, marketers, operators, designers, researchers, investors, and bankers make up about 20 percent of overall Codex users.

Sites fits that broader strategy. Instead of forcing every output into a document, spreadsheet, slide deck, or static report, Codex can package work as an interactive product-like surface.

That is useful when the output needs exploration rather than passive reading. A dashboard lets people filter and compare. A scenario planner lets leaders adjust assumptions. A project board lets a team update status. A customer review workspace can gather usage trends, open questions, next steps, and owners in one place.

How Sites Works

The official docs describe a two-stage publishing model:

1. Save a version.
   Codex builds the deployable site and associates that version with the source Git commit used for the build. This is the review stage.
2. Deploy a version.
   Codex publishes a saved version and gives you the production URL after deployment succeeds.

This separation is important because OpenAI says every Sites deployment URL is a production deployment. If you want to review before going live, ask Codex to save a version without deploying it.

A strong first prompt should include:

• The audience for the site
• The core experience or workflow
• The data the site should use
• Whether users need to sign in
• Whether data should persist between visits
• Whether the site should be owner-only, workspace-wide, or limited to specific users or groups

Example prompt:

@Sites Build a customer review workspace for the account team. Include sections for product usage trends, open risks, requested features, renewal timeline, next steps, and owner assignments. Keep access limited to me and workspace admins until I review it. Save a deployable version, but do not deploy until I approve it.

What You Can Build With Sites

Based on OpenAI’s launch post and developer docs, Sites is best suited for lightweight but useful web experiences:

• Internal dashboards
• Project request trackers
• Customer review workspaces
• Launch hubs
• Financial scenario planners
• Event operations dashboards
• Product update galleries
• Creative brief repositories
• Lightweight games or interactive demos
• Internal tools that use workspace identity
• Apps that store records, progress, scores, or uploaded files

This is not the same as saying Sites replaces every production engineering workflow. OpenAI’s documentation specifically says existing projects need compatible deployment artifacts, and that Sites hosts projects that build Cloudflare Worker-compatible output as ES modules. For existing projects, ask Codex to check compatibility before deploying.

Supported Site Shapes

OpenAI’s Sites docs describe several patterns:

• A content-led website or landing page can be built without persistent application state unless the experience needs it.
• Saved records, user progress, or game scores can use D1, a relational database for durable structured data.
• Images, documents, audio, video, or other uploads can use R2 object storage.
• Uploaded files with searchable metadata can use D1 for metadata and R2 for file contents.
• Internal sites can use workspace-authenticated user identity.
• Public sign-in or external identity provider flows require an authentication-enabled Sites project.

The practical rule is simple: do not ask for durable storage unless the hosted site needs to remember real product data. A temporary theme preference or dismissed banner does not need durable storage. A request tracker, customer workspace, project status board, or game leaderboard probably does.

Access Control

Sites is designed for team sharing, so access control is central. OpenAI’s docs say you should set the audience before sharing a deployed URL and keep a new site limited to the owner and workspace admins until you have reviewed the content, data handling, and expected audience.

The documented access modes are:

• admins_only: the site owner and workspace admins
• workspace_all: all active users in the workspace
• custom: specific active users or workspace groups, while still allowing the owner

A safe deployment prompt:

@Sites Show me the current access setting, deployment URL, and saved version. If the build matches the version I approved, change access to the Revenue Operations group only.

Secrets and Environment Variables

OpenAI’s docs are explicit that hosted environment variables and secrets should be managed through the Sites panel in the Codex app. Do not store secrets in .openai/hosting.json. Keep local .env and .env.example files aligned for development, but do not commit secret values.

If you change hosted environment values, ask Codex to redeploy the approved saved version so the new configuration is used.

Legal and Policy Responsibilities

The new ChatGPT Sites Terms are worth reading before publishing anything meaningful.

Key points from the terms:

• You retain ownership rights in your website content, to the extent permitted by law.
• By creating or publishing ChatGPT Sites, you grant OpenAI and its third-party hosting providers a license to host and make the website content available.
• OpenAI may display attribution text or links, such as “powered by ChatGPT.”
• You are responsible for your ChatGPT Sites, including content, functionality, legal compliance, end users, and user-submitted content.
• Your site must not violate OpenAI usage policies, pose security threats, include malware, target children under 13 or the applicable digital consent age, or facilitate money transfers, cryptocurrency transfers, or financial or investment transactions.
• If your site collects or processes personal data, you are responsible for privacy compliance, notices, consent, and data-subject requests.
• Sites must not process protected health information under HIPAA or payment card data regulated under PCI DSS.
• OpenAI reserves the right to remove, unpublish, delete, or disable ChatGPT Sites.
• The terms identify ChatGPT Sites as a beta service.

That last point is not a throwaway. For business use, treat Sites as a preview/beta capability and review governance, retention, user access, and compliance requirements before relying on it for sensitive workflows.

How to Get Started

1. Confirm your plan and workspace access.
   You need a ChatGPT Business or Enterprise workspace at launch. Enterprise admins must enable Sites through RBAC.
2. Open the Codex app.
   Sites is accessed through Codex, not through a generic website-builder dashboard.
3. Add the Sites plugin if needed.
   OpenAI’s docs say to open Plugins in the Codex app, find Sites, and add it. Start a new thread after installing a plugin.
4. Start with a low-risk internal use case.
   Good first projects include a team dashboard, project tracker, meeting hub, customer review workspace, or internal launch checklist.
5. Ask Codex to save before deploying.
   Because deployment URLs are production deployments, ask for a saved version first.
6. Review the source changes, migrations, build status, access settings, and data handling.
   OpenAI’s docs specifically recommend reviewing source changes and any database migrations in the Codex review pane before deploying or widening access.
7. Deploy only after approval.
   After deployment, ask Codex to confirm the deployment status and production URL before sharing.

Example Prompts

Internal Project Dashboard

@Sites Build an internal project dashboard for the operations team. It should show active projects, owners, priority, blockers, due dates, and status. Let team members update status and blockers. Require workspace sign-in and save updates between visits. Keep access limited to me and workspace admins. Save a version for review; do not deploy yet.

Launch Hub

@Sites Turn these launch notes into a living launch hub. Include messaging, milestones, owners, unresolved decisions, dependencies, and a launch readiness checklist. Use a clean internal-dashboard style. Save a review version first.

Financial Scenario Planner

@Sites Create a scenario planner from this financial model. Let leaders compare assumptions for pricing, conversion rate, hiring plan, and operating costs. Show the effect on revenue and margin. Do not deploy until I approve the saved version.

Existing Project Deployment

@Sites Check whether this project can produce Sites-compatible deployment artifacts. If it can, prepare a deployable version and summarize any changes needed. If it cannot, explain the blockers before editing anything.

Best Practices

Start internal. Sites is most compelling for workspaces and team artifacts, especially while the feature is in preview.

Keep permissions narrow at first. Use owner/admin access while building and reviewing, then widen to a specific group or workspace only after approval.

Separate review from deployment. Ask Codex to save a version before deployment, especially for sites with data handling, auth, or customer-facing content.

Be explicit about persistence. Tell Codex whether the site needs saved records, uploads, user progress, searchable metadata, or only temporary UI state.

Review legal constraints. Avoid use cases involving payment card data, protected health information, children under 13, financial transactions, or anything that would violate OpenAI’s usage policies.

Treat generated sites as real software. Review source changes, database migrations, secrets, access controls, and production URLs.

Where Sites Fits in the AI Website Builder Landscape

Sites overlaps with website builders, no-code tools, prototyping tools, and AI coding agents, but its starting point is different. It is built into Codex, so the workflow is less “choose a template and edit a page” and more “delegate a work-product or lightweight app to an agent, then inspect, revise, save, and deploy it.”

OpenAI also says it is working with early partners including Vercel, Wix, Base44, Replit, Lovable, Figma, Webflow, and Emergent as it builds toward a Sites partner ecosystem. That suggests Sites may eventually connect more directly with the broader app-builder and design-tool market, but as of this launch, the safest claim is simply that OpenAI has announced early partners and a preview feature for Business and Enterprise teams.

What Not to Assume Yet

To avoid overclaiming:

• Do not assume Sites is available to all ChatGPT Free, Plus, Go, or Pro users today.
• Do not assume every existing web app can deploy unchanged.
• Do not assume Sites replaces production engineering review.
• Do not assume OpenAI endorses or reviews your site content.
• Do not assume a deployed URL is a private draft.
• Do not use Sites for prohibited data or restricted transaction flows.
• Do not treat partner ecosystem plans as shipped integrations unless OpenAI documents the specific integration.

Bottom Line

OpenAI Sites is one of the clearest signs that Codex is expanding from coding assistance into a broader knowledge-work production platform. The launch is especially interesting because it turns AI output into shared, interactive software rather than another document to read.

For teams, the immediate opportunity is practical: dashboards, project hubs, customer review pages, scenario planners, and lightweight internal tools that can be created and updated through Codex. The immediate caution is just as practical: Sites is in preview, tied to Business and Enterprise workspaces at launch, governed by new ChatGPT Sites Terms, and every deployment URL should be treated as production.

Used carefully, Sites could become a fast way to turn business context into working internal software. Used casually, it could create governance, privacy, or access-control problems. The right first move is not to publish something flashy. It is to build a small internal tool, save a review version, inspect it, lock down access, and then deploy only when the team knows exactly what is going live.

Sources

• OpenAI: Codex for every role, tool, and workflow
• OpenAI Developers: Sites – Codex
• OpenAI: ChatGPT Sites Terms
• OpenAI: Codex is becoming a productivity tool for everyone
• Medium: OpenAI Codex’s browser use feature
• Kingy AI: The Complete Guide to OpenAI Codex
• Kingy AI: OpenAI Codex Command Guide
• Kingy AI: Codex vs. Claude Code vs. Cursor: The Definitive 2026 Guide
• Kingy AI: Best AI Coding Tools for Non-Developers in 2026