Claude Code · How-To

Claude Code Artifacts

The disableArtifact setting in a settings.json file, the one-line switch that turns off Claude Code artifacts
The fix, up front
  • To turn artifacts off entirely, add "disableArtifact": true to your ~/.claude/settings.json and restart. Same effect from the env var CLAUDE_CODE_DISABLE_ARTIFACT=1, or by adding Artifact to permissions.deny.
  • To keep the feature but stop the browser popping open every time a page is published, set CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 in the env block.
  • Artifacts are private to you by default. On Pro and Max there's no sharing at all; on Team and Enterprise you can share within your org, never publicly.
  • It only works when you're signed in with /login on a paid plan against Anthropic's own API. On an API key, Bedrock, or Vertex, it's already off.

If you want to disable Claude Code artifacts and skip the story, here's the whole thing. Open ~/.claude/settings.json and add one line at the top level:

{
  "disableArtifact": true
}

Restart Claude Code, and it will stop publishing pages entirely, falling back to writing a plain local HTML file when it wants to show you something visual. That's the blunt off switch. The rest of this page covers the softer knobs, how to confirm which one you need, and why the whole thing isn't in the changelog.

What an artifact actually is

On June 18, 2026 Anthropic added artifacts to Claude Code. An artifact is a self-contained web page, HTML or Markdown, that Claude Code writes into your project and then publishes to a private URL on claude.ai. You open it in the browser and it updates in place as the session keeps working. It's meant for the output that reads better as a page than as a wall of terminal text: an annotated PR walkthrough, a dashboard, a set of options side by side. The official write-up is the artifacts documentation.

The reason people go looking for the off switch is the auto-publish behavior. The docs put it plainly: Claude "may publish an artifact on its own when the output suits a page." When it does that unprompted, the URL carries a tell, a ?via=auto_preview query string. The IDs are real, so here's the shape rather than a live one:

https://claude.ai/code/artifact/<artifact-id>?via=auto_preview

The first time Claude wants to publish, it asks: "Claude wants to publish … to a private page on claude.ai." Approve it once and republishing the same artifact won't prompt again. It just updates the same URL, and unless you tell it otherwise, pops the browser open each time. That last part is what most people actually want to stop.

The four knobs

There's no toggle in the UI and nothing in --help. The controls are a settings flag, two environment variables, and a permission rule.

ControlWhereWhat it does
disableArtifact: true settings.json (top level) Switches artifacts off for your sessions entirely.
CLAUDE_CODE_DISABLE_ARTIFACT=1 env Same as above, as an environment variable.
Artifact permissions.deny Denies the publish tool via the permission system.
CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 env Keeps artifacts, but stops the browser opening on each publish.

Just stop the popup, keep the feature

This is the setting most people want. Artifacts stay available when you ask for one, but Claude stops hijacking your browser every time it republishes. In the env block of ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_ARTIFACT_AUTO_OPEN": "0"
  }
}

Claude still prints the URL, so you can open the latest one yourself whenever you want. From the terminal, Ctrl+] reopens the most recent artifact on demand.

Turn it off completely

Any one of these three is enough. The settings flag is the cleanest:

// ~/.claude/settings.json
{
  "disableArtifact": true
}

If you prefer an environment variable, handy in launcher scripts for headless or delegated runs, use this instead:

export CLAUDE_CODE_DISABLE_ARTIFACT=1

And if you already manage tool access through the permission system, deny it there:

// ~/.claude/settings.json
{
  "permissions": {
    "deny": ["Artifact"]
  }
}

You don't need all three. Pick the one that matches how you already configure Claude Code. With any of them set, when Claude wants to show you something visual it writes a local HTML file and hands you the path instead of publishing.

Setting this per-project? Put the block in the repo's .claude/settings.json instead of your home one. Useful when you want artifacts on for your own interactive work but off inside a client repo you'd rather nothing left, even to a private page.

How I found the knobs (run this yourself)

I went looking in the obvious place first, the changelog, and came up empty. I read every entry from 2.1.198 through 2.1.202. Not one mention of artifacts, publishing, or claude.ai/code. That's not an oversight. Artifacts is gated by your account (plan, login, org policy), not shipped as a versioned CLI feature, so it lands via the blog and the docs rather than a release note.

The CLI side is still in the binary, though, and you can see it. The variable names are plain strings inside the installed build:

# Point this at your installed version (mine is 2.1.202)
V=~/.local/share/claude/versions/2.1.202

strings "$V" | grep -E 'CLAUDE_CODE_(DISABLE_ARTIFACT|ARTIFACT_AUTO_OPEN)'
strings "$V" | grep -E 'code/artifact|auto_preview'

Both grep hits come back non-empty. The auto_preview marker from those unprompted URLs is right there in the binary too. And when I checked the older builds still on my machine, the same strings were present as far back as 2.1.196. The CLI plumbing shipped weeks before the June 18 announcement flipped it on server-side. That's the tell for an account-gated feature: the client code arrives quietly ahead of time and waits for the switch.

Confirm your change took

Two checks. First, that your build even has the feature. If the grep above prints nothing, your version predates it and there's nothing to disable. Second, that your override reached the session:

# Did the env override reach the shell Claude Code runs in?
echo "$CLAUDE_CODE_ARTIFACT_AUTO_OPEN"
echo "$CLAUDE_CODE_DISABLE_ARTIFACT"

A value set in settings.json only shows up in sessions Claude Code started after you saved the file, so if these echo blank, restart. The simplest end-to-end test: ask Claude to "make an artifact of anything." With it disabled, it writes a local .html file and gives you the path instead of a claude.ai link and a permission prompt.

Where your artifacts actually live

Worth knowing before you decide whether to leave it on. A published artifact is private to you by default. On Pro and Max plans it stays private, full stop. There's no share button. On Team and Enterprise you can share a page with specific people or everyone in your organization, but there is no option to make one public; viewers have to be signed into the same org. The pages are served from a sandboxed *.claudeusercontent.com origin, hosted on Anthropic's infrastructure, and every publish, share, and delete is written to your org's audit log.

So it's not "your code leaked to the web." But it is content leaving your machine to Anthropic-hosted storage, which is exactly why some setups want it off. If your org runs Zero Data Retention, HIPAA, or customer-managed keys, artifacts are already disabled for you and there's nothing to change.

You might not even have it

Before you spend time disabling something, check that it's on. Artifacts require every one of these. Miss any, and Claude just writes a local file instead of publishing:

RequirementNeeds
PlanPro, Max, Team, or Enterprise
AuthSigned in with /login, not an API key, gateway token, or cloud credential
ProviderAnthropic API, not Bedrock, Vertex AI, or Foundry
SurfaceCLI or desktop v1.13576.0+; off by default in the Agent SDK, GitHub Action, and MCP contexts

If you drive Claude Code through an API key or a cloud provider, this whole page is moot. You never had artifacts to begin with.

Why you might leave it on

The auto-open is the annoying part, and CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 fixes that without throwing away the feature. When Claude produces something genuinely visual, like a diff walkthrough, a comparison of three implementations, or a live checklist during a long migration, a page really is the better medium than scrollback. My own take: kill the popup, keep the capability, and reach for the full disableArtifact only in repos where you want nothing published at all.

Common questions

Do I need to restart Claude Code?

For the env vars and settings.json, yes. They're read when a session starts, so a running session won't pick up the change. Save, quit, start fresh.

What's the difference between the auto-open off and the full disable?

CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0 keeps artifacts working. Claude can still publish when you ask; it just stops yanking your browser to the foreground. disableArtifact (or CLAUDE_CODE_DISABLE_ARTIFACT=1, or the deny rule) turns publishing off completely.

Does disabling it affect my teammates?

Only if you put it in a shared, checked-in .claude/settings.json. A value in your home ~/.claude/settings.json is yours alone. Org-wide control lives in the claude.ai admin settings, not in your local config.

It still published a page. What now?

Usual causes: the session was already running when you saved the change (restart it), or the setting didn't land where you think, so echo the variables as shown above. Since the feature is account-gated and undocumented at the CLI level, a future build could rename these; if that happens, re-run the strings grep to find the current names.