--- title: "Sharing OpenAI Codex Output Externally: What Codex Sites Does (and Doesn't)" slug: /blog/share-codex-artifacts-externally publishedAt: "2026-06-29" updatedAt: "2026-06-29" priority: P1 keyword: share Codex artifacts externally secondary_keywords: OpenAI Codex Sites external sharing, Codex Sites limits, share Codex output with clients, publish Codex output, Codex Sites custom domain funnel_stage: Problem-aware → Solution schema: Article, FAQPage word_count_target: 1700 description: "OpenAI Codex Sites publishes interactive work to a URL inside your workspace. Here's exactly what it shares, where it stops, and how to share Codex output externally and across agents." --- # Sharing OpenAI Codex Output Externally: What Codex Sites Does (and Doesn't) > **TL;DR:** Codex Sites turns Codex work into an interactive site shared by URL *inside your OpenAI workspace* — strong for in-workspace decision surfaces, but not documented for external/guest sharing, custom domains, versioning, or publishing from anything other than the Codex app. When the work needs to reach people outside your workspace or stay durable across agents, publish it to a host that isn't tied to one workspace. Codex stays the operator; the artifact lives somewhere it can outlast a single tool. 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](/blog/claude-publish-button-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: ```bash dsp publish ./codex-output.html # Returns: https://acme.dsp.so/codex-output ``` 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](/blog/mcp-publish-tool-agents).) - **Durability.** Version history, rollback, source export, an audit log of [who opened what](/blog/know-if-someone-opened-your-link), 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: | Capability | Codex Sites | display.dev | | ----------------------------------- | ---------------------------- | ------------------------------------------------------------- | | Source agent | Codex app only | Any agent — Codex CLI, Claude Code, Cursor, CI, build scripts | | Publish a file directly | Worker-wrapped app artifacts | Yes — `dsp publish file.html` | | Share inside your workspace/company | ✅ (workspace URL) | ✅ (company visibility) | | Share externally / with guests | Not documented | ✅ named emails, cross-org, public | | Viewer auth | OpenAI workspace identity | Viewer's own company Google/Microsoft — no account | | In-place AI refinement | ✅ Strong (annotations) | Via comments, not native AI editing | | Versions / rollback / source export | Not documented | ✅ Shipped | | Comments | Annotations (in-Codex) | ✅ Anchored comments (human↔agent loop) | 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](/blog/share-claude-codex-artifacts-externally). ## FAQ **Q: Can you share Codex Sites outside your OpenAI workspace?** Not in a documented way. OpenAI describes Sites sharing as "share with your workspace using a URL," gated by workspace access modes — there's no published external-guest, cross-org, or public-link mode. To share Codex output with someone outside your workspace, publish the output to a host that supports external or company-SSO viewers, such as display.dev. **Q: Does Codex Sites support custom domains?** OpenAI has not announced custom domains or publisher-owned URL namespaces for Sites; sites are served on OpenAI hosting. If you need the artifact on your own URL, you'll need to publish it elsewhere. **Q: Can I publish Codex CLI output as a site?** There's no documented Sites creation or deploy path from Codex CLI, the API, MCP, or non-Codex agents — Sites is announced as a Codex-app feature. A neutral CLI like `dsp publish ./file.html` publishes output from Codex CLI, Claude Code, Cursor, or any other agent to a shareable URL. **Q: Where are Codex Sites hosted?** On OpenAI's infrastructure, deployed as Cloudflare Worker-compatible app artifacts. A single HTML page is wrapped in a small Worker as the hosting adapter, rather than served as a raw file. ## Share Codex output in one command When the work needs to leave the workspace — or just outlast this month's agent — publishing takes one line: ```bash dsp publish ./codex-output.html ``` Any agent's output, a URL your audience opens with the company login they already have, and versions and comments so it stays a living document. [Try display.dev free →](https://display.dev)