"This version can't be shared publicly" — what the error means and how to get the work to your client anyway (2026)

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.

First: which failure do you actually have?

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.

The message itself offers two moves — "Publish a new version or change the shared version, then try again" — and it's worth knowing what's been reported about each before you spend an afternoon on them:

• "Publish a new version." One report on Anthropic's tracker walks through doing exactly that, then going further: republishing the same file to mint a fresh version, and then creating a completely new artifact from a copy at a different path — new artifact object, new URL. The same error came back both times. That reporter's read is that whatever is declining sits at the account or session level rather than inside any one artifact, which would explain why changing the artifact doesn't move it. (issue #79824, still open when we checked on 24 August 2026.)

• "Change the shared version." The control this refers to — the Shared version: Latest dropdown — is reported as not opening when clicked. (issue #82974, closed as a duplicate of the above.)

• A close cousin: "Can't switch to Latest while people outside your organization can open this artifact. Change who has access first." This one appears when you try to move a link you already sent over to the newest version. One person who hit it in September 2026 had shared an earlier version by link and invited nobody, and reported that setting general access back to private didn't clear it — nor could they find a separate access control to change. (thread on r/ClaudeAI) It's a single report and we haven't reproduced it, so read it as a known snag, not a diagnosis. If your goal is simply that the people holding that link see the current work, the export route below gets you there without waiting on the setting.

None of that means don't try; both are one click each. It means give each one attempt, not an afternoon. If neither lands, the toggle isn't the road to your client, and the rest of this page is.

Is the page too big? Probably not, though it's a fair question. Anthropic's Claude Code documentation now states a size limit: the rendered page must be 16 MiB or smaller, with large embedded images the usual cause when a publish fails for size (checked 15 September 2026). That limit is about publishing the artifact, though, not about sharing it publicly — the docs don't say whether public sharing has a stricter one. And size clearly isn't the usual culprit here: one report describes a roughly 25 KB static page with no scripts and no connectors hitting this exact error (issue #85550, closed as a duplicate of #79824). If your page is small, don't spend time shrinking 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.

The line worth memorising

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.

Why this is more than a workaround

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.

The sequence, start to finish

1. Ask which failure you have: toggle refusing, or link working-for-you-only.
2. If it's the second one, check whether the artifact calls Claude at runtime. If it does, exporting is the only route — and be honest with yourself about whether the exported version still does anything useful without the model behind it.
3. Ask Claude for the full HTML as a single self-contained file.
4. Open it locally. Confirm it renders on its own.
5. Upload it and send the link. Add a password if it's under NDA, an expiry if it's tied to a review window, or leave it permanent if it's a reference the client should keep.
6. When you revise, replace over the same link so nobody is reading last week's version.

When to just publish instead

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.