Can you share a Claude artifact that uses connectors? (2026)

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.

The short answer

From the claude.ai help page on sharing artifacts, checked 9 November 2026:

"An artifact that pulls from connected apps uses the viewer's connections, not yours."

The same page says that if a viewer can't access a data source, that part of the artifact shows an error instead of your data. Until recently it also said artifacts that connect to your apps couldn't use "Anyone with the link" at all; that line is gone. The artifacts it now keeps off public links are the ones that connect to other websites, or carry an uploaded file still being checked. On Pro and Max you can also invite specific people by email; on Team and Enterprise you can share with named people or everyone in your organization.

Anthropic's Claude Code documentation covers pages published from Claude Code, and it reads differently: you can share a connector-backed page publicly where your plan and organization allow, but "connector calls don't run for a viewer who opens the public link without signing in to claude.ai, or from outside your organization. That viewer sees the page without its live sections."

Both pages now land in the same place, and it's the part that matters: the live data only reaches someone with their own Claude account and their own connection. A client with no Claude account gets, at best, the page with its live sections empty. The outside world is not on the list.

Why it works that way — the part worth keeping

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.

Two pages, and you pick one before you start

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.

The page that travels: what to actually do

Nothing exotic here, and that's the point — a page that borrows nothing is a page with very few moving parts.

1. Ask for a snapshot, not a fetch. Prompt Claude to pull the numbers now and write them into the page, rather than calling the connector at load time. Ask it to print the "data as of" date somewhere visible; a snapshot that doesn't admit it's a snapshot is how someone quotes a stale figure in a meeting.
2. Ask for one self-contained file. CSS and JavaScript inline, images embedded. Claude is already doing this inside its own format — its artifacts run under a strict policy that blocks almost every external request, so it inlines by default — and you want that same discipline in the file you export. The export checklist covers what usually leaks, and inlining CSS and JavaScript covers the mechanics if you're doing it by hand.
3. Put the file on a link. Drop the HTML — or a ZIP bundle if it's grown into multiple files — at a private-link host. You get back an unguessable URL that's hidden from search by default. The recipient opens it in a browser and that's the whole interaction: no account, no install, no "sign in to view." If the work is sensitive, add a password; if it shouldn't outlive the review, set an expiry.

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.

When staying inside Claude is the right answer

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.

When you need a real backend instead

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: one self-contained page with no backend."

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.

What this isn't

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.

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.