ChatGPT Sites plugins: deploy a Codex project with live data

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

ChatGPT Sites plugins let a Site you build load data from each visitor's own connected apps, so one internal tool shows every teammate their own records under their own permissions. OpenAI announced the change at DevDay on 29 September 2026, and the Sites documentation describes the setup. You can start from an existing Codex project, but plugin use needs a workspace plan and a Site that stays private to that workspace.

Sites itself is in public beta. Treat everything below as beta behaviour that can change, and check the docs again before you build something people depend on.

Who can use ChatGPT Sites and plugins?

Two availability rules apply. Building and hosting a Site is one. Letting that Site call plugins is the other.

The last row matters for Enterprise teams. Your Site can be ready while a plugin toggle is still off. The admin docs also say that allowing a plugin in Sites does not override ordinary plugin permissions or tenant restrictions.

Deploy an existing Codex project to ChatGPT Sites

The Sites product page says you can start from an existing Codex project. The docs describe it as deploying a compatible local project, and they suggest this prompt:

Deploy this project with Sites. Check whether it is compatible, make any required changes, and give me the deployment URL.

Sites links your source to hosting through .openai/hosting.json. That file stores the project ID and optional storage bindings. When you deploy from local source, Sites associates the version with the Git commit used for the build. Keep the file under version control so the link between repo and Site shows up in review.

Publishing has two stages. You first save a version, which gives you a reviewable deployment candidate. Then you deploy that version to the production URL. Use the gap between those steps the way you would hold a pull request before merge.

Pick the site shape before you ask for features. The docs describe three cases: a content site without persistent state, a Site that needs D1 for structured data or R2 for file uploads, and a Site that needs identity. For internal tools, they point to workspace authentication.

How do you add a plugin to a Site?

Plugin support has three owners: the workspace admin, the person building the Site, and each visitor.

The admin enables it per plugin. The documented path is:

1. Open Admin > Plugins in the workspace.
2. Select the plugin, for example Notion.
3. In the Sites section, turn on Allow site visitors to use this plugin.
4. Select Save.
5. Review each plugin the Site needs for availability and permissions.

If a toggle is disabled, tenant connector access may be blocked. The admin then follows the External access link, or asks the tenant administrator to enable Connectors for ChatGPT Sites.

As the builder, you keep the Site private to the workspace. New Sites start with access limited to the owner and workspace admins, so share it with the right people once it works.

Each visitor signs in with ChatGPT, reviews the access request, picks a connected account and grants consent before the Site receives any app data. On page load, Sites reads that data with the visitor's own connection and permissions, and it manages caching for you. The product page calls this read-only access to visitors' connected tools in eligible workspaces.

For identity in your own code, Sites handles the routes /signin-with-chatgpt and /signout-with-chatgpt. After sign-in it forwards the visitor's identity to your server in request headers, including oai-authenticated-user-email and, where available, oai-authenticated-user-full-name.

Secrets, editors and data you should not host

Put environment variables and secrets in Site settings. The docs say never to embed them in prompts or content, which also rules out pasting them into the Codex chat that builds the Site.

Editors can read the Site's live database data. Invite editors with that in mind, because edit rights include the stored records as well as the layout.

The documented limits are short. D1 database storage is 10 GB and R2 object storage has no fixed limit. HTTP, HTTPS and WebSockets work, raw TCP does not, and data residency is not available at launch. The docs also exclude some uses outright, including Protected Health Information, payment-card data, services aimed at children under 13, financial transactions, malware, phishing and impersonation.

Try it with one internal request dashboard

The docs include a sample prompt for a project request dashboard where team members submit requests, see owners, update status and filter the list. It is a good first Site for a Codex user, because the data model is small and the review questions are clear.

1. Open the repo in Codex, or start one from the request dashboard prompt. Add a line to AGENTS.md such as "no secrets in source, use Site settings" so Codex follows it on every edit.
2. Ask ChatGPT to deploy the project with Sites, and check that .openai/hosting.json appears in the diff.
3. Save a version, open the in-app browser preview and check the Site as an ordinary member, not as the owner.
4. Ask your admin to allow one plugin for Site visitors. Verify the consent screen, then confirm that a second teammate sees only their own data.
5. Deploy the version. A few days later, open More actions > Analytics to review unique visitors and page views.

Reject the version if any visitor sees data they could not open in the source app. That permission check is the whole point of the feature, so run it before anyone relies on the Site. Our Delegate, Review, Own methodology applies the same review checklist to any change an agent builds.

What about automations in Sites?

The DevDay recap says automations are now easier to add and manage, so Sites can keep shared information up to date. The Sites documentation does not yet describe how to configure those automations, which triggers they support, or how they count against usage. Wait for that page before you design a Site around scheduled updates.

Start with one read-only dashboard, test it with two teammates, and add a second plugin only after the permission check passes.

Further reading

• ChatGPT Sites documentation
• Sites setup for workspace admins
• ChatGPT Sites product page
• OpenAI DevDay 2026 recap