Can a Codex Site have a custom domain? Not under the documented model.

The short answer

As of June 24, 2026, a Codex Site cannot have a custom domain under the documented model. OpenAI documents deploying and hosting a Site at its own URL, and controlling who in your workspace can view it through three access modes. There is no documented way to attach a domain you own, change the hostname, or add a DNS or CNAME record. The OpenAI-managed URL is the address.

That is consistent with what Sites is for. The feature is positioned around internal tools, dashboards, and shared workspaces, and an internal tool does not usually need a vanity domain. The gap only bites when the thing you built is meant to leave the company: a client-facing page, a public microsite, a deliverable that should sit at your-company.com. That is a different job, and it is the job a custom domain exists for.

Why the address is OpenAI’s, not yours

Codex Sites hosts your deployment and scopes access at the workspace level. The three documented access modes (admins_only, workspace_all, and custom) all decide which members of your OpenAI workspace can open the Site; none of them touch where the Site lives or what it is called. There is no domain layer in the documented model at all, so there is nothing to point a custom domain at.

This is coherent for an internal tool. If a Site is only ever opened by people inside your workspace, the URL is plumbing, not branding, and an OpenAI-managed address is fine. The design optimizes for "deploy fast, share with the team," not for "publish under our brand." Neither is wrong; they answer different questions, and custom domains belong to the second one.

When you actually need a custom domain

A custom domain matters the moment the audience is external. A few cases where the OpenAI URL stops being enough:

• Client deliverables. A report, proposal, or dashboard you hand to a customer reads very differently at your-firm.com than at a vendor URL.
• Public microsites. A landing page, a launch page, or a one-pager that anyone should be able to open, indexed and shareable, lives on a domain you control.
• Permanence and portability. A domain you own is an address you keep. If the underlying host changes, the URL you have shared does not have to.

If your output never leaves the workspace, none of this applies and Sites is a fine home for it. If it does, you need a published page on a domain you control, which is a publish step Sites does not document.

How to put agent output on your own domain today

Full disclosure: this section describes Stacktree, which is our product, so read it as us explaining where we fit rather than as neutral advice. If what you need is agent output living on your own domain, with no OpenAI workspace seat required to view it, the pattern today is different from deploying a Codex Site, and it is worth being honest about both what it does and what it gives up.

The pattern is not to export or move a Codex Site. There is no documented way to do that, and Stacktree does not do it. Instead, you have the agent render a static HTML view of what you want to show and publish that HTML to an open host. Codex can do this directly: it generates the HTML and calls a publish tool over MCP, without leaving the session.

Stacktree is the open host in that pattern, and it supports custom domains. A published site is private by default, with the unguessable URL as the credential, so a viewer needs no account and no workspace seat to open it. On the Pro plan you attach your own domain through Cloudflare for SaaS: add a CNAME, verify it, and the page serves from your-company.com instead of a vendor URL. update_site replaces the content in place at that stable address, so the link you shared keeps working as the page changes. It is MCP-native, so it works from Codex, Claude Code, Cursor, and Claude.ai rather than inside one agent, and it is source-available and self-hostable on your own Cloudflare account.

The trade is real and you should weigh it. Stacktree hosts static HTML only: no server logic, no application database, no in-browser editor. If you need a full internal app with persistence behind it, the kind of thing Sites in Codex is built to deploy, Stacktree is not that, and Sites is the right tool. Stacktree fits the narrower case: a page anyone can open by link, on your own domain, that you can take with you. The two are not substitutes; they answer different questions.

What would change this answer

This is a living status post, refreshed when OpenAI ships a change. As of June 24, 2026 the answer is no documented custom-domain support. Here is the watch-list that would move it:

1. Documented custom-domain mapping. If OpenAI documents a way to attach a domain you own to a Site, with a DNS or CNAME step, the headline answer flips.
2. A public or external-viewer mode. A custom domain is most useful when outsiders can view the Site at all. A documented public or link-only mode would be the natural precondition. See our note on whether you can make a Codex Site public.
3. Export or self-hosting. Not documented today. A path to download the code or move a deployment would let you take it to any host and put it on your own domain.

If any of these is documented, we will update this post and note the date. Until then, the answer above reflects the documented state of Codex Sites and is dated accordingly.