Table of Contents
- How Claude Code Artifacts Work
- Requirements: Plan and Environment Support Comparison
- Artifact Creation and Preview Workflow
- Environment Variables and Configuration Options
- CSP Constraints and Allowed Scope: What Works and What Doesn’t
- Live Updates and Version Control Structure
- DevOps Use Case Suitability Comparison
- Areas for Further Expansion
Sharing CI/CD pipeline build results by screenshotting terminal output and pasting it into Slack is inefficient. With Claude Code artifacts preview, session outputs can be published as live web pages that team members can view instantly in a browser. This article compares Artifact’s operating principles, plan-specific support, environment variable configuration, CSP constraints, and practical use cases.
How Claude Code Artifacts Work
An Artifact is a live interactive web page that publishes outputs from a Claude Code session to a private URL on claude.ai. It consists of HTML, CSS, and inline JavaScript, and the key feature is real-time updates as the session progresses. It can be previewed in a browser and shared with team members within the organization via the Share button in the page header.
When delivering code review results or dashboards to a team, the typical process involves committing markdown files or going through a separate hosting service. Artifacts eliminate this intermediate step. A request to Claude Code in the terminal converts the result directly into a web page.
For example, to visualize a PR diff with inline annotations, the following prompt works:
Make an artifact that walks through this PR with the diff annotated inline.This single line renders the PR’s changes as an HTML page, and team members can view it in a browser without installing any additional tools. While similar to a static site generator in that it produces a single self-contained HTML page, the difference is that it’s linked in real time with the Claude Code session.
An Artifact is a single HTML file composed entirely of HTML, CSS, and inline JavaScript with no external dependencies. It renders immediately in the browser without any build process or bundling.
Requirements: Plan and Environment Support Comparison
Before applying Claude Code artifacts preview, it’s essential to check plan and environment requirements. This feature isn’t available in all environments.
Artifacts are only available on Team or Enterprise plans and require a session authenticated to claude.ai via /login. They operate exclusively through the Anthropic API — Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry are not supported. Organizations with CMEK, HIPAA, or Zero Data Retention enabled will find the feature disabled.
| Condition | Supported | Notes |
|---|---|---|
| Team plan | ✅ Supported | /login authentication required |
| Enterprise plan | ✅ Supported | /login authentication required |
| Individual Pro plan | ❌ Not supported | As of 2026-06 |
| Anthropic API direct connection | ✅ Supported | Default operating environment |
| Amazon Bedrock | ❌ Not supported | Cloud provider routing not available |
| Google Cloud Vertex AI | ❌ Not supported | Cloud provider routing not available |
| Microsoft Foundry | ❌ Not supported | Cloud provider routing not available |
| CMEK-enabled org | ❌ Disabled | Security policy conflict |
| HIPAA-enabled org | ❌ Disabled | Regulatory compliance constraint |
| Zero Data Retention org | ❌ Disabled | Data storage not permitted |
In DevOps environments, this table matters because Artifact availability depends on the connection path when invoking Claude Code from infrastructure automation pipelines. Organizations using Claude through Bedrock or Vertex AI will need to exclude Artifacts from their current options.
Organizations handling medical data or using customer-managed encryption keys will find Artifacts automatically disabled. There’s no way to force-enable the feature through configuration — changes to the organization’s security policy must come first.
Artifact Creation and Preview Workflow
Artifact creation starts with a natural language prompt within a Claude Code session. During creation, Claude Code requests publish permission — once approved, a URL is output and the browser opens automatically.
Create → Approve → Preview Flow
In step 1, request Claude Code to create an Artifact. A prompt like “Create an artifact that visualizes this PR’s diff” is sufficient. In step 2, Claude Code displays a prompt requesting publish permission. Upon approval, a private URL under the claude.ai domain is generated. In step 3, the browser opens automatically and live preview begins.
This auto-open behavior can be problematic in CI environments. On a headless server, attempting to open a browser may throw errors or spawn meaningless processes. Environment variables can control this auto-open behavior in such cases.
Reopening an Artifact from the Terminal
To re-check an Artifact while working on something else during a session, press Ctrl+] to reopen the most recent artifact. It’s a shortcut for quickly switching to the preview without leaving the terminal.
When running Claude Code in CI environments like Jenkins or GitHub Actions, set
CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 to disable automatic browser opening, and forward the output URL via a Slack webhook instead.
Environment Variables and Configuration Options
The aspect of Claude Code artifacts preview that varies by operating environment is environment variable configuration. Different settings are appropriate for automation pipelines, local development, and feature disabling scenarios.
CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0
# or in the settings file
"disableArtifact": true
# or as an environment variable
CLAUDE_CODE_DISABLE_ARTIFACT=1These three settings differ in their scope of effect:
| Setting | Method | Effect | Use Case |
|---|---|---|---|
CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 | Env variable | Disables browser auto-open only; Artifact creation remains active | CI/CD headless servers |
disableArtifact: true | Settings file | Disables Artifact feature entirely | When publish must be blocked by security policy |
CLAUDE_CODE_DISABLE_ARTIFACT=1 | Env variable | Disables Artifact feature entirely | Docker containers and environments with limited settings file access |
CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 and CLAUDE_CODE_DISABLE_ARTIFACT=1 have entirely different scopes. The former allows creation but doesn’t open the browser, while the latter turns off the feature completely. To auto-forward Artifact URLs to Slack or Jira in a CI pipeline, the former is the right choice. With the latter, no URL is generated at all.
The settings file’s disableArtifact: true and the environment variable CLAUDE_CODE_DISABLE_ARTIFACT=1 produce the same effect but differ in how they’re applied. The settings file can be placed in .claude/settings.json at the project level to apply across the entire team, while the environment variable is advantageous for targeting specific execution contexts. When per-container control is needed via a Dockerfile’s ENV directive, the environment variable approach may be more suitable.
Environment-Specific Automation Patterns
When operating Claude Code across multiple pipelines in a DevOps environment, manually managing Artifact-related settings can easily lead to inconsistencies. Environment-specific configuration should be codified based on three criteria.
In local development environments, keeping the default settings (auto-open enabled) is most productive. In CI/CD environments, disabling only auto-open with CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 and including the generated URL in the pipeline output is efficient. In environments where security policy requires blocking publishing entirely, CLAUDE_CODE_DISABLE_ARTIFACT=1 is the appropriate choice.
# CI/CD pipeline example: GitHub Actions
# Generate Artifact URL only, don't open browser
CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0# Security-sensitive environment: Disable Artifact feature entirely
CLAUDE_CODE_DISABLE_ARTIFACT=1Managing these settings through .env files or CI secrets enables declarative control over Artifact behavior per environment. Injecting these environment variables when provisioning infrastructure with Terraform or Ansible is also a pattern worth considering. The complete list of environment variable and settings file options is available in the Claude Code Artifacts creation and configuration guide.
CSP Constraints and Allowed Scope: What Works and What Doesn’t
The key factor determining Artifact’s usable scope is the CSP (Content Security Policy) specified in the Claude Code Artifacts security and constraints documentation. Attempting to build complex dashboards without understanding these constraints is a common cause of failure.
Artifacts are single self-contained HTML pages with strict CSP enforcement. External scripts, stylesheets, fonts, and image loading are blocked, and fetch/XHR/WebSocket calls are also prohibited. Publishable file formats are limited to .html, .htm, and .md, and the rendered page size must be under 16 MiB. With no backend, form data storage, API calls, and multi-route serving are impossible.
Allowed vs. Blocked Items
| Item | Allowed | Details |
|---|---|---|
| Inline HTML/CSS | ✅ Yes | <style>, <div>, etc. within a single file |
| Inline JavaScript | ✅ Yes | Code within <script> tags |
| External CDN scripts | ❌ Blocked | <script src="https://cdn..."> not allowed |
| External stylesheets | ❌ Blocked | <link rel="stylesheet" href="..."> not allowed |
| Web font loading | ❌ Blocked | External fonts like Google Fonts not allowed |
| External images | ❌ Blocked | <img src="https://..."> not allowed |
| fetch/XHR calls | ❌ Blocked | REST API calls not allowed |
| WebSocket | ❌ Blocked | Real-time external data reception not allowed |
| Form data storage | ❌ No | No backend available |
| Multi-route | ❌ No | SPA routing limited to within the single page |
.html publishing | ✅ Yes | Default format |
.md publishing | ✅ Yes | Markdown also supported |
.json, .csv publishing | ❌ No | Outside supported formats |
| Pages exceeding 16 MiB | ❌ No | Rendered size limit |
The core of these constraints lies in the term “self-contained.” Since external libraries like Chart.js or D3.js can’t be loaded from a CDN, charts must be drawn directly using inline SVG or the Canvas API. CSS frameworks also require writing only the needed styles directly in an inline <style> block rather than pulling from Tailwind’s CDN.
When building a monitoring dashboard as an Artifact, pulling real-time data from Prometheus or Grafana APIs isn’t possible. Instead, include the data inline in the HTML at the time of Artifact creation, and request Claude Code to update it when the data changes.
From a DevOps perspective, these constraints clearly define Artifact’s role. It’s best used as a tool for visualizing and sharing point-in-time snapshots, not as a real-time monitoring solution.
Live Updates and Version Control Structure
When an Artifact is updated, it’s republished to the same URL, and all users with the link open see the update in real time. Each publish is managed as a version, and the Share controls allow selecting which version to share.
Update Workflow
To update an existing Artifact from a different session, provide the artifact URL to Claude:
Update https://claude.ai/code/artifact/5fbea6f3-... with today's numbers.This command refreshes the content at the existing URL with new data. Since the URL doesn’t change, links shared in Slack or Jira always point to the latest state.
Version Control and Sharing Scope
artifact v1 ──publish──▶ URL created
artifact v2 ──republish──▶ same URL updated
artifact v3 ──republish──▶ same URL updated
│
▼
Select v1 / v2 / v3
in Share controlsSharing scope is restricted to within the organization — external sharing is not possible. This limitation is an advantage for data leak prevention in Enterprise environments, but it also means a separate method is needed when results must be shown to external partners or clients.
| Sharing Method | Available | Description |
|---|---|---|
| Same-org team members | ✅ Yes | Direct sharing via Share button |
| Users in other orgs | ❌ No | Access blocked outside org boundary |
| Unauthenticated external users | ❌ No | claude.ai authentication required |
| Update from same session | ✅ Yes | Automatic republish |
| Update from different session | ✅ Yes | Artifact URL must be provided |
| Share specific version | ✅ Yes | Version selectable in Share controls |
DevOps Use Case Suitability Comparison
When applying Claude Code artifacts preview to DevOps workflows, criteria are needed to determine whether Artifacts are suitable for each scenario. Given CSP constraints and the internal-only sharing limitation, this isn’t a one-size-fits-all tool.
Suitable Scenarios
PR review visualization is a prime use case. Rendering diffs as HTML with inline annotations can make it easier to grasp context than GitHub’s default diff view. No external API calls are needed, and visualizing static data (code changes) doesn’t trigger CSP restrictions.
Deployment reports are also a good fit. Organizing a specific deployment’s changes, affected services, and rollback procedures into a single HTML page simplifies team-internal sharing. Since data is finalized at deployment time, real-time API calls aren’t necessary.
Incident timelines are another strong use case. A visually organized postmortem page covering the timeline from incident occurrence to recovery can be created. However, this works for completed incidents — it’s not suitable for real-time tracking of ongoing incidents.
Unsuitable Scenarios
Real-time monitoring dashboards exceed Artifact’s limitations. Periodically fetching Prometheus metrics requires network calls that CSP blocks. Dedicated tools like Grafana or Datadog remain irreplaceable in this domain.
External client-facing reports are also a poor fit. Since sharing scope is limited to within the organization, delivering results to external stakeholders requires downloading the HTML and hosting it separately.
| Scenario | Artifact Suitability | Reason |
|---|---|---|
| PR diff visualization | ✅ High | Static data, no external calls needed |
| Deployment reports | ✅ High | Point-in-time data, internal team sharing |
| Incident postmortem | ✅ High | Completed event documentation |
| Code quality reports | ✅ Medium | Watch for 16 MiB limit depending on data volume |
| Real-time monitoring | ❌ Low | fetch/WebSocket blocked |
| External client reports | ❌ Low | Internal sharing only |
| Multi-page documentation | ❌ Low | Single HTML page limitation |
Rendering examples for specific content types like React components and Mermaid diagrams are not yet documented in the official docs. The exact release version number for the Artifact feature has not been reflected in the CHANGELOG either. Specific figures for token cost optimization (token consumption ratio of artifacts versus plain text) are also not stated in the official documentation.
Areas for Further Expansion
Once the basic workflow for creating Claude Code live previews with Artifacts becomes familiar, expanding toward building Claude Code dashboards is a natural next step. The pattern involves consolidating deployment history, service health check results, and code coverage trends into a single Artifact for use as an internal team dashboard. Implementing tab switching or filtering functionality with inline JavaScript can accommodate a substantial amount of information within the 16 MiB limit.
From a Claude Code session sharing perspective, leveraging Artifact’s version control feature enables periodic updates to the same analysis while tracking changes over time. Republishing security scan results to the same Artifact URL every Monday means team members can always check the latest results from a single bookmarked link. Fine-tuning the Claude Code artifact disable options and auto-open controls per environment enables consistent application of Claude Code artifacts preview across the entire pipeline. Once this pattern is established, combining MCP server integration or Claude Code’s Tool Use feature with the Artifact creation workflow is another direction worth exploring.