A disabled Publish button isn't one bug — it's four different situations wearing the same grey. Only one of them clears if you try again. Here's how to tell which one you're looking at, and how to get the page to the person waiting for it either way.
You finished the thing. You went to send it. The Publish button is grey.
(On newer artifacts the control is called Share, and what's greyed out is usually the Anyone with the link option inside it. Anthropic's docs say the Publish label is only left on older chat artifacts on Free, Pro and Max. Same four reasons either way.)
The frustrating part isn't the grey — it's that a greyed-out Publish button is at least four different situations wearing the same appearance, and only one of them clears if you try again. Pressing harder doesn't distinguish them. So the useful first move is diagnosis, not a fix.
Publishing looks like a single switch, so a disabled switch reads like a single fault. It isn't. Publishing an artifact is the end of a short chain of checks — is this artifact eligible at all, is this account allowed to publish outside itself, does this page need something only you can reach, is this particular version in a shareable state — and the interface collapses every failure in that chain into the same flat grey.
That's a reasonable design choice and a genuinely unhelpful one to be on the receiving end of. So take the four in order of how permanent they are, because there is no point troubleshooting a situation that has already been decided.
This is the first thing to rule out, because it's the only one where continuing to try costs you time you can't get back.
Anthropic's documentation states: once you unpublish an artifact, you cannot publish that same artifact again, and you'll need to create a new artifact if you want to publish it later.
There is no plan, setting, or support path that undoes it. If someone with access to this conversation pressed Unpublish at any point — including as a way to "reset" something that looked broken — the button you're looking at is not going to come back for this artifact.
Two consequences people usually don't expect. First, a new artifact means a new link, so any URL you already sent out doesn't start working again. Second, this is why pressing Unpublish during an outage is such an expensive reflex: we wrote about that specific trap in Claude artifact storage temporarily unavailable, and the full shape of the one-way door is in how to unpublish a Claude artifact — and what it permanently takes with it.
If this is your situation, skip to getting the source out. Rebuilding as a fresh artifact works, but it is not a repair — it's a second copy with a different address.
If the button is grey on your work account but behaves normally on a personal one, this is almost certainly why.
Anthropic's documentation says that on Team and Enterprise plans, artifacts stay inside your organization by default. "Anyone with the link" only becomes available once an Owner has turned on External sharing, or has allowed that one artifact individually.
So nothing is broken here. There is a switch, but it isn't on the artifact and it isn't yours: it belongs to whoever holds the Owner role on the account. The account you built it in decides who the artifact can reach, and a work account defaults to "people inside this org". That's coherent: an organisation that pays for a shared workspace generally does not want everything made inside it to be one click from a public URL.
One wrinkle for older chat artifacts (the ones whose button says Share & copy link rather than Share): even with External sharing on, Anthropic's docs say the people you send it to need a Claude account to open it, and they also get access to the attachments and files in that chat. Worth knowing before you send one to a client.
Where it stops being coherent is the common case — you're doing client work from a work account, and the client is by definition outside the org. Then the design that's protecting you internally is the design standing between you and the person who's paying. The org boundary is the product working; it's just pointed the wrong way for what you're doing. We went through the related version of this for a different platform in share a ChatGPT Sites page outside your workspace — the shape of the problem is the same one.
Same Team account, different product, different setting. It's easy not to notice which one you built in.
Two limits either way: it's an Owner's switch, not yours, and an artifact that uses connectors (Cowork's docs say connected apps) still can only be shared inside the organization. Checked against Anthropic's pages on 15 September 2026 (Claude Code, Cowork) and 1 October 2026 (sharing artifacts). It's their product and their wording, so they can change it. Who can open a Claude Code artifact on each plan is laid out in Claude Code wants to publish an artifact — who can open that link?
If the message mentions connectors, the block isn't really on publishing. It's on what the page would do once published.
Anthropic's documentation says artifacts that connect to your apps or use Claude can't use "Anyone with the link". It also answers the obvious worry: when one of these artifacts is shared with specific people, it uses the viewer's connections, not yours. Nobody borrows your account by opening it.
That's also why the public option is off. A stranger who opens a public URL has no connections and possibly no account, so the page would have nothing to fetch with. Sharing it with named people who have their own connected apps works. Sharing it with "anyone" doesn't have a working version.
The move that actually works is to separate the two things the artifact is currently doing at once: fetching data, and displaying it. Fetch while you're signed in, bake the result into the page, and what's left is a page that shows a finished answer rather than one that goes looking for it. We wrote that out properly in sharing a Claude artifact that uses connectors.
If the wording points at a version — publish a new version, or change the shared version, then try again — this is the one case where the obvious action sometimes works.
Sometimes. The trap is that the message is phrased as an instruction, so people follow it repeatedly. If you publish a new version and hit the same wall, the message was describing the symptom rather than the cause, and the real reason is one of the three above. Two failed attempts is enough evidence to stop.
We pulled apart the two distinct failures hiding behind that one sentence in this version can't be shared publicly. And if you're unsure which of Claude's several sharing controls you're even looking at — publishing an artifact and sharing a conversation are not the same act, and unsharing doesn't undo the same things — which Claude shares are public, and what unshare actually undoes untangles them.
Whichever of the four you landed on, the work itself is fine. Publishing is a distribution step, not storage — the page still exists in the conversation, and the conversation is a perfectly good door.
Ask for it plainly:
Print the complete source of that artifact as plain text in this chat — a single code block, nothing summarised, no placeholders. Do not create an artifact.
Those last two sentences are doing real work. Without them you tend to get an abridged version with a comment in the middle saying the rest is unchanged, which is not a copy of anything. Ask for the whole file, and read what comes back before you close the tab.
Then save it as an .html file on your own machine. At that point you're holding the deliverable rather than a permission to display it, and the grey button is no longer on the critical path.
Every AI tool that builds things for you also decides who is allowed to see them, and those decisions are made for the tool's own reasons — org boundaries, one-way doors, whose connections a page runs on. All four of the situations above are defensible from where the platform is standing. They're just being applied at the moment you needed to hand something to someone.
The durable version of this is to keep building wherever you like and to treat delivery as a separate step you control. A self-contained file you hold can go anywhere; an artifact can only go where its platform currently permits. Same content, very different dependency.
If the destination happens to be a client rather than the public web, that's the thing miinideck is built around — you drop the finished HTML file and get back a link that isn't guessable, with a password on it if you want one, on any tier including the free one. But the part that matters here isn't which host you pick. It's that the file exists on your side of the line before you need it to.
If you got here because the button is grey right now: work out which of the four it is first. Three of them can't be fixed by trying again, and knowing that in the next minute is worth more than any workaround.
The message is about Anthropic's side, not yours, and it usually clears on its own. The risk isn't the outage — it's what people press while waiting. Here's the safe order of operations, and how to get the work out of the artifact while you wait.
You built something in Claude, came back weeks later, and it's gone. Usually it isn't deleted — it's sitting inside a conversation you can no longer find. Here's how to get it back, and the one case where it really is unrecoverable.
Artifacts stop appearing and every guide says the same four generic fixes. Here's the order that actually separates a setting on your side from an outage on theirs — starting with the one documented cause that produces total failure.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.