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.
You asked Claude for a dashboard and it built one that actually works — it reads the live numbers, it knows who's looking, there's a button that files the issue instead of telling you to go file it. It stopped being a picture of a tool and became a tool.
Then you go to send it to the client, and the share menu doesn't offer what you expected.
This is the moment worth understanding, because the answer isn't a bug report or a missing feature on a roadmap. It's a straight consequence of what makes the page good in the first place — and once you see the mechanism, you stop being surprised by it and start designing around it.
From Anthropic's own documentation:
"An artifact that calls connectors can't be shared to a public link on any plan. On Team and Enterprise plans, you can keep it private or share it within your organization. On Pro and Max plans, where a public link is the only way to share, a connector-backed artifact stays private to you."
Read the second sentence twice if you're on Pro or Max. Public sharing is the only sharing those plans have. So it isn't "you can share it, just not publicly" — it's you can't share it. The page you just built, that reads your live data and does real work, is a page only you will ever open.
On Team and Enterprise, you get one more step: you can share it with named people or with everyone in your organization, and they sign in to claude.ai as members to see it. That's a real audience — it's just an audience that ends at the edge of your company.
Either way, the outside world is not on the list.
The instinct is to file this under restrictions, next to rate limits and file caps. It isn't. It falls out of the mechanism, and the mechanism is the interesting part:
A connector-backed artifact isn't a file that reads data. It's a page that borrows the reader's keys.
When someone opens the page, the connector calls don't run as you. Per the docs, they run through the viewing account's own connection — claude.ai makes the call on the page's behalf, asks that viewer to approve it first, and never hands the page anyone's credentials. Two colleagues opening the same dashboard can see different numbers, because their accounts reach different things. If a viewer hasn't connected that tool, or declines the prompt, the page still renders — the live sections just come up empty.
That design is the right one, and you'd be angry if it were the other way. The alternative — the page carrying your access — means every link you send is a copy of your keys, and one forwarded URL is a data breach.
But follow it through. If the page's power comes from the reader's account, then a reader with no account has nothing to lend it. A public viewer isn't a limited case of a signed-in viewer; they're a viewer with an empty keyring. There is no version of that page that works for them. So it isn't blocked from public sharing by policy. It's uninhabitable there.
Which produces the thing actually worth taking away from all this:
Power and portability now move in opposite directions. The more your artifact reads, authorizes, and acts, the more tightly it is bound to the account it runs in. Every capability you add costs reach. The most impressive page you can build is the one you can hand to the fewest people — and the page you can hand to anyone is, by construction, the one that borrows nothing.
That's not a complaint. That's a fork in the road, and it now sits before your first prompt.
Once you've seen the fork, the practical consequence is that "make me a dashboard" is no longer a complete instruction. There are two dashboards.
The one that stays home. It reads live data, respects each viewer's permissions, and offers buttons that do things. Its audience is you, or your organization. Its whole value is the live connection, and that connection is exactly what nails it in place. This is a good thing to build. Just build it knowing it isn't leaving.
The one that travels. No connectors. The data is baked in at build time — a snapshot, ideally with a timestamp on the page so the reader knows what they're looking at. It loses freshness. It gains everyone: a client, an investor, a reviewer, your audience, anyone with a browser and no account anywhere.
The failure mode is picking accidentally. You build the first one because it's more fun to build, then two days later someone outside needs to see it — and stripping the connectors doesn't leave you a portable page, it leaves you a layout full of empty sections where the live data used to be. The structure was designed around a data source that no longer exists.
So decide first. It's a one-question decision — does this leave the building? — and it's cheap at the start and expensive later.
Building the one that travels? Export it as a self-contained HTML file and drop it here — you get a private link in under a minute. The person you send it to needs no account on Claude, or on anything else.
Nothing exotic here, and that's the point — a page that borrows nothing is a page with very few moving parts.
The general version of this — privately sharing a Claude or ChatGPT artifact with a client — is its own walkthrough, and the reasons an AI tool's own share link tends not to open for the person you sent it to covers the wider pattern this belongs to. Connectors are the sharpest instance of it, not a new species.
Plenty of the time, actually — and if this is your case, everything above is moot.
If what you want is a live internal tool — a status board your team opens Monday morning, a revenue view where each person sees their own accounts, a triage page with buttons that really move the tickets — then the artifact plus connectors is a genuinely strong shape, and moving it anywhere else makes it worse. You'd be rebuilding auth, permissions, and a data layer to recreate something you already have. The per-viewer permission model in particular is not a small thing to reproduce: the page showing different data to different people, correctly, without you writing a line of access-control code.
Stay. The constraint that bothered you — it can't leave the org — is not a constraint on this job. Nobody outside was ever going to open your deploy dashboard.
The honest boundary, named plainly: if you need live data and an outside audience, you've outgrown the artifact format — and you've outgrown a static page on a link, too. Don't let this post talk you into the wrong tool.
Outside users who log in, a database the page writes to, server-side routes, a webhook — that isn't a page, it's an application, and it needs a platform that runs your server. Vercel and Netlify are the right tools for that job and they're good at it. A private-link host doesn't replace them and shouldn't pretend to.
Anthropic draws the same line around its own format, and the phrasing is exact enough to steal:
"An artifact is a capture of work, not an application."
That sentence is doing real work. Most of what AI tools build for us is a capture — a report, a proposal, a demo, a snapshot dashboard, a prototype someone needs to look at and react to. Captures don't need backends. They need to open.
To be straight with you about the boundary in the other direction: a private link doesn't do connectors either. A page hosted at miinideck is a page on the open web — it can't reach into your Claude account, and it can't borrow your reader's. Nothing outside Anthropic's own product can, because the thing being borrowed is a claude.ai connection. If someone tells you their host will give you connector-backed artifacts on a public URL, they are describing something that doesn't exist.
What a private link owns is the other half — the page that travels. Self-contained HTML or a ZIP bundle, an unguessable URL, no account for the viewer, private and hidden from search by default. That's the half connectors were never going to cover, and the reason isn't competitive. It's that the moment a page becomes shareable to anyone, it can't be borrowing anyone's keys.
Same fork, seen from the other side.
Private, no-index links and password protection are free on every plan, along with one always-on link (free links otherwise default to a 7-day expiry, and the file cap is 10MB). Solo ($4.99/mo) makes links permanent, raises the cap to 25MB, and adds detailed analytics. Studio ($14.99/mo) goes to 50MB and adds a custom domain and white-label.
The update that let artifacts call connectors is a real step forward — it's the difference between a page that describes your work and a page that does it. Just notice what it quietly did to the word "artifact." It used to be one thing: the page you looked at was the page you sent. Now it's two, and only one of them travels.
Know which one you're building. That's the whole discipline.
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.
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.
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.