claude-code - 💡(How to fix) Fix [BUG] Cowork: Orphaned Artifact backing folder causes unrecoverable virtiofs mount error in all project sessions [3 comments, 3 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When a Claude Artifact is bound to a Cowork project, Cowork auto-mounts the artifact's backing folder from the host at ~/Documents/Claude/Artifacts/<artifact-id>/ into the session VM as .artifacts/<artifact-id>. This mount happens silently for every session in the project, regardless of which working folder the user selects.

If the backing folder is missing, moved, or renamed on the host, every session in that project fails to start with a virtiofs RPC error. The failure mode has several problems:

1. The error path misleads diagnosis. The error references ~/Documents/Claude/Artifacts/<artifact-id>, which looks like a working-folder configuration issue — but changing the selected working folder has no effect, because the failing mount is the artifact mount, not the working-folder mount.

2. There is no UI path to recover. The artifact's backing-folder path is derived from the artifact id, not editable anywhere in the Cowork UI. The only way for a non-technical user to recover is to reset the VM bundle, which destroys all Cowork session history across all projects — a massively disproportionate remedy.

3. The fallback mkdir surfaces a misleading secondary error. When the source path is missing, virtiofs tries to create the full path chain, but uses bare mkdir (not mkdir -p). The resulting error (mkdir /mnt/.virtiofs-root/shared/Users/<user>/Documents: file exists) strongly implies a host filesystem collision or OneDrive/iCloud FileProvider issue — sending users (and LLM assistants helping them diagnose) down a completely wrong rabbit hole.

What Should Happen?

Expected Behavior

One of the following:

• Graceful degradation (preferred): If the artifact's backing folder is missing at session start, log a warning and skip the artifact mount. Session continues with working-folder mount only. Optionally surface a non-blocking UI notice ("Artifact X backing folder missing — recreate it from host to re-enable").
• Auto-repair: If the backing folder is missing, create it (empty) at session start. Artifacts that had content can be restored by the user; artifacts that were never populated lose nothing.
• Clear error message: At minimum, the error should say "Artifact 'NAME' backing folder missing at 'PATH' " so users understand what to fix. The current message implies a filesystem conflict that doesn't exist.

Current User Workarounds (neither is discoverable)

1. Recreate the backing folder: mkdir -p ~/Documents/Claude/Artifacts/<artifact-id> — requires knowing the artifact id.
2. Edit the project's artifacts.json at ~/Library/Application Support/Claude/local-agent-mode-sessions/<session-group-id>/<project-id>/artifacts.json to remove the artifact binding — requires knowing this file exists and accepting loss of the artifact's metadata wrapper.

Neither is possible from the Cowork UI. Both require terminal usage and knowledge of undocumented internal paths.

Why This Is High-Impact

• Affects any user who reorganizes their ~/Documents folder, uses file-sync tools that relocate folders, or experiences any host-side filesystem event affecting ~/Documents/Claude/Artifacts/.
• Existing GitHub issues (#42795, #24134, #29914) attribute similar-looking errors to OneDrive/iCloud/case-sensitivity issues, but the artifact-binding root cause explains a subset of these cases that persist after ruling out those causes — meaning users may be chasing the wrong fix.
• The only documented recovery (VM bundle deletion) is dramatically destructive: it nukes all Cowork history across all projects. This is an enormous user cost for what is fundamentally a stale-reference problem.

Suggested Additional Fixes

• Document the ~/Documents/Claude/Artifacts/<id>/ convention in Cowork help center.
• Expose artifact backing-folder path in the Cowork UI and allow relocation.
• Add a "remove artifact from project" action in the Cowork UI so users don't need to hand-edit artifacts.json.

Error Messages/Logs

RPC error: failed to mount /mnt/.virtiofs-root/shared/Users/<user>/Documents/Claude/Artifacts/<artifact-id> as .artifacts/<artifact-id>: source path does not exist and could not be created: /mnt/.virtiofs-root/shared/Users/<user>/Documents/Claude/Artifacts/<artifact-id>: mkdir /mnt/.virtiofs-root/shared/Users/<user>/Documents: file exists

Steps to Reproduce

Steps to Reproduce

1. Create a Cowork project.
2. Inside the project, create a Claude Artifact (any kind — HTML, React, markdown, etc.). Cowork creates a backing folder at ~/Documents/Claude/Artifacts/<artifact-id>/.
3. Confirm at least one session in the project runs successfully (so the artifact mount works once).
4. Quit Claude Desktop.
5. On the host, delete, move, or rename ~/Documents/Claude/Artifacts/<artifact-id>/.
6. Relaunch Claude Desktop. Open the project. Start a new session pointing at ANY working folder — including folders completely unrelated to ~/Documents/.
7. Send any task (e.g. list files).

Result: Every session in that project fails with the above error, regardless of working folder selection.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Before the live artifact feature

Claude Code Version

Claude 1.3883.0 (93ff6c) 2026-04-21T17:24:01.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Additional Context

Discovered while diagnosing what initially appeared to be a OneDrive FileProvider issue. Full diagnostic trail: verified ~/Documents had no FileProvider extended attributes (xattr -l empty), OneDrive correctly contained under ~/Library/CloudStorage/OneDrive-*, Full Disk Access enabled for Claude Desktop. Error persisted across new projects with non-Documents working folders. Root cause identified by grepping ~/Library/Application Support/Claude/ for the error path, which led to the project's artifacts.json and revealed the hidden artifact mount.