Claude Code Artifacts: Ship a Coding Session as a Page

Claude Code Artifacts, launched in beta by Anthropic on June 18, 2026, turn a coding session into a private, live, shareable HTML page on a claude.ai URL — a way for an engineer to hand a teammate the output of agentic work as something you open in a browser rather than something you describe in a status update.

What makes this different from the chat Artifacts Anthropic shipped back in 2024 is grounding: a Claude Code artifact is built from your actual development session — the local repository, connected tools via MCP, and the conversation that produced the work. And what makes it different from a deploy is the deliberate absence of one. There is no backend. A strict Content Security Policy blocks every external network request. Anthropic states the design plainly: an artifact is a capture of work, not an application.

This guide covers what actually launched, how an artifact is assembled from the session, why Anthropic chose a stateless canvas over a hosting platform, how that contrasts with OpenAI Codex Sites, the plan and admin constraints engineering managers need to know, a role-based decision tree for when to use an artifact versus when to deploy a real app, and the unresolved trust question that sits underneath the whole feature.

On June 18, 2026, Anthropic launched Claude Code Artifacts in beta for Team and Enterprise subscribers, on both the Claude Code CLI and the desktop app (version 1.13576.0 or later). An artifact is a single, self-contained interactive HTML page published from a Claude Code session to a private URL on claude.ai. It renders in any browser and updates in place as the session continues.

The interaction is plain language. You ask Claude for one — for example, “Make an artifact that walks through this PR with the diff annotated inline” — and Claude can also publish one automatically when its output suits a page. Before publishing a new artifact, Claude Code asks for permission. From the terminal, pressing Ctrl+] reopens the most recent artifact. Accepted source file types are .html, .htm, and .md; Markdown renders as styled HTML inside the artifact shell.

The live-update behavior is the part that replaces the status update. When Claude Code produces a new iteration, the open page refreshes in place and holds the viewer’s scroll position. Every publish creates a new version at the same URL, and users can restore any prior version from the Share control — so a teammate watching the link sees the work evolve without you re-sending anything. If you are new to the surface this builds on, our Claude Code 1.3 feature deep dive covers the subagents, skills, and hooks that power session context.

The thing that separates a Claude Code artifact from a generic AI-generated HTML page is its inputs. According to coverage of the launch, an artifact is built from three session sources: the local repository codebase, connected tools or plugins via MCP, and the conversation history that produced the work. Engineers do not need to wire up external data sources or stand up infrastructure — the material already exists inside the session.

This is also the cleanest line between the two things called “artifacts.” The chat Artifacts Anthropic introduced in claude.ai are conversational outputs. Claude Code Artifacts are grounded in the actual development session context — live codebases, connected MCP tools, terminal output — rather than conversation-space content without active codebase coupling. The practical effect is that a Claude Code artifact can reflect the real state of your repo, not just what was typed into a chat box. For how those tool connections work, see our guide to MCP Apps and interactive UI in Claude.

Claude also applies a built-in design skill when it builds an artifact, looking first for an existing design system in the project’s CLAUDE.md or theme file. If design tokens — colors, typography, spacing — are recorded there, Claude treats them as higher precedence than its own defaults. For teams that have invested in a documented design system, that means shared pages can come out on-brand without extra prompting.

Artifacts can also be updated across sessions — but only if you give Claude the artifact’s URL. Without it, a new session always creates a new artifact rather than updating the existing one, which is worth knowing before you accidentally fork your own dashboard. The docs also describe a lightweight “editor” pattern where an artifact feeds back into the session: a triage board with draggable cards and a “Copy as prompt” button lets the result of interacting with the page flow back as a terminal prompt.

Most coverage leads with “you can share a live page.” The sharper story is what Anthropic chose not to build. A strict Content Security Policy blocks all external network requests: no external scripts, fonts, stylesheets, or images from other hosts, and fetch, XHR, and WebSocket calls are completely blocked. All CSS and JavaScript is inlined; images are embedded as data URIs. The page is sealed.

That seal is the feature. With no outbound calls, an artifact cannot exfiltrate data, cannot pull in a compromised third-party script, and cannot quietly phone home — a meaningfully smaller attack surface for a page that is going to circulate inside an enterprise. The trade-off is everything a normal web app does at runtime. Anthropic spells it out: an artifact has no backend, cannot store form input, cannot call an API at view time, and cannot serve multiple routes.

This is the original analysis worth sitting with. The decision is not a limitation Anthropic is racing to remove — it reads as a positioning choice. A sealed, org-scoped review canvas fits an enterprise security posture in a way a self-hosted app surface never could. The cost is that artifacts will never be the place you ship a product; the benefit is that they can be the place you safely circulate sensitive work. Anthropic resolved that tension by picking a side and saying so out loud.

The launch competes most directly with OpenAI Codex Sites, released roughly two weeks earlier. The two products take opposite architectural philosophies, and the contrast is the clearest way to understand what each is for. Per OpenAI’s own Codex Sites documentation, Codex Sites hosts projects that build Cloudflare Worker-compatible output as ES modules, with D1 — a relational database for durable structured data — and R2 object storage for files, plus workspace-authenticated user identity and public sign-in or an external identity provider. It is, in short, a place to host a persistent app.

Claude Code Artifacts is the inverse: a stateless canvas with no backend, no database, no object storage, and no public sign-in. The table below breaks the two out by architectural property — a side-by-side that, as of this writing, no other published comparison assembles. Cells are drawn from the official Claude Code docs and OpenAI’s Codex Sites documentation.

Read the table as two answers to two questions. If the question is “where does my team inspect and trust an agent’s work,” the stateless review canvas is the cleaner fit. If the question is “where do I host the thing my customers use,” the persistent platform is. They are not really substitutes — which is why a team can reasonably end up using both. For a broader look at how these agents stack up, see our comparison of comparing Claude Code and Codex as coding agents.

Availability is narrower than the headlines suggest, and the details matter for anyone planning a rollout. Artifacts are available on Team and Enterprise plans only. On Team plans they are enabled by default; on Enterprise plans an administrator must enable the feature under Settings > Claude Code > Capabilities before any user can publish. There is no Free or Pro access at beta.

There is also an authentication constraint that catches teams off guard: artifacts require direct Anthropic API authentication. Sessions using an API key, a gateway token, or a cloud-provider credential — Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Foundry — cannot publish artifacts. If your organization runs Claude Code through a cloud provider, this feature is, for now, off the table on that path.

Access is private by default. Every artifact is visible only to its author until manually shared, and sharing is limited to authenticated members of the same organization — there is no option to make an artifact publicly viewable on the internet. Artifacts are served from *.claudeusercontent.com, so organizations with restricted outbound network access must add that sandboxed origin to their allowlist alongside claude.ai.

Anthropic lists use cases in its docs but does not provide a role-based decision tree, and the most common question the feature raises — “is this the right tool, or do I need a real app?” — goes unanswered. The table below maps roles to a recommended artifact, an example prompt to trigger it, and the line where you should reach for a deploy instead. Use it as a starting heuristic, not a rule: the deciding factor is almost always whether anything needs to persist, authenticate beyond your org, or call an API at view time.

Here is the part the marketing pitch skips. The contested layer in AI coding tools, as analysts describe it, is moving from code generation to the surface where teams inspect and trust an agent’s work. A governed, org-scoped record of the session — with access controls and retention — makes that visibility deployable inside an enterprise. That is genuinely the right framing for why artifacts matter: the value is not the page, it is the trustworthy record.

But a record that looks authoritative is not the same as a record that is correct. As Mitch Ashley of The Futurum Group has argued, a live page that reads as authoritative still has to earn it through review, or it scales the very trust-without-verification it appears to resolve. A beautifully rendered dashboard generated by an agent can be confidently wrong, and the polish makes the error easier to miss, not harder.

The forward-looking read is that artifacts shift where the review burden lands rather than removing it. They make agentic work easy to circulate, which is exactly why the discipline around verifying that work has to scale with it. Teams that treat a shared artifact as a prompt for review — not as a settled answer — will get the upside. Teams that treat the polish as proof will quietly accumulate confident mistakes. The feature is a real step forward for visibility; it does not, on its own, close the verification gap it makes more visible.

One implication nobody else in the launch coverage flags: artifacts generate output tokens like any other response, and a styled page with inline CSS, JavaScript, and data-URI images is more token-intensive than plain terminal text. For an engineering manager tracking usage, the upgrade from a terminal summary to a polished shared page is not free — it is a real, if modest, shift in output volume per response.

Anthropic does not publish a token cost per artifact, and it would be a mistake to invent one — the right way to think about it is relative, not absolute. The docs do offer optimization guidance: prefer SVG or HTML/CSS for diagrams over embedded raster images, omit interactivity you do not need, and have the page summarize large datasets rather than inlining them. Each of those choices trims the output the model has to generate.

The practical takeaway for budget owners is to be intentional about when a page is worth the tokens. A diff walkthrough that saves four async back-and-forths is plainly worth it; auto-publishing a styled page for every routine result is not. If you are sizing AI usage across a team and want help turning that into a cost model, our AI digital transformation engagements start with exactly this kind of usage-and-spend analysis, and our custom web development work covers when a page should graduate from an artifact to a real deploy.