Claude Code Artifacts for Client Work: Send the Client a Link, Not a Wall of Text

What a Claude Code Artifact Is

An artifact is a live, interactive web page that Claude Code publishes from your session to a private URL on claude.ai. You ask for one in plain language, or Claude publishes one on its own when the output suits a page better than text: an annotated diff, a chart, a set of options side by side. Claude writes the page to an HTML or Markdown file, publishes it, and opens the link in your browser. When you ask for a change, it edits the file and publishes again to the same URL, and anyone with the page open sees the update in place.

For client work this solves a problem I used to handle badly. Most of what a client needs to see from a build is visual: what the intake flow looks like now, which of three layouts they prefer, where the project stands this week. I used to describe it in an email or paste screenshots into a thread. Now the session that did the work produces the page that shows the work, and I send one link. The [/design command](/blog/claude-code-design-command-for-client-work) is built on the same artifact system, so if you have used it, you have already used artifacts.

The requirements are specific. Artifacts need a Pro, Max, Team, or Enterprise plan and a session backed by a claude.ai account, which means signing in with /login in the desktop app or the CLI. Sessions that authenticate with an API key, a gateway token, or a cloud-provider credential cannot publish, and artifacts are not available on Amazon Bedrock, Google Cloud, or Microsoft Foundry. In the desktop app you need version 1.13576.0 or later. If Claude writes a local HTML file and gives you no link, one of those conditions is not met.

Who Can See a Client Artifact

This is the part to get right before the first one goes out. A new artifact is visible only to you. On Team and Enterprise plans you can share with specific people in your organization or with everyone in it, and those viewers sign in to see the page. On Pro and Max plans, a public link is the only way to share at all. Your client is not a member of your organization, so whatever plan you are on, the practical way to show a client an artifact is a public link, and a public link is one that anyone on the internet can open with no claude.ai sign-in.

That has three consequences for client work. First, there is no viewer login: an artifact is a static page with no backend, and it cannot authenticate the person looking at it. If the link is forwarded, the new reader sees what your client sees. Second, a viewer who opens a public link from outside your organization sees the label Content is user-generated and unverified instead of your name, so tell the client in the same message that the link is from you and what it shows. Third, the page itself lives on Anthropic's infrastructure, which means whatever goes into it has left your machine. That belongs in the [two-bucket conversation about client data](/blog/is-it-safe-to-use-claude-code-with-client-data) you have before the build starts, not after the first link is sent.

On Team and Enterprise plans public sharing is off until an Owner turns on External sharing under the Artifacts toggle in the admin settings, and turning it back off blocks access through existing public links. If you run a small agency on a Team plan, that switch is the kill switch for every client link at once. Know where it is before you need it.

The Pinned-or-Live Rule

Every publish of an artifact becomes a version, and the Share control lets you choose which version viewers see, or turn on Always share latest version. That one setting is the difference between a page that helps you and a page that starts an argument. The Profit Room's Pinned-or-Live Rule decides it by asking a single question: is the client approving this page, or watching it?

1. Approving means pinned. A scope summary, a comparison of three design directions, a walkthrough of what the build does at handoff: the client is going to say yes to what they see. Share a specific version, and reference it in the email or the agreement. If you later republish with changes, the client is still looking at the page they approved until you deliberately move them to the new version. This is the same discipline as a signed [one-page agreement](/blog/one-page-agreement-before-you-build): what they agreed to does not move.
2. Watching means live. A weekly status board, a checklist that fills in while a migration runs, a count of what the automation handled this month: the client wants the current state. Share with Always share latest version on, and let the page update as you work. This is what replaces the [weekly update email](/blog/weekly-client-update-prevents-fires) for many of my clients, or sits under it as the link at the bottom.
3. Never mix the two on one page. If a status board also contains the scope the client signed, a routine update can quietly change the scope they see. Split them: one pinned approval page per decision, one live status page per project.

One behavior to know when you run a live page. After you approve the first publish, Claude Code republishes an artifact without asking each time, but it asks again after you have shared it publicly. For a client-facing page that is the correct default: every update to a public page is a moment where you confirm what is going out. Do not route around it.

Three Artifacts I Use on Every Client Build

The docs list the common patterns: walk through a change, compare alternatives, tune with interactive controls, track work in progress. On client builds I use three of them, at three points in the project.

• The options page, before the build. When a decision has real alternatives, such as two ways to structure the booking flow or three homepage directions, I ask Claude for one artifact with each option laid out side by side and a one-line tradeoff under each. The client picks from something they can see. Pinned, because it is an approval.
• The status board, during the build. One page per project with what shipped, what is next, and what I need from the client, updated by the same session doing the work. For a long task I ask Claude to keep the checklist current as it goes. Live, because the client is watching.
• The walkthrough, at handoff. A page that shows each part of the delivered build, what it does, and how to use it, with the screenshots from the [Proof Pass in the browser](/blog/claude-code-browser-testing-for-client-work) embedded in it. It sits next to the [sign-off request](/blog/get-a-client-to-sign-off-on-a-build) as the thing being signed off on. Pinned.

Make them look like the client, not like a template. Claude applies a built-in design skill when it builds an artifact, but it gives your own design system higher precedence than its own choices. Put the client's colors, fonts, and spacing in the project's [CLAUDE.md](/blog/claude-md-file-for-client-projects) under a Design system heading, and every page for that client comes out in their brand without extra prompting. One practical note from the docs: the page's security policy blocks external images, so logos and screenshots are embedded directly into the page, and the rendered page has a 16 MiB limit. Large embedded images are the usual reason a publish fails.

Cost, Limits, and When Not to Use One

An artifact costs output tokens like any other response, and a styled page costs more than the same content as plain text. Inline CSS, interactive controls, and embedded images are the main contributors. The docs recommend SVG or HTML and CSS for diagrams instead of raster images, leaving out interactivity you do not need, and summarizing large datasets rather than inlining them. Those three habits are also what keep a client page readable.

Two limits matter for clients specifically. Comments on an artifact work only when it is shared within your organization on a Team or Enterprise plan; a public page shows Comments aren't available while this Artifact is shared publicly. So client feedback still comes back by email or call, and you paste it into the session. And an artifact that pulls live data through a claude.ai connector cannot be shared to a public link on any plan, which rules out a live client dashboard fed by connectors. For that, build the client a real dashboard they own, with the [MCP servers](/blog/mcp-servers-for-claude-code-client-work) and the permissions scoped to their project.

If a client project should never publish anything at all, for example because the client's policy forbids hosting their material on a third-party service, turn artifacts off for that folder: set enableArtifact to false in the project's .claude/settings.json. That requires Claude Code v2.1.242 or later, and it sits alongside the rest of your [per-client permission rules](/blog/claude-code-permissions-for-client-work). Write the decision into the agreement so both sides know where the work will and will not appear.