Codex Sites are important because they show how OpenAI wants Codex to move from generating work to hosting and sharing some of that work inside a workspace.
That makes Sites less like a general-purpose website builder and more like a controlled path for internal apps, shared tools, and lightweight web experiences that teams can use together.
AI Search Snapshot
Codex Sites are a preview feature for eligible Business and Enterprise workspaces that let users create and deploy workspace-internal web apps with Sign in with ChatGPT access. They fit internal tools, shared dashboards, and lightweight workflow apps better than public marketing sites, and they should be governed through workspace settings and human review.
Direct Answer
Use Codex Sites when the goal is to create lightweight internal web apps that need to be shared inside a workspace, not when you need a broad public site or a fully independent product stack. OpenAI’s help documentation explicitly frames Sites as workspace-internal and controlled through workspace settings.
The practical best fit is shared internal work: dashboards, ops tools, lightweight utilities, reviewable prototypes, and team-only apps that benefit from quick iteration but still need admin controls and human review.
Codex Sites Table
| Focus | What it means | Best fit | Review gate |
|---|---|---|---|
| Status | Preview in eligible Business and Enterprise workspaces | Good fit for controlled workspace experiments. | Check plan and workspace settings before rollout. |
| Access model | Workspace-internal with Sign in with ChatGPT | Useful for internal apps and shared team tools. | Admins and owners should control who can create and access sites. |
| Admin controls | Sites toggle and site disable controls in workspace settings | Lets teams pilot safely before wider use. | Human review should still decide whether a site is good enough to share. |
| Bad fit | Public marketing-site assumptions | Not the right mental model for a preview internal-workflow feature. | Do not skip security, design, or data review just because it is fast. |
Evaluation Criteria
- Use Sites for workspace-internal tools, not generic public publishing.
- Confirm admin toggles and access controls before broad team use.
- Treat shared apps as a governed artifact that still needs human review.
- Choose Sites when speed and internal sharing matter more than custom public infrastructure.
What OpenAI Says Sites Are
OpenAI’s June 2, 2026 product article describes Sites as a preview of the ability to create interactive websites and apps you can share with your workspace using a URL. The Help Center article is even more explicit: Sites in Codex are available in preview for eligible Business and Enterprise workspaces and are intended for workspace-internal web apps with Sign in with ChatGPT access.
Where Sites Fit Best
The best fit is internal shared work. That includes dashboard-like tools, team utilities, ops helpers, internal prototypes, and other lightweight apps that do not justify a long engineering queue before the team can start using them. If your bottleneck is “we need a small internal tool now,” Sites are far more relevant than if your bottleneck is “we need a public product platform.”
Why Admin Controls Matter
OpenAI’s help docs say admins and owners can enable or disable the Sites toggle and can also disable existing sites. That means Sites are not just a user feature. They are a workspace-governed feature. Teams should decide who can create them, who can access them, and what kinds of data or actions are appropriate before a wider rollout.
How This Connects to the Bigger Codex Shift
Sites matter because they make the June 2 knowledge-work repositioning tangible. They turn Codex from a generation tool into a shared work surface. If you want the bigger picture first, read the Codex for knowledge work hub. If your real concern is access and connected apps, go next to the plugins guide.
Review Checklist
- Treat Sites as workspace-internal apps first, not public websites first.
- Verify workspace eligibility and preview controls.
- Decide who can create and share sites before rollout.
- Review data, access, and design implications before publishing a site internally.
- Keep human review visible before a site becomes part of team workflow.
Bottom Line
Codex Sites are most useful as a fast path to internal shared tools inside a controlled workspace.
The teams that use them well will combine speed with admin controls, limited rollout, and human review.
FAQ
Are Codex Sites public websites?
OpenAI’s Help Center frames Sites as workspace-internal web apps in preview, not as a generic public site feature.
Who can control Sites in a workspace?
Admins and owners can control the Sites toggle and can disable existing sites through workspace settings.
What is the best first use case?
A lightweight internal tool or shared dashboard is a better first use than a business-critical public site.
Do Sites remove the need for review?
No. Shared internal apps still need human review for access, accuracy, design, and workflow fit.
Verified External Sources
- OpenAI: Codex for every role, tool, and workflow
- OpenAI Help Center: Using Codex with your ChatGPT plan
- OpenAI: Introducing the Codex app
Related 3RK Guides
- Codex for Knowledge Work: What OpenAI’s June 2, 2026 Shift Means for Teams
- Codex Plugins Explained: How Role-Specific Workflows, App Access, and Admin Controls Fit Together
- Codex Annotations Explained: How to Refine AI Work Without Starting Over
- How Non-Developers Use Codex: Research, Dashboards, Briefs, and Internal Apps
- AI Governance Operating Model
- AI Announcement Decoder: How to Read Model, Agent, and Platform Launches Without Hype