ChatGPT Sites launches public beta for prompt-built apps

• ChatGPT Sites entered public beta for turning prompts, files, or rough ideas into dashboards, trackers, reports, prototypes, and lightweight apps, according to jxnlco's beta note.
• Publishing is part of the workflow: jxnlco's beta note describes private preview plus published URLs, and OpenAIDevs' launch link points to the broader ChatGPT Work rollout.
• Auth is already first-class: jxnlco's auth reply says Sites has built-in auth, while jxnlco's demo note says the demo supported login, comments, and a custom subdomain.
• The first confusing edge case was deployment visibility: benhylak's follow-up saw deployed changes not appear and a “public” site gated behind ChatGPT login, while pvncher's reply pointed at org settings.
• The broader Work/Codex interface still leaks product structure, according to koltregaskes's interface audit, which found Sites grayed out on web but creatable on desktop.

The Sites docs have the deployment mechanics OpenAI did not fit in the launch copy: saved versions, production deployment URLs, .openai/hosting.json, D1/R2 storage, workspace identity, and external auth. The OpenAI Academy guide also buries a sharp caveat: Sites cannot connect directly to live data today, even though OpenAI's Work post says ChatGPT can update Sites as underlying information changes.

Sites moved from a Codex-centered preview into ChatGPT's Work/Codex product surface. OpenAI's ChatGPT Work launch post frames Work as an agent that can create sheets, slides, docs, and web apps from connected apps and workflows.

The public beta surface, as described by jxnlco:

• Inputs: prompt, file, or rough idea.
• Outputs: dashboard, project tracker, report, prototype, or lightweight app.
• Build surfaces: ChatGPT Work or Codex.
• Review path: private preview inside ChatGPT.
• Publish path: shareable URL.
• Rollout: paid plans.
• Admin control: Enterprise admins can control public publishing.

OpenAI's June Codex post shows the lineage: Sites started as a preview for Business and Enterprise customers to create interactive hosted websites and apps shareable inside a workspace.

The Sites docs define a Site as a persistent hosted output that ChatGPT can reopen, refine, configure, and share. For local projects, Sites stores hosting linkage in .openai/hosting.json and can bind storage resources there.

The deployment model is more explicit than the launch copy:

• Save a version: ChatGPT builds a deployable candidate and associates it with a Git commit for local source projects.
• Deploy a version: ChatGPT publishes the saved version and returns the production URL.
• Every deployment URL is production, according to the docs.
• Reviewable candidates require saving a version without deploying it.

The supported shapes are practical internal-tool primitives:

• Static or content-led site, no durable state by default.
• Saved records, user progress, or scores using D1.
• Uploaded files using R2.
• Searchable uploads using D1 metadata plus R2 file contents.
• Workspace-authenticated identity for internal sites.
• Authentication-enabled Sites for public sign-in or external identity providers.

Jxnlco's replies filled in the auth story before the docs did: “Login with ChatGPT” handles access, and built-in auth is part of Sites. The public Book of Disquiet demo also supported login, comments, and a custom subdomain, according to jxnlco's demo note.

The Sites docs list three sharing scopes, depending on account and workspace settings:

• Only you or invited people.
• Everyone in your workspace.
• Anyone with the link.

Sharing lets people visit a Site, not edit it. Workspace admins can restrict public sharing, which matches the org-setting explanation pvncher offered for a site that appeared public but still sat behind a ChatGPT account.

OpenAI's Work launch says Sites can create live dashboards and update them as underlying information changes. The Academy guide narrows that claim: Sites cannot connect directly to live data sources today.

The current pattern is a two-part system, per OpenAI's own docs: use a separate automation to gather updates on a schedule, then review and refresh the Site. That makes “live dashboard” more like scheduled regeneration plus deployment than a direct data binding.

Benhylak's first run hit the failure mode every hosted-agent product dreads: the UI said deployed, the visible site did not reflect changes, and public access still required a ChatGPT account.

Benhylak's follow-up listed three concrete symptoms:

• Files appeared on the site once, then later changes did not show up.
• ChatGPT kept saying the site was deployed.
• The site looked public but remained behind the user's ChatGPT account.

Koltregaskes's longer audit put Sites inside a wider ChatGPT Work/Codex navigation mess:

• Chat, Work, and Codex are presented as product modes, but their roles differ across web and desktop.
• The web says “Branch into new chat,” while desktop says “Continue in new task.”
• Desktop exposes Work and Codex menus, while some web capabilities differ.
• Model selection exposes internal names and different effort controls across Chat, Work, and Codex.
• Sites was grayed out in Work Mode on web for that user, while “create a site” worked on desktop.

reach_vb's reply said the team appreciated the community feedback and was already working on fixes.

Emollick compared ChatGPT Work with Google's NotebookLM on the same 70-plus files. ChatGPT Work produced an 11-slide PowerPoint after 6m 42s, while NotebookLM exposed sources, citations, and a Studio panel with tools such as Slide Deck, Mind Map, Reports, Flashcards, and Infographic.

Emollick's clarification put the distinction cleanly: NotebookLM is built for research and source analysis, and its interface centers process and sources rather than only outputs. For Sites, that is the unresolved UX question: a hosted artifact is useful, but knowledge work often needs to show how the artifact was made.