Artifact sharing fails: "This version can't be shared publicly" persists across republish and new artifacts

Same error here, adding a reproduction data point.

Error: "This version can't be shared publicly. Publish a new version or change the shared version, then try again." when switching General access from "Only you" and clicking "Share publicly".

Environment:

• Claude Code CLI on macOS (darwin), artifact published via the Artifact tool from a CLI session
• Personal account (gmail), viewing at claude.ai/code/artifact/<id>
• Artifact: fully self-contained static HTML (inline CSS, native mermaid fences), no capabilities declared, no MCP connectors

Tried, all failed with the same error:

1. Republished a new version to the same URL (with a version label) — error persists
2. Published the same file under a new filename → brand-new artifact at a fresh URL — error persists on first share attempt
3. "Shared version" dropdown shows "Latest" and is greyed out/disabled, so the error's own suggestion (change the shared version) is not actionable

Renders fine for the owner; only public sharing is blocked. Happy to provide artifact IDs privately if useful.

Hitting this on a personal Max account with CLI 2.1.220. Same error across four republished versions and two separate artifacts, including one published with capabilities explicitly cleared and the runtime contract bumped to latest, so it isn't a stale version or a connector declaration. The docs say a public link is the only way to share an artifact on Pro and Max and that no admin management applies on those plans, which means there is no External sharing toggle for an individual account to turn on. Looks like the org-level external-sharing flag is being evaluated against the auto-created personal org, where it defaults off and has no admin UI. If that's the cause, public sharing is unreachable for every Pro and Max user rather than being a per-artifact problem.

same error

Super annoying. I see this too.

same here, Claude Max account

Another failed workaround: reducing size from 7mb to 0.39 MB

Another: publishing by overwritting a past artifact that was sharable also doesn't work

Bisected this today and found at least one concrete trigger — it is content-based, not account- or org-level.

A raw, unencoded data:image/svg+xml,<svg …> URI anywhere in the artifact source blocks public sharing.

In my case it was a one-line emoji favicon:

<link rel="icon" href='data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><text y="14" font-size="14">🧭</text></svg>'>

How I narrowed it

Published one artifact per variant and tried Share → "Anyone with the link" on each:

| variant | shareable |
|---|---|
| trivial control page | ✅ |
| full report, prose only (67 KB, no JS, no data) | ❌ |
| first half of sections | ❌ |
| second half of sections | ❌ |
| everything except the TL;DR | ❌ |
| TL;DR only | ❌ |
| 20 KB stylesheet only | ✅ |
| the favicon line only — 144-byte page | ❌ |

Then isolating what about it:

• data:image/svg+xml;base64,<base64> → ✅ shares
• raw data:image/svg+xml,<svg …> in <link rel="icon"> → ❌
• the same raw SVG URI in an <img src> → ❌

So it's the unencoded SVG markup inside a data: URI — not SVG as such, not favicons, not the <link> tag. My guess is the publish-time scanner treats inline SVG markup as active content (SVG can carry script).

Fix

Base64-encode the SVG data URI, or drop the <link rel="icon"> entirely (Claude Code's Artifact tool has a favicon parameter that sets the tab icon anyway). Base64-encoding that single URI and changing nothing else made a 1.4 MB report share immediately.

Ruled out

Artifact size (6.9 MB, 1.4 MB and a 144-byte page all failed), the capabilities declaration, window.claude.* runtime references, and the page's prose. The failing PATCH /api/frame/perm/<id> returns 409.

@kristianward416 @ouell @darmawan01 @mirzaromi @trauts2 @sandrods — worth grepping your sources for data:image/svg+xml, (comma, not ;base64,). Several of you mention Mermaid diagrams; Mermaid renders to SVG at runtime rather than in the source, so that may well be a different trigger and I haven't tested it. But if any of you have an inline SVG data URI in the file, that alone is enough to reproduce.

Also worth fixing on the product side: the error message points at "publish a new version", which cannot help when the cause is in the content itself. Naming the offending construct would have saved a lot of guessing.

---
Investigation run by Claude (Opus 5) in Claude Code, posted by @Butanium.
Co-Authored-By: Claude <noreply@anthropic.com>

another time republishing worked, there was somehow a transient error

Another data point: removing a Mermaid diagram fixed sharing for me, and my source never contained an SVG data URI.

One artifact with a single <pre class="mermaid"> ER diagram refused to share. I replaced that diagram with a static HTML/CSS table, changed nothing else, republished to the same URL, and "Anyone with the link" worked immediately. Published size went from 3.2 MB (almost all of it the Mermaid runtime injected at publish time) down to ~38 KB.

I can't say whether Mermaid as such is the trigger. Removing the block also removed the injected bundle, and the only two <svg occurrences anywhere in the published page were inside that bundle, in code that builds SVG by string concatenation:

return'<svg xmlns="http://www.w3.org/2000/svg"'+r+">"+e+"</svg>"

So it's consistent with @Butanium's theory extending to SVG markup inside a JS string rather than only in a data: URI, but I have not run the isolating test (a page with an inert SVG string and no Mermaid) to confirm. Posting in case someone else has already ruled that in or out.

Practical workaround either way: if a diagram is the only blocker, hand-writing it as HTML/CSS restores sharing and drops several MB at the same time.

Can confirm — same fix worked for me. Had a Field Manual–style spec page (architecture + ER + 4 sequence diagrams, all inside <pre class="mermaid"> blocks, ~all text, no images, no raw data:image/svg+xml, anywhere in my source). Public sharing failed with the same "This version can't be shared publicly" error, and persisted across republishing to the same URL and to a fresh URL under a new filename.

Rebuilt all four diagrams as static HTML/CSS (a routing-table layout for the component diagram, entity cards + a relationship table for the ER diagram, numbered procedure lists for the sequence diagrams) and removed every <pre class="mermaid"> block — nothing else changed. Republished to the same URL and "Anyone with the link" worked immediately.

This lines up with @sandrods's finding — the Mermaid runtime bundle injected at publish time builds its output via SVG string concatenation, and that seems to be enough to trip the same scanner as a raw inline SVG data: URI, even with zero literal SVG markup in the authored source. Worth the product team confirming whether the scanner runs against the rendered page (including injected runtime bundles) rather than just the authored source .