Sharing OpenAI Codex Output Externally: What Codex Sites Does (and Doesn't)

OpenAI Codex Sites is one of the clearest signals yet that agent output is becoming hosted, interactive work rather than static files or chat transcripts. If you live in the Codex app, it's a genuinely good way to turn an analysis into a scenario planner, a launch into a living hub, or a plan into a dashboard your team can actually use.

But the moment that work needs to leave your OpenAI workspace — a client, a partner, a board, a candidate, a contractor — or needs to be maintained by a different agent next quarter, you run into the boundary of what Sites is for. This guide is honest about both: where Codex Sites is the right tool, and what to do when you need to share Codex output externally.

What Codex Sites actually is

Codex Sites is a Codex-native surface for creating interactive websites and apps and sharing them with your workspace by URL. The shape, per OpenAI's own documentation:

• Created inside the Codex app, with annotation-driven refinement — select an element or a claim and ask Codex to revise that specific part. This in-place loop is genuinely strong.
• Hosted by OpenAI as Worker-compatible app artifacts. (A single HTML page is wrapped in a small Worker as the hosting adapter — Sites deploys apps, not raw files.)
• Previewed for ChatGPT Business and Enterprise, with admin enablement in workspace settings.
• Shared "with your workspace using a URL" — workspace access modes gate who inside the org can open it.

For work that's born in Codex and consumed by colleagues already in the same workspace, that's a low-friction, high-quality loop. There's no reason to leave it.

Where Codex Sites stops

The constraints aren't about quality — they're about scope. As of mid-2026, OpenAI has not publicly documented any of the following for Sites:

• External or guest sharing. Sharing is described as workspace-scoped. There's no documented public link, named-guest access, or cross-org sharing for an audience that isn't in your OpenAI workspace.
• Custom domains or publisher-owned URL namespaces.
• Versioning, rollback, or source export — no documented way to pin a version, roll back, or take the source out and maintain it elsewhere.
• Publishing from anywhere but the Codex app. No documented Sites creation/deploy path from Codex CLI, ChatGPT web or mobile, the API, MCP, or any non-Codex agent (Claude Code, Cursor, CI jobs, local models).
• Signed-in pages in the in-app browser. OpenAI's own Codex in-app browser docs note that signed-in pages, cookies, and auth flows aren't supported — so a gated external page isn't something Codex opens natively anyway.

None of this means Sites is weak. It means Sites is an app-native, workspace-native feature. The gap is everything outside that box: other agents, other models, external audiences, and durability over time. (It's the same shape of problem as Claude's publish button for internal sharing — a great in-product loop that stops at the vendor's own walls.)

How to share Codex output externally and across agents

The fix isn't to fight Codex on its home turf — it's to give the artifact a home that isn't tied to one workspace. Publish it to display.dev, and the same file becomes a durable, shareable URL:

dsp publish ./codex-output.html

What that changes:

• Reach beyond your workspace. Set visibility to company (anyone with a verified company Google or Microsoft email), private, or specific named emails — or public. External viewers authenticate with credentials they already have; there are no accounts to create.
• Any agent, one substrate. The same dsp publish path works from Codex CLI, Claude Code, Cursor, a CI job, or a plain build script — not just the Codex app. The artifact survives a change of agent or model. (See MCP as a publish tool for agents.)
• Durability. Version history, rollback, source export, an audit log of who opened what, and anchored comments that an agent can read and act on to republish.

This isn't "leave Codex." Codex can stay the operator — for a public artifact it can even open the display.dev URL in its in-app browser and annotate the live surface; for gated ones, use the display.dev MCP or export/update tools. Codex is the operator; display.dev is where the artifact lives.

Codex Sites vs. display.dev

Using only publicly documented Codex behavior and shipped display.dev features:

The split is clean: Codex Sites is the better in-workspace creation and refinement surface; display.dev is the better publishing-and-keeping surface when the audience or the agent isn't fixed to OpenAI.

How to pick

• Work created in Codex, every viewer in your OpenAI workspace, annotation refinement is the job: use Codex Sites.
• The artifact needs to reach someone outside your workspace, keep a stable URL, carry versions and comments, or be maintained from another agent: publish it to display.dev.
• You want both: let Codex create and refine, then publish the result to display.dev for durable, external, cross-agent sharing.

For the full landscape across Claude, ChatGPT, and the rest, see how to share Claude and Codex artifacts externally — 8 tools compared.