Sites in Codex, and the open question of sharing outside your workspace.

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.

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 is controlled at the workspace level. OpenAI documents three modes:

• admins_only, visible to the site owner and workspace administrators.
• workspace_all, visible to all active users in the workspace.
• custom, visible to specific active users or groups you name.

All three share one boundary: the viewer has to be an active member of your OpenAI workspace. There is no public mode, no link-only mode, and no external-viewer mode in the documented model. This is a deliberate design for internal tools, and it is consistent with how the feature is positioned.

On availability, Sites in Codex is in preview, limited to ChatGPT Business and Enterprise workspaces, with OpenAI describing more plans as rolling out later. On Enterprise, access is governed through RBAC. It is not available to individual or free accounts today. On June 4, 2026 the Codex team posted on X that Sites is live for team plans and that non-team plans are being worked on; the docs had not changed as of June 6. 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 custom mode lets you narrow it to a team.

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: sharing, domains, export

The questions people ask most about Sites in Codex are about what happens at the edges of that internal model. Here is what the docs say, and where they are silent.

Can you share a Site with someone outside your workspace? Not as documented. Every access mode requires the viewer to be an active member of your OpenAI workspace. There is no public or link-only option. If you need a contractor, a client, a candidate, or anyone without a seat in your workspace to view the thing, the documented access controls do not cover that case, and you would have to reach for a different channel.

Can you put it on your own domain? Custom domains are not documented. The deployment URL is OpenAI-hosted. OpenAI may add this later, and it is reasonable to expect demand for it, but as of June 2026 the docs do not describe a way to attach your own domain. The honest reading is "not documented," not a flat no.

Can you export the code or self-host it? Export, code download, and self-hosting are not documented. Sites is described as hosted by OpenAI, and the docs do not lay out a path to move a deployment elsewhere or run it on your own infrastructure. Again, this could change; right now there is no documented exit.

None of these are criticisms of the feature for its stated purpose. Internal tools generally do not need a public URL, a vanity domain, or portability. They become real considerations only when the artifact needs to outlive the workspace, reach someone outside it, or move. 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 is the inverse of workspace-scoping on the sharing axis: 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. You can layer on a password, an email-domain gate with magic-link verification, or end-to-end encryption. Custom domains are available on the Pro plan, 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 inside Codex, Sites in Codex is built for that; if you need to send an agent-made page to someone outside your company, or put it on your own domain, or keep the ability to take it with you, an open primitive is the closer fit. They are not substitutes.

What to watch

This reflects OpenAI's documentation as of June 2026, and a preview-stage feature is exactly the kind that changes. A few things would be worth rechecking:

1. An external or public sharing mode. If OpenAI adds a way to expose a Site to viewers outside the workspace, the most-asked question here is answered, and the internal-only framing shifts.
2. Custom domain support. Watch for this on the deployment side; it is a common next step for hosted-app products and would change how durable a Sites URL feels.
3. Export or portability. A documented way to download the code or move a deployment would address the lock-in question directly.
4. Wider plan availability. OpenAI says more plans are rolling out later, and on June 4, 2026 the Codex team posted that non-team plans are being worked on, so individual and smaller-team access may open up soon.
5. Use beyond Codex. Today it is the @Sites plugin inside Codex, with no documented use from other agents. If that broadens, the picture changes again.

If any of these land, the answers above will need updating. For now, this is the documented state of the feature.