Sites in Codex, from workspace-only beta to public ChatGPT Sites.

What Sites in Codex is

Sites in Codex is a plugin for OpenAI's Codex coding agent. You invoke it with @Sites, and Codex can then create, save, deploy, and inspect a site or app on your behalf. The range is broad: OpenAI's docs list websites, web apps, dashboards, internal tools, and games as supported targets. The build happens inside the Codex session, so the same agent that writes the code also ships it. Since 9 July 2026 the same feature ships inside ChatGPT as ChatGPT Sites for paid subscribers; this post keeps the full history and the current documented state.

This is more than static page hosting. A Sites deployment can carry server-side logic and durable data, not just markup. OpenAI documents two storage backends behind it: D1, described as a relational database for durable structured data, and R2, described as object storage for files. Hosted environment variables and secrets are managed from the app sidebar. So a Sites app can read and write a real database, store uploads, and keep configuration out of the code. That puts it in the category of full application hosting rather than file hosting.

One detail worth stating clearly because it is easy to assume otherwise: persistence is supported, and every Sites deployment URL is a production deployment. There is no separate "publish" step that turns a draft into something real. The URL Codex gives you is the live one.

How hosting and access work

Sites is hosted by OpenAI, running on Cloudflare. You do not manage the infrastructure, choose a region, or bring your own account; OpenAI operates it and hands back a deployment URL. For teams who want an agent to ship something without anyone touching a deploy pipeline, that is the appeal.

Access control is where the story moved most. In the original beta, access was workspace-scoped only, with three documented modes: admins_only (the site owner and workspace administrators), workspace_all (all active users in the workspace), and custom (specific active users or groups). All three required the viewer to be an active member of your OpenAI workspace; there was no public mode. The GA docs now list four sharing options:

• Owner and workspace admins, the tightest mode.
• Selected active users or groups, where supported.
• Anyone in the workspace, where supported.
• Anyone on the internet, "only when public publishing is enabled". In Enterprise workspaces public publishing is off by default and must be enabled by an admin.

The boundary that remains: every non-public mode requires a signed-in, invited viewer. There is no password gate, no email gate, and no link-only private mode, so a site is either open to the whole internet or restricted to accounts inside the workspace. The middle ground, a gated page a client can open without an account, is not in the documented model.

On availability, Sites moved from a Business and Enterprise preview to paid ChatGPT plans generally (every paid plan except Free and Go) at the July GA. The docs still label it a public beta and hedge that availability "can depend on your plan, region, and workspace settings"; per OpenAI's help center, Sites is not available in the EEA, Switzerland, or the UK at launch. We keep a running answer in the availability and public-link post.

What it is great at

Taken on its own terms, Sites in Codex is strong at a specific job: standing up internal team tools quickly, from inside the agent that wrote them.

The strengths are real:

• Full apps, not just pages. With a relational database, object storage, and server-side logic, you can build something that holds and updates state, not only something that renders. An internal dashboard that reads live data, a tool that records submissions, a board people edit, these fit.
• Built and shipped in one place. Because the build and the deploy both live in the Codex session, there is no handoff to a separate hosting step. You describe what you want, Codex builds it, and the deployment URL comes back.
• Production deployments by default. Every URL is a production URL, so there is no ambiguity about whether what you are looking at is the real thing.
• Managed secrets. Environment variables and secrets in the app sidebar mean credentials do not have to be inlined into code that the agent generated.
• Workspace-scoped access that matches the use case. For internal tools, "only people in our workspace can see this" is exactly the right default, and the selected-users mode lets you narrow it to a team.
• Built-in analytics. The GA docs document total unique visitors and page views, plus both over time, though not currently for sites owned by an Enterprise workspace.

OpenAI's own showcase reflects this framing. The published examples are all internal team tools: an onboarding hub, an enablement library, an executive KPI dashboard, an employee idea board, a launch calendar, and an event-ops hub. That is a coherent product story. Sites in Codex is for apps your team uses, built by your agent, kept inside your company.

The open questions, revisited: sharing, domains, export

When this post first ran, the three most-asked questions all had the same answer: not documented. The GA release resolved two of them. Here is where each stands now.

Can you share a Site with someone outside your workspace? Answered: yes, by making it public. Since 9 July 2026, public publishing puts a site on the open internet for anyone, no login (we verified the launch example serves with no account). What the docs still do not cover is the case in between: a page for a contractor, a client, or a candidate that should not be public to the whole internet but where the viewer has no account. The private modes all require a signed-in, invited viewer, and there is no password gate, email gate, or expiry.

Can you put it on your own domain? Answered: yes, where available. The GA docs describe connecting an apex domain or subdomain you already own by updating DNS records. Two caveats from the docs themselves: it is offered "where available", and custom domains are not available in Enterprise workspaces at launch.

Can you export the code or self-host it? Still not documented. Community reports at the GA launch described receiving a Wrangler project of a site for self-hosting on your own Cloudflare account, which would be a genuine portability story, but the docs do not describe an export path. Until they do, treat it as unconfirmed.

The pattern in what remains is consistent: everything still undocumented sits on the client-deliverable edge. Public or workspace-internal is covered; gated-but-account-free, expiring, and portable is not. If that is your situation, it is worth knowing the docs do not cover it yet.

Where this leaves open-ecosystem tools like Stacktree

Full disclosure: we build Stacktree, so treat this section as us describing where we sit, not as neutral advice. Stacktree solves a deliberately narrower and more open problem than Sites in Codex, and the two address different needs.

Stacktree is a publish primitive for agent-made HTML, exposed over MCP, so it works across Claude Code, Cursor, Codex, and Claude.ai rather than inside one agent. Its model fills exactly the middle ground the Sites docs leave open: a site is private by default, and the unguessable URL is the credential, so a viewer needs no account and does not have to belong to any workspace. On a paid plan you can layer on a password or an email-domain gate with magic-link verification, and on any plan an expiry or end-to-end encryption; that covers the case of sharing an HTML file with a client without making it public and without a login. Custom domains are available from Solo, you can replace a site in place with update_site, and it is source-available and self-hostable on your own Cloudflare account. The trade is scope: Stacktree hosts static HTML only, with no server logic or application database. So if you need a full internal app with persistence, or a public site, Sites is built for that; if you need to send an agent-made page to someone outside your company without publishing it to the whole internet, or publish it from any agent over an API, an open primitive is the closer fit. They are not substitutes.

What to watch

This is a living post; the watch-list from June is now half resolved. Here is the scorecard as of 18 July 2026:

1. An external or public sharing mode. Resolved, 9 July 2026. Public publishing shipped with the ChatGPT Sites GA; admins control it in Enterprise workspaces. Still open inside it: any gated mode a viewer can pass without an account.
2. Custom domain support. Resolved in the GA docs. Apex or subdomain via DNS records, where available; not in Enterprise workspaces at launch.
3. Export or portability. Still open. Community-reported Wrangler export at launch, nothing in the docs.
4. Wider plan availability. Resolved on plans, open on regions. All paid plans except Free and Go have it; the EEA, Switzerland, and the UK were excluded at launch with no timeline.
5. Use beyond ChatGPT and Codex. Still open. Sites is created in conversation, with no documented API, CLI, or MCP surface for publishing from other agents.

As the remaining items land, the answers above will be updated. For now, this is the documented state of the feature.