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

[kristianward416]

Description

Attempting to make a published Artifact (Markdown page with a Mermaid diagram) shareable via the "anyone with the link" toggle in the share menu fails with:

This version can't be shared publicly. Publish a new version or change the shared version, then try again.

Steps to reproduce

1. Publish a Markdown artifact via Claude Code's Artifact tool (.md file with a ```mermaid fenced diagram, standard frontmatter-free content, headings, tables).
2. Open the published artifact page.
3. Use the share menu → toggle to "anyone with the link".
4. Error appears immediately.

What I tried to work around it

• Republished the exact same artifact (same file path) to mint a new version — same error.
• Created a completely new artifact from a copy of the file at a different path (new artifact object, new URL) — same error persisted.

Since the error survived both a version republish AND a brand-new artifact object, it doesn't look like a per-artifact/per-version issue — seems account- or session-level.

Expected behavior

The share toggle should either succeed, or give an error that's actually actionable (the current message tells the user to do something — "publish a new version" — that was already tried and didn't help).

Environment

• Claude Code CLI
• Artifact content type: Markdown with Mermaid diagram

[ouell]

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/
• 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.

[darmawan01]

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.

[mirzaromi]

same error

[trauts2]

Super annoying. I see this too.

[sandrods]

same here, Claude Max account

[Butanium]

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

[Butanium]

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

[Butanium]

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

[Butanium]

another time republishing worked, there was somehow a transient error

[sandrods]

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.