Claude lacks knowledge of claude.ai artifact sharing — gives incorrect alternatives instead

[BriennaErickson]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

"What's a good way for me to share this [artifact] with the leadership team? Can I just use the link I'm updating?"

What Claude Actually Did

1. Incorrectly stated the artifact URL was not a stable shareable link
2. Suggested unnecessary workarounds: SharePoint, emailing the file, Confluence, Jira
3. Only corrected itself after the user pointed out the share button on the artifact
4. When asked about org vs. personal artifact repositories, said it didn't know

Expected Behavior

Claude should have answered directly: "Yes — the share link on the artifact is stable. Anyone with it will see the latest version each time you republish."

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

1. Create an artifact in claude.ai/code
2. Ask "Can I share this with my team using the link?"
3. Claude redirects to file-based alternatives instead of confirming the share link works

Claude Model

Sonnet

Relevant Conversation

▎ User: "Can I just use the link I'm updating?"
▎ Claude: Suggested SharePoint, email, Confluence, Jira as alternatives
▎ User: "But I see a share link on the webpage"
▎ Claude: "You're right — there is a share button..." [corrected only after user prompted]

Impact

Low - Minor inconvenience

Claude Code Version

2.1.191 (Claude Code)

Platform

Anthropic API

Additional Context

No response

[matthewod11-stack]

Corroborating this from the other direction — same root cause (the model has no current knowledge of the post-training-cutoff Artifacts feature), but with a more severe failure mode worth adding:

In a build session (Claude Code 2.1.191, macOS) the model didn't just mis-advise on sharing — it reasoned from training and concluded Claude Code Artifacts were impossible / unavailable entirely, and only reversed after being made to read the live docs and actually test. The Artifacts feature shipped ~2026-06-19, after the Jan-2026 training cutoff, so the model has no reliable prior on it: left to training it will deny the feature exists, invent file-based workarounds (exactly your SharePoint / Confluence / email list), or say "I don't know" about org-vs-personal sharing.

A compounding factor that makes the wrong conclusion stick: the Artifact tool is genuinely absent from some sessions — headless claude -p, scheduled-task, and Agent-SDK runtimes, and even an interactive session loaded with a large MCP/skill surface (see #70254). So when the model checks its toolset and the tool really isn't there, it "confirms" the false belief that artifacts are off, rather than recognizing the tool is just gated by surface/cwd.

Net: the model needs current, authoritative knowledge of the Artifacts feature — the stable shareable URL, "always share latest version", org vs specific-people sharing, and the interactive-vs-headless availability split — so it answers directly instead of from a stale prior. We ended up writing a local runbook to stop our own agents from reasoning the feature out of existence; that shouldn't be necessary.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.