Claude refuses to share your artifact and suggests publishing a new version — which often doesn't clear it. Here's the diagnosis that actually separates the two failures behind that message, and the export route that doesn't depend on the toggle working.
You finish something in Claude, go to send it, and the interface says:
This version can't be shared publicly
The suggestion that usually follows is to publish a new version, or switch which version is shared, and try again. Sometimes that clears it. It has also been reported to survive republishing — and to reappear on brand-new artifacts — which is the version of this problem people end up searching for at 11pm with a client waiting.
This matters more than any individual fix, because the two problems look identical from where you're standing and share none of the same solutions.
Failure one — the toggle errors. You click share, Claude declines, you see the message. Nothing gets published. This is happening inside Claude's sharing layer and you have limited leverage over it.
Failure two — the toggle works, the page doesn't. You get a link. It opens perfectly for you. Your client replies that it's asking them to sign in, or that it's blank. Nothing is broken on the sharing side at all.
The discriminator for the second one is a single question: does this artifact call Claude while it's running?
If it does — if it generates text on the fly, summarises something, answers questions — then it isn't a self-contained page. It's a front-end that needs a live Claude session behind it, and it was running on yours. A stranger opening that link has no session to offer, so the page loads and then can't do the thing it exists to do. That's not a bug and no setting corrects it. (An artifact that uses connectors is the sharpest version of this: it runs on the reader's own account access, and a stranger has none.)
If it doesn't — if it's a calculator, a dashboard, a report, a landing page, a prototype — then it's ordinary HTML, CSS and JavaScript, and it will run anywhere. Which means you don't need the share toggle to cooperate at all.
When the artifact panel's download button is missing, greyed, or gives you something that doesn't render, don't fight the interface. Ask in the conversation:
"Give me the full HTML for this as a single self-contained file."
You get the source in the chat. Save it as something.html. Done.
This is worth knowing even when nothing is broken, because asking beats downloading: you can specify what you want. Inline the CSS. Inline the JavaScript. Don't fetch fonts or libraries from a CDN if it needs to work in locked-down environments. A download gives you whatever the export happens to produce; a request gives you the file you actually need.
Then check it: open the file locally in a browser. If it renders, it's genuinely self-contained. If it's unstyled or empty, something load-bearing is still being fetched — hand it back and ask for those pieces inlined. The self-contained export checklist walks the specific things that tend to leak.
There's a temptation to treat exporting as the annoying fallback you resort to when the nice button is broken. For anything going to a client, it's the other way round.
A published artifact link is a preview surface belonging to a platform. That's a perfectly good thing to be — it's fast, it's free, it renders your work with zero setup. But its state is controlled somewhere you don't administer. A toggle can refuse. A version can become the wrong version. An unpublish is permanent in a way most people don't discover until they try to undo it.
None of that matters when the audience is you and two colleagues. It matters a lot when the person holding the link is the client who's paying for the work, because from where they sit there is no distinction between "the platform's sharing layer had an issue" and "the thing you sent me doesn't work." One of those is about a product you don't own. Both of them land on you.
A file you exported and hosted yourself has a smaller set of moving parts: your file, your link, your call on when it expires.
Drop the exported .html and get an unguessable, no-index link that opens for anyone — no Claude account, no sign-in wall, no toggle in the way.
Publishing is genuinely the better option when the work is meant to be seen widely — a public demo, a tool you want people to find, something you're linking from a post. It's fewer steps, it costs nothing, and reach is the entire point.
The export route is for the opposite case: a named recipient, a deliverable, something that shouldn't turn up in a search result. If you're regularly in that case, sharing a Claude or ChatGPT artifact privately covers the whole flow rather than just the part where something went wrong, and why AI share links fail the recipient maps the same failure across the other tools — because Claude is not unusual here. Every AI tool's native share link quietly assumes the reader is you.
The steps take about ten seconds. The cost is less obvious: unpublishing permanently retires that artifact's ability to be published, and deletes its stored data. Here's how to do it, what it takes with it, and what to reach for when access only needs to end for now.
Not to a public link — on any plan. On Pro and Max, a connector-backed artifact can't be shared at all. Here's the mechanism that makes that rule inevitable, and what to do once you know which page you're actually building.
ChatGPT Sites hosts what you build and gives you access controls — owner only, named workspace members, the whole workspace, or the public internet. There's no rung for one outside client. Here's the shape of that gap and the route round it.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.