OpenAI Adds Workspace App Publishing to Codex

Corey Ching describes Sites in Codex as a way for teams to turn an idea into a secure application and publish it “in minutes,” directly from Codex. The demonstration begins with a simple app-building prompt — “Build me a forecasting dashboard for next week’s Q” — and shows Codex producing a dashboard-style application rather than a static document.

The example interface is titled “QBR Forecast Command Center” and is framed as a forecast dashboard for the week of June 8, 2026. It includes operational business metrics such as “Gap to plan $730K,” “Pipeline coverage 1.18x,” and “Close-week exposure $6.5M,” alongside a bar chart showing forecast movement. The point is not merely that Codex can generate a chart; Ching positions Sites as a way to package team context, analysis, and workflow-specific information into an application that others can open and use.

OpenAI’s own use cases, according to Ching, include internal tools, mini apps, and shareable resources that “might otherwise live as docs or slides.” Sites is presented as the layer that gives those generated apps the infrastructure expected of internal software: hosting, authentication, storage, and database support are included “out of the box.” Ching also says Codex plugins and skills let him bring in context and analysis from tools his team already uses, then ask Codex to build and publish the application.

The workflow being described is conversational and iterative. After a site is published, the team can keep refining it “through conversation,” without setting up infrastructure or writing deployment code. That distinction matters: Sites is framed less as a code-generation demo and more as a product surface for turning trusted internal material into a managed application asset.

Ching’s first detailed example is “Account Lens,” an internal dashboard for an executive business review. The displayed app is titled “Aster Peak Account Lens” and includes the customer name “OAI Blossom Energy Solutions,” the phrase “Executive business review,” and a topic line: “Secure rollout of remote asset telemetry assistants.”

Before a customer meeting, Ching says, an account team could open a site containing customer context, approved talking points, and a clear chart of financial metrics. He describes it as “the kind of focused internal app a team can build from trusted material to prepare them for their meetings.” The emphasis is on preparation from vetted material: not a blank chatbot session, and not an editable deck passed around by email, but a narrow application assembled around the information a meeting team needs.

A second example applies the same pattern to event preparation. The shown site, “Aster Peak | Forum Ready,” is organized around the “Global Energy Transition Forum 2027,” dated October 12–13. The visible message on the page is “Remote assets: reliability without more field load.” Ching says a team preparing for an external energy summit could organize the agenda, attendees, approved messages, conversation starters, and a “before-you-go plan” in one place.

The phrasing here is deliberate: everyone attending the event can “work from the same useful document.” Sites is still being described partly in document terms, but with application structure around the document: shared access, organized sections, team-specific context, and the ability to keep improving the artifact after it is created.

The third example, “Compass Memo,” moves from meeting and event preparation into internal decision-making. The displayed memo app is titled “Aster Peak Compass Memo” and presents a proposed investment: “Extend priority customer support to 24/7 coverage.” It highlights a concrete expected impact: “Overnight coverage could cut urgent-case response time by 64 minutes.”

Ching describes the site as an executive memo that brings together the proposal, budget, guardrails, risk, reviewers, and evidence in a central place. The intended use is to help a team move work forward by giving leaders visibility into what still needs resolution “without missing any detail.”

This example is the clearest statement of the product’s internal operating model. Sites is not presented as only a lightweight app builder for dashboards; it is also positioned as a structured container for decisions. A team can assemble the facts, constraints, reviewers, risks, and supporting evidence around a proposed investment, then give leaders a single place to review the open issues.

Ching then broadens the category. Teams could build a forecasting dashboard, an onboarding hub, a product council brief, or an interactive data story. The examples differ in domain, but they share the same pattern: trusted material is converted into a purpose-built app that a team can share, revisit, and refine.

Sites are described as “workspace assets,” which means their publication and access model is part of the core workflow. In the site management interface shown in the demonstration, the page lists “Sites,” shows an item named “Account Lens | Aster Peak Technologies,” and opens a sharing modal for that site. The access panel includes “Who has access,” with Corey Ching listed as “Owner.”

Ching says he can share a site with specific users or with his whole workspace. Viewers sign in with their ChatGPT account to open it. That is the practical endpoint of the product claim: Codex can take team context and produce an application, but Sites is meant to make that application usable inside an organization through managed sharing and authenticated access.

The closing formulation is Ching’s summary of the intended motion: “From trusted context to an application your team can actually use, that’s Sites.” In the demonstration, “use” means more than generating a page. It means hosting the app, controlling access, storing data, connecting to team context through Codex plugins and skills, and continuing to refine the app conversationally after publication.