[BUG] Artifact tool not loaded in claude -p even with enableArtifact: true in user settings
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The Artifact tool is never loaded in print mode (claude -p), even with "enableArtifact": true in user settings (~/.claude/settings.json). This makes it impossible to republish an existing artifact from a script or cron job.
The docs (https://code.claude.com/docs/en/artifacts#availability) say Artifact is "Off by default in Agent SDK, GitHub Action, and MCP-server contexts", but the enableArtifact setting description (https://code.claude.com/docs/en/settings) says it enables the tool "for this user" and only lists managed disableArtifact and org admin settings as overrides — it does not mention being ignored in SDK/print context. Either enableArtifact should take effect in -p, or its documentation should state the limitation and there should be some supported way to enable Artifact for headless runs.
Artifact works fine in interactive sessions on the same machine and account.
What Should Happen?
Either enableArtifact: true (user scope) loads the Artifact tool in -p, or a documented flag exists to enable it in SDK contexts.
With "enableArtifact": true in ~/.claude/settings.json, the Artifact tool should be available in claude -p, so a prompt like claude -p "Update https://claude.ai/code/artifact/<id> with fresh data" republishes the existing artifact to the same URL — same behavior as an interactive session.
Alternatively, if enabling Artifact in SDK contexts is intentionally unsupported, the enableArtifact docs should say so explicitly and an enablement mechanism (flag or setting) should be provided for headless automation.
Error Messages/Logs
Prompting an artifact update in -p returns the literal error:
"Artifact exists but is not enabled in this context"
The `tools` array from the init event (`--output-format stream-json --verbose`) does not include "Artifact":
["Task","Bash","CronCreate","CronDelete","CronList","DesignSync","Edit","EnterWorktree","ExitWorktree","ListMcpResourcesTool","Monitor","NotebookEdit","PushNotification","Read","ReadMcpResourceDirTool","ReadMcpResourceTool","RemoteTrigger","ReportFindings","ScheduleWakeup","SendMessage","Skill","TaskCreate","TaskGet","TaskList","TaskOutput","TaskStop","TaskUpdate","ToolSearch","WebFetch","WebSearch","Workflow","Write", ...mcp tools...]
Steps to Reproduce
- Linux server, Claude Code v2.1.215, logged in with a claude.ai Max account via
/login(OAuth;apiKeySource: none). No managed settings, noCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, nodisableArtifactanywhere. - Create an artifact from an interactive session (works fine) and note its URL.
- Add
"enableArtifact": trueto~/.claude/settings.json. - Verify that user settings ARE loaded in
-p: add"model": "claude-haiku-4-5"to the same file and runclaude -p 'x' --output-format stream-json --verbose— the init event reports the haiku model, proving the file is read. Remove the key again. - Run:
claude -p 'hola' --output-format stream-json --verboseand inspect thetoolsarray in the init event → "Artifact" is absent. - Run:
claude -p 'Update https://claude.ai/code/artifact/<id> with a test line' --allowedTools "Artifact"→ model replies it has no artifact tool; in earlier runs it returned "Artifact exists but is not enabled in this context". - Also tried
--settings ~/.claude/settings.jsonexplicitly → same result.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.215
Platform
Other
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Use case: a cron job that republishes an existing artifact (fixed URL shared with the team) with fresh data daily. Currently the only workaround is driving an interactive session via tmux send-keys, which is fragile for automation.
~/.claude/settings.json at time of testing:
{
"permissions": {
"allow": ["mcp__ops-mcp", "mcp__ads-mcp-staging"],
"ask": ["mcp__ops-mcp__deploy_production", "mcp__ops-mcp__detener_servicio"]
},
"theme": "dark",
"remoteControlAtStartup": true,
"agentPushNotifEnabled": true,
"skipWorkflowUsageWarning": true,
"enableArtifact": true
}
3 Comments
Still happening in the new version.
Independent confirmation, still reproducing on a newer version — this is a real production blocker, not a one-off.
Setup: Debian 13 VM, Claude Code v2.1.221,
apiKeySource: none(OAuth login, same as OP). A cron job runsclaude -p --permission-mode bypassPermissions --output-format text "<prompt>"every 30 minutes to rebuild and republish 3 existing artifacts (fixed URLs) with fresh data — essentially the exact use case described here.Confirmed the same absence, but via a slightly different angle than the OP's
stream-jsoninit-event check: I asked a freshclaude -psession to runToolSearch(the deferred-tool lookup mechanism) for "Artifact" directly. It returned "No matching deferred tools found" — the tool isn't just filtered from the advertised list, it's unreachable even by explicit name-search from inside the session itself.Ruled out permissions/config as the cause on our end too:
Artifactis already explicitly present in~/.claude/settings.local.json'spermissions.allowarray (added when this was first set up, well before the failures started) — same conclusion as OP'senableArtifact: truetest, just via the allow-list route instead of the enable-flag route. Neither mechanism does anything for-p.Scale/persistence data point that might help prioritization: this has now failed on 38 consecutive scheduled runs across 8 days (first hit 2026-07-28, still failing as of 2026-08-04) with zero self-resolution. Each run correctly rebuilds the target HTML, detects it has no Artifact tool, and — per its own fail-safe logic — skips publishing and leaves state uncommitted so the next run retries cleanly. So it's not silently corrupting anything, but it also means this specific cron-republish pattern (the one flagged as the motivating use case in the original report) is completely non-functional and has been for over a week, with automated retries providing no signal that anything will change without a code/doc fix.
What we're doing in the meantime, for anyone else hitting this: falling back to running the same rebuild+publish manually from an interactive Claude Code session on the same host (confirmed the Artifact tool works fine there, same account, same machine) — which works, but obviously isn't automatable, and defeats the point of having a cron pipeline at all.
+1 on the original ask: either make
enableArtifact/an equivalent allow-list actually take effect in-p/SDK contexts, or explicitly document that headless artifact publishing is unsupported so people don't build (and silently break) automation around it.Really need this to be resolve, the artifact is not in the Headless Claude Tool list. without reach this tool. every pipeline that we intergate with Artifact is un-doable by using claude -p.