[BUG] Cowork (Linux): resuming a pre-upgrade conversation fails with duplicate `.claude` / `.claude/skills` VirtioFS mount ("file exists")

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?

After upgrading Claude Desktop on Linux from the standalone claude-cowork-service to the built-in Cowork (and uninstalling the old service), every conversation that was created before the upgrade fails to start its Cowork workspace when resumed. Conversations created after the upgrade work fine.

Sending a message in a pre-upgrade conversation triggers a workspace spawn that fails immediately with an RPC mount error. From the log, the resumed session's mount set contains both .claude (the whole directory) and .claude/skills. The whole-.claude mount is set up first, which creates the .claude/skills path inside the session root; the subsequent .claude/skills mount then can't create its mount point and aborts with file exists.

A working (post-upgrade) session instead mounts .claude/projects and .claude/skills as separate subpaths, with no whole-.claude mount, so there is no collision. So resumed pre-upgrade conversations appear to replay a legacy mount layout that conflicts with the current per-subpath skills mount.

The transcript data is intact and readable — this only blocks starting the workspace, so the conversations cannot be continued.

What Should Happen?

Resuming a pre-upgrade conversation should start its workspace successfully, exactly like a new conversation. The mount set for a resumed session should be normalized so it does not contain both a whole .claude mount and a nested .claude/skills (and .claude/projects) mount; and/or mount-point creation should tolerate an already-existing directory (mkdir -p / ignore EEXIST) instead of hard-failing.

Error Messages/Logs

# Failing spawn — note mounts=7 includes BOTH ".claude" and ".claude/skills"
[Spawn:config] Creating spawn function for process=stoic-wonderful-cannon, isResume=true, mounts=7 (Homelab, homelab, outputs, .claude, .auto-memory, .claude/skills, uploads)

# The resulting mount failure
[Spawn:vm] Spawn failed: RPC error -1: "failed to mount /mnt/.virtiofs-root/home/<user>/.config/Claude/local-agent-mode-sessions/skills-plugin/<org-id>/<account-id>/skills as .claude/skills: failed to create mount point: mkdir /sessions/stoic-wonderful-cannon/mnt/.claude/skills: file exists"
[Process] Error: RPC error -1: "failed to mount ... as .claude/skills: failed to create mount point: mkdir .../mnt/.claude/skills: file exists"

# For contrast, a WORKING post-upgrade session mounts these as separate subpaths (no whole ".claude"):
#   .../mnt/.claude/projects   (virtiofs)
#   .../mnt/.claude/skills     (virtiofs)

Steps to Reproduce

1. On Linux, use an older Claude Desktop that runs Cowork via the standalone claude-cowork-service. Create and use several Cowork conversations.
2. Upgrade Claude Desktop to the version with built-in Cowork; uninstall claude-cowork-service.
3. Fully quit and relaunch the app.
4. Open a conversation that was created before the upgrade and send a message (this resumes it).
5. The workspace spawn fails with the RPC mount error above, and the conversation cannot be continued.
6. Create a new conversation and send a message — it works, confirming the failure is specific to resuming pre-upgrade conversations. Restarting the app and "Try again" / "restart from an earlier message" both reproduce the failure.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Desktop app — claude-desktop-bin 1.11187.4

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Setup
I'm specifically on CachyOS, but this bug shouldn't be distro specific I don't believe, due to the nature of it it would happen the same on any distro unless I'm mistaken. I am aware that I'm using a repackaged build, but the Cowork mount logic should by all reason still be your code in this scenario.

There was no choice for it in the dropdown, so just to re-iterate: This is a bug in the Linux Claude Desktop application (Cowork), not the CLI.

I was on version 1.11187.4 of claude-desktop-bin, and upgraded to version 1.17377.1. The old version used a separate claude-cowork-service package, which was on version 1.0.57.

Relation to existing issues.
This looks related to the area:cowork VirtioFS skills-mount failures but appears to be a distinct bug:

• #51744 (Cowork VirtioFS mount fails on macOS — assemble() symlinks the skills source): different platform and different mechanism. In my case the skills source mounts fine in new sessions; the collision here is on the destination mount point in resumed sessions.
• #42795 (Cowork virtiofs mount fails when Documents exists as a file): also macOS, unrelated path.

Impact.
All conversations created before the upgrade are un-resumable — data is intact but cannot be continued. No user-side workaround found. The mount set is a per-conversation snapshot with no UI control, restarting the app does not help, and there is no in-conversation folder toggle that recomputes it.

Suggested fix.
On resume, normalize/dedupe the mount set — drop the legacy whole-.claude mount when .claude/projects / .claude/skills are mounted individually — and/or make mount-point creation idempotent (tolerate EEXIST).