What Codex Sites is, and when you want something you own

TL;DR. Codex Sites (surfaced in ChatGPT as ChatGPT Sites, and often searched as "OpenAI Sites") is OpenAI's feature for turning a prompt into a hosted website, dashboard, or lightweight web app without leaving Codex or ChatGPT. OpenAI hosts it, and as of August 2026 it is limited to paid plans and not yet offered in the EEA, UK, or Switzerland. It is a genuinely fast way to get an internal tool in front of a workspace. The trade-off is structural: the code, the runtime, and the sign-in model belong to the platform. If you want to own the code, control the domain, and be able to move later, connect Codex to Hatchable instead and let it deploy a real app you can export.

What Codex Sites is

OpenAI introduced Sites for Codex on June 2, 2026, as a preview for ChatGPT Business and Enterprise workspaces. Inside Codex you invoke it with the @Sites plugin and describe what you want. Codex writes the site, saves it, and deploys it to hosting that OpenAI runs, then hands back a URL you can share inside the workspace. OpenAI's framing at launch was that Sites are "a new kind of canvas for your ideas": dashboards, planners, review workspaces, project boards, galleries, and lightweight tools built from the plans and analysis a team already has.

Around July 9, 2026, the same capability reached individual paid subscribers as ChatGPT Sites, in public beta. OpenAI's help center describes it as a way to "create, preview, publish, and share interactive websites and lightweight apps." In Codex the plugin is still called Sites; in ChatGPT you ask for a website or use @Sites in the prompt. Public write-ups have used "Codex Sites," "ChatGPT Sites," and "OpenAI Sites" for the same thing, which is why all three show up in search.

Who can use it, as publicly described

General characterisations based on public information as of August 2026; check OpenAI's help center for current details.

• Plans. Sites is available on paid ChatGPT plans and not on Free or Go. Enterprise workspaces generally need an admin to switch it on.
• Regions. At launch it was not available in the EEA, Switzerland, or the UK, and OpenAI has not published a timeline for those regions.
• Hosting. OpenAI hosts the site. There is no deploy pipeline to set up, and every deployment URL is treated as production.
• Who can view it. The documented sharing modes run from the owner and workspace admins, to selected people or groups, to anyone in the workspace, to anyone on the internet when public publishing is enabled. The private modes rely on viewers signing in with their ChatGPT identity.
• Custom domains. You can point a domain you already own at a Site by updating DNS records, where the feature is available. It was not available in Enterprise workspaces at launch.
• Data. Sites can reportedly be given a relational database and file storage, configured from within the Sites experience.

The structural trade-off

None of the following is a bug. It is what an integrated, platform-hosted builder looks like from the outside, and it matters only if you intend the thing you built to outlive the tool you built it with.

• Owning the code. As of August 2026 we could not find a documented path in OpenAI's public help articles for exporting a Site's source, and independent write-ups from July 2026 report the same gap. Codex can show you the code, but "I can read it" and "I can take it and run it elsewhere" are different things. This may change; check the docs before you depend on either answer.
• The runtime. The site runs on OpenAI's hosting, with OpenAI's storage options and OpenAI's limits. That is convenient and it is also a dependency on one vendor's roadmap.
• Sign-in. Private Sites are gated on ChatGPT identity. That is exactly right for a workspace tool, and exactly wrong for a client portal or a customer-facing app where the people logging in are not ChatGPT users.
• Access gates. A paid plan and a supported region are prerequisites for the author. If you are on the free plan, or in the EU or UK, the feature is not there yet.
• Moving later. Custom domains help, but a domain pointing at a runtime you cannot reproduce elsewhere is a forwarding address, not portability.

When you want something you own: Codex plus Hatchable

The open alternative keeps Codex as the builder and changes where the result lives. Connect Codex to Hatchable once (it is a listed plugin in the Codex directory, or two lines of config.toml), and from then on Codex can create a project, write the files, deploy, and hand you a live URL at your-app.hatchable.site. You never provision anything, and nothing about it depends on which ChatGPT plan or country you are in.

What changes is ownership and reach:

• The code is yours. Plain HTML, JavaScript, SQL, and TOML. Export to GitHub with history, or download a zip and a SQL dump, whenever you like.
• Sign-in for your app's users, not for ChatGPT users. Every project gets email-code login and passkeys for the people who use the app, with Google sign-in available. A client, a customer, or a friend signs in to your app, not to a workspace.
• A real backend on day one. Each project gets its own private Postgres database (standard SQL and migrations), file storage, email sending and receiving, scheduled jobs, secrets, and its own MCP endpoint so other AIs can call the app. See ChatGPT Sites, but with a database and logins for the longer version of this comparison.
• Domains you control. Custom domains are part of the Builder plan, alongside email domains.
• Pricing that does not meter the building. The free plan is unlimited private projects and one published app, no card. Builder is a flat $12 a month for unlimited published apps. There are no credit packs or per-prompt fees, because your own Codex subscription writes the code. Details on the pricing page.

Sites characterisations are based on public information as of August 2026 and may lag OpenAI's changes; check each vendor for current details.

Getting started from Codex

1. Install the Hatchable plugin

   In the Codex app open Plugins, or run /plugins in the CLI, search for Hatchable, and install it. Prefer the manual route? Add this to ~/.codex/config.toml:

   [mcp_servers.hatchable]
   url = "https://hatchable.com/mcp"

   then run codex mcp login hatchable. The longer walkthrough is in how to add an MCP server to Codex.

2. Approve the sign-in

   A browser tab opens on hatchable.com. Approving creates your free account if you do not have one. No API key to paste.

3. Ask Codex to build and deploy

   Describe the app and end with "on Hatchable." Codex creates the project, writes the files, deploys, and returns the live URL. The step by step is on deploying from Codex.

Both tools can coexist. Use Sites for the internal board your team will look at this week. When the thing you are building needs its own users, its own domain, and a future outside one vendor, point Codex at something you own.