How to enable the Codex Sites plugin (Business & Enterprise)

If Codex Sites is missing from your Codex app, the fix is almost always one of two things: your plan does not include it, or an admin has not switched it on for your role yet. This is the enablement guide — who can even see Codex Sites, the Enterprise role-based access control step versus Business being on by default, how to add the plugin in the app or the CLI, the new-thread-after-install gotcha that trips everyone up, the config file toggle to turn it off later, and how to invoke it with @Sites. It is short on purpose, because enabling it is genuinely just a few steps once you know the order.

Check your plan first

Before you touch any setting, confirm Codex Sites is even on your plan. It launched in preview on ChatGPT Business and Enterprise, with more plans rolling out — so if you don't see it, your plan may not be in the rollout yet.

Two caveats worth stating plainly. Codex Sites began on Business and Enterprise with more plans rolling out during the preview, so this table is a snapshot — the official feature-availability page is the live source of truth for your plan. And on Plus specifically, Codex plugins in general are more limited: some first-party plugins are unavailable and app connectors are restricted to Business, Enterprise, and Edu.

Enterprise: enable Sites via RBAC

On Enterprise, Codex Sites ships off and stays invisible to members until an admin turns it on. This is by design — Enterprise gates plugins behind role-based access control so admins decide which roles get which capabilities.

The admin step is short:

1. Sign in to ChatGPT admin settings at chatgpt.com/admin/settings with an admin account.
2. Find the role-based access controls for Codex plugins.
3. Enable the Sites capability for the role or roles that should have it.
4. Save. Members in those roles can now add the Sites plugin themselves.

The admin enables the capability for a role; the member still installs the plugin in their own Codex app afterward. So "enabled by the admin" and "added by me" are two distinct actions on Enterprise, and skipping the first is the single most common reason an Enterprise user cannot find Codex Sites.

Business: it's on by default

Business is the easy case. Codex Sites is enabled by default for the workspace, so there is no RBAC step and no admin gate to clear. Members go straight to adding the plugin. If you are on Business and you do not see Sites, the problem is usually that you have not added the plugin yet — not a permission. Jump to the next section.

Add the Sites plugin (app and CLI)

Once your plan and role allow it, adding the plugin is the same regardless of tier. You can do it from the Codex app or the CLI.

In the Codex app: open the Plugins directory. It groups plugins into "Curated by OpenAI", "Shared with you", and "Created by you" — Sites lives under the curated group. Open it and press the Add to Codex button.

In the CLI: run the plugins command and pick Sites from the directory, then choose Install plugin.

/plugins

Then — and this is the part people miss — start a new thread. A thread that was already open before you added the plugin will not see Sites. Open a fresh thread and the plugin is available. Some plugins also ask you to authenticate with an external service during setup or first use; Sites itself is hosted by OpenAI, but keep an eye out for an auth prompt the first time you invoke a plugin that needs one.

Here is the whole getting-started path in order, so the new-thread step does not get lost:

Turn it on or off later (config.toml)

Adding a plugin enables it. To disable Codex Sites without removing it, edit your Codex config file at ~/.codex/config.toml, set the plugin's enabled value to false, and restart Codex for the change to take effect.

# ~/.codex/config.toml
# Disable the Sites plugin without uninstalling it.
[plugins.sites]
enabled = false

Flip enabled back to true and restart to bring it back. This is the one place where "restart Codex" genuinely matters — installing relies on a new thread, but toggling the config requires a restart. The exact table key naming inside config.toml for the Sites plugin is not something we want to misstate, so treat the snippet above as the shape of the toggle and confirm the precise key in your own config file or the plugins documentation.

Invoke it with @Sites

With the plugin added and a new thread open, there are two ways to put Sites to work. You can describe the task in plain language and let Codex pick the right tools, or you can type @ to invoke a plugin or its bundled skills explicitly. Naming the plugin removes the ambiguity, which matters most when the job should end in a hosted deployment rather than generic code.

@Sites Create a small status page for my team and save a version so I can review it before it goes live.

After that first run, you return to your sites through Sites in the Codex app sidebar. From here the mechanics belong to the build-and-deploy flow rather than enablement.

Where this fits in your workflow

Enabling the plugin is the easy half. The harder half is the brief you hand Codex once Sites is live, because a vague prompt produces a vague site no matter how good the hosting is. That is the step worth doing before you type @Sites: we draft the site brief in oran.chat and pressure-test it across GPT, Claude, and Gemini in one place, branching the prompt instead of overwriting it, so the version Codex gets is the one that already survived three sets of objections. If you keep a single instruction set in play across those models, our pillar on the system prompt that works across GPT, Claude, and Gemini is the place to start.

For the surrounding context, what Codex Sites is covers the save-versus-deploy model and what runs under the hood, and how to use Codex Sites walks the end-to-end build flow once the plugin is on. The authoritative reference for plugin mechanics is the Codex plugins documentation. For more like this, see Playbooks.