ChatGPT Sites can now be shared privately. The viewer still signs in.

What shipped on 11 September

The announcement from @ChatGPT bundles five updates, three months and "over 5M sites" after launch: invite teammates to edit, save and publish a shared Site; invite specific people to a private Site without making it public; deploy in half the time; ask ChatGPT to inspect a Site's database, which editors can view too; and connect your own custom domain. Collaboration and custom domains were already in the docs in August. Private sharing is the new one, and it is the one this post is about.

The help center caught up a few days before the tweet. Its list of access options still has four entries, but the second one changed. It used to be "selected active users or groups". It now reads: "Selected active users or groups, and named external viewers." Everything below follows from that clause.

How the invite works, step by step

From OpenAI's help center, condensed and quoted where the wording matters:

1. Open the Site and select Share. Set "Who has access" to "Only those invited" to keep it private.
2. "Use the available people or email control to enter the email address for the person you want to invite." On a personal Site the control is "Enter an email address".
3. "Review the recipient and their view-only access, then save the sharing change."
4. "Confirm that the person appears in the Site's access list. Ask them to open the Site while signed in with the account that received access."

The person you invited "cannot edit or publish the Site" and does not become a workspace member. To revoke, remove them from the access list, then, in the help center's words, "check the remaining audience settings", because workspace-wide or public access may still let them in. In Enterprise workspaces the ability to invite external viewers is itself a permission an admin has to grant.

This is a real improvement over the July model. Our earlier post on sharing a Site with a client said the only private audiences were accounts inside your own workspace, and that a client "either needs a seat or gets a URL anyone can open". The seat is no longer required. That post is updated today to say so.

The sentence that decides it

"Invited visitors must sign in with the account that received access."

That is the whole mechanism. The invite is an entry on an access list keyed to an email address, and the check at the door is a ChatGPT sign-in on that address. It is the same identity check the workspace options use, extended to one more identity. It is not a link that carries its own permission.

People in the launch thread landed on the same point within the hour. One reply asked the question directly: "Do people still need to be logged in to ChatGPT? If so it's not really viable." Another, with the most likes of any skeptical reply, read "share privately" as private from everyone except OpenAI. In the product lead's feedback thread the day before, a developer described wanting "super simple multi-user auth, e.g. only this list of gmail folk can access", finding that a Pro account could not do it, and hand-rolling authentication on a public Site instead. That is the shape of the demand: a list of people, no accounts, no public URL. Private sharing answers the first part of it.

What private sharing still does not have

• A passcode. Nothing a recipient types to get in. Access is identity or nothing.
• An email-domain gate. You cannot say "anyone at client.com". You name people one at a time, and each of them signs in.
• An expiry. No date after which the link stops working. Asked for one in the feedback thread ("Sites with expiry date and auto delete. Would be useful for polls or survey"), the product lead suggested having Codex add a scheduled task that disables the Site or swaps in a "poll closed" page. Workable, and not a setting.
• A link-only private mode. Our London test in August found a personal plan offered "Only you" and "Anyone with the link"; the docs now add invited viewers. There is still no mode where an unguessable URL is itself the credential.
• Per-recipient links. Every invited viewer opens the same URL after signing in. There is no way to know which of three invitees opened it without building that into the Site.

The database line worth reading twice

"Explore your data: ask ChatGPT to inspect your Site's database. Editors can view it, too." Two replies to the announcement flagged the same thing independently: database access shared with every teammate you invite as an editor is a larger grant than "collaborative editing" suggests. The docs agree in plainer words: "Editors can read the Site's live database data." Invited viewers are not editors, so this does not apply to them. But if the reason you want a private Site is that it holds real data, the permission to keep straight is "Can edit", not "Can view".

When invited viewers are the right tool

Plenty of cases, and it is worth being fair about them. A co-founder who already lives in ChatGPT. A stakeholder at a partner company who has a Plus account and is happy to sign in. A dashboard with a live database that a handful of named people should be able to poke at, where a sign-in is a feature rather than a hurdle. Anything where the viewer is technical, already a ChatGPT user, and the Site is an app rather than a document. Sites builds full applications with a database and server logic, and private sharing gives those apps a real audience short of the open internet. Use it.

When the reader is a client

The case that does not fit is the one where you are sending finished work to someone who did not ask to create an account. A proposal, an audit, a quarterly report, a design review: the reader is a client, the content is theirs, and the relationship is that you make it easy for them. Asking them to sign up for ChatGPT so they can read a PDF you could have emailed inverts that. The person who wanted "only this list of gmail folk" did not want those people to have ChatGPT accounts. He wanted a list.

That is the case Stacktree is built for, and it starts from the link rather than from an identity provider. Every published page is an unguessable private URL. A client opens it with no account. If the content needs a gate, you add a passcode they type, or a company email-domain gate they pass with a one-time magic link, still with no account created. Links can expire or delete themselves after first view. Each recipient can get their own named link, so you know who opened what and can revoke one person without touching the rest. The page sits on your own domain from the Solo plan, and any agent can publish it over MCP or a single curl, then revise it in place on the same URL.

Two products, two questions. Sites answers "how do a few named ChatGPT users get into my app?" and now answers it well. The question a deliverable asks is "how does one person outside the building read this with no friction, and how do I know they did?" Private sharing moved the first question forward today. The second one still has the same answer it had in July.