Get a shareable link for what Codex built

Codex Sites is OpenAI's hosting, which its docs call Sites or ChatGPT Sites, and it's a separate product from host0. You describe a site in ChatGPT or Codex, and OpenAI builds and hosts it.

Sites is the better pick if you already pay for ChatGPT and want to build and host in one place, or if the app needs server code, file uploads or a real database. On a shared workspace, it also brings workspace sign-in with it.

host0 makes more sense if you stay in the terminal or the IDE, if the people opening it aren't on ChatGPT, or if you only need to hand over one file. One thing to weigh on the Sites side: OpenAI says it has no built-in way to back up a site's records and uploaded files together and restore them into a new site.

Not directly. OpenAI's docs say Sites has no management view in the CLI or the IDE extension, and they send you to ChatGPT on the web or in the desktop app to create, save, deploy and manage a site.

You can still edit and test a local project in the CLI first. Then ask ChatGPT, in the desktop app, to check that the project is compatible and prepare it. Sites records the link in .openai/hosting.json. Every Sites deployment URL is production, so ask it to save a version without deploying if you want to review the build before it goes live.

Because local Codex commands run with network access off by default, and a deploy has to reach host0. In the default Auto preset, Codex stops and asks; once you approve, the deploy runs.

To stop being asked for host0 alone, add a rule. It lets this one command prefix run outside the sandbox without a prompt, and leaves everything else as it was. OpenAI marks rules as experimental. Restart Codex after adding it.

prefix_rule(
    pattern = ["npx", "-y", "@host0/cli@latest"],
    decision = "allow",
    justification = "host0 deploys need the network and write to ~/.host0",
)

The rule covers the CLI route, so a fallback to publish.sh still asks. Setting network_access = true under [sandbox_workspace_write] looks simpler, but it opens the network for every command and still isn't enough: npx keeps its cache in your home folder and sign-in saves to ~/.host0, and the sandbox only lets commands write inside the workspace and temp folders.

The first deploy with no key prints a link and a short code, and Codex shows them to you. You approve in your own browser, so no email or password goes through the chat.

The key is saved to ~/.host0/credentials, outside the workspace, so that step is one more reason the run needs your approval. If you already have a key, set HOST0_API_KEY in the shell you start Codex from. Codex doesn't strip variables with KEY in the name by default, so commands see it unless your shell_environment_policy filters it out.

In ~/.agents/skills for your own skills, and in .agents/skills from the current folder up to the repo root. A copy under .claude/skills or .cursor/skills isn't on its list.

curl -fsSL https://host0.ai/install.sh | bash -s -- --agent codex

• Check: run /skills or type $ in the CLI or IDE extension. Codex normally notices a new skill by itself; if not, restart it.
• Too many skills: the first list Codex loads is capped at a small share of the context window, so with a long list it shortens descriptions and can drop some with a warning. Name $host0 if it isn't being picked.
• Installing from inside a session: .agents in the workspace is read-only to sandboxed commands and ~/.agents is outside it, so either one needs approval. Running the installer in your own terminal avoids that.

Take the plugin if you work in the Codex CLI and want both in one step. Add them separately if you use the IDE extension, since it doesn't support plugins.

codex plugin marketplace add host0-ai/skills

That only adds the marketplace. Type /plugins, switch to the host0 tab and install it, then start a new session, because a plugin's skills appear only in sessions started after the install. Pick one setup: the plugin bundles the same skill and the same MCP server, so there's no reason to add them again on top.

No. The sandbox applies to commands Codex spawns, and MCP connections are controlled separately, so a visibility change or a record fix works with command network access off. A deploy isn't one of its tools, so publishing still goes through the sandbox.

• Reading, like listing apps or fetching analytics, is marked read-only.
• Changing something, like sharing, restoring a version or editing a record, is marked destructive, and OpenAI's docs say Codex requires approval for those calls.
• On a terminal with no local browser, add --no-browser to the login command, open the printed link, sign in, and paste the redirect URL back.

codex mcp add host0 --url https://mcp.host0.ai/mcp

From the same folder, just ask again: .host0/state.json remembers the app, so the URL stays and unchanged files are skipped. A new worktree doesn't have that file, and a deploy from there creates a second app unless you name the first one.

Say "publish to team-todos", using the slug from your URL, and Codex passes it. The skill tells it not to commit the state file, and a desktop-app worktree starts from a commit, so the file doesn't come along by itself. If you use those worktrees a lot, add .host0/ to .gitignore and to a .worktreeinclude file in the repo root: the desktop app copies ignored files matching that list into each new worktree. It doesn't do this for worktrees you make yourself with git.

Run the deploy as its own step instead of through Codex. codex exec is read-only by default, --sandbox workspace-write adds edits but not the network, and a non-interactive run has nobody to approve a request.

npx -y @host0/cli@latest deploy ./my-site

Let Codex build, then run that command as the next CI step with HOST0_API_KEY set as a secret and --slug set to your app, since a fresh checkout has no state file. This should work, but we haven't run it next to Codex in a pipeline.

It should work, but we haven't run it ourselves. A cloud task gets its own VM and its own network settings, so it has neither your skill nor your key until you add them to the environment.

• The skill: commit it to .agents/skills in the repo. Repository skills reach cloud tasks; personal skills on your computer don't sync.
• The key: add HOST0_API_KEY under Environment variables, or in Personal vault if the environment is shared. A network secret gives programs a placeholder instead, and we haven't tried that with host0.
• The network: allow host0.ai and host0.app under Additional allowed domains, and keep the Package managers preset on so npx can fetch the CLI.
• The app: name the slug in your prompt, since the checkout has no .host0/state.json.

Save and republish the environment, then start a new task, because settings reach new tasks only. Stay on the current Codex Cloud: OpenAI's legacy version removes secrets before the agent starts. With no key at all, a task prints the same sign-in link, but the key stays in that task's VM and the next task asks again.