[BUG] Claude Cowork for Windows, plugin skills searched at wrong location

[NikolaJelisavac]

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?

Claude Cowork for Windows tries to load the plugin skills from a wrong path resulting in skills not being able to load. (see repro steps for details)

What Should Happen?

Expected:
Skill is successfully invoked and executed

Error Messages/Logs

Steps to Reproduce

Repro:

• In Claude Cowork for Windows install one of the available Anthropic plugins, for example Sales.
• Try using one of the skills available in the plugin, e.g. saying "Use account-research skill to research Anthropic company".

Actual:
Claude Cowork thinks the skills is mounted in location like this:
/sessions/{session-name}/mnt/.local-plugins/../../../../../../Local/Packages/Calude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/{session-number}/{some-other-number}/cowork_plugins/[key-part-of-the-path]

while in reality it is located in following location:
/sessions/{sesion-name}/mnt/.local-plugins/[key-part-of-the-path]

This makes it impossible to use plugins and their skills on Windows in current Claude Cowork version

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude 1.1.2685 (f39a62)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. Plugin skill agent path resolution looks in wrong directory #18013
2. [Bug] Hook executor mangles Windows paths - backslashes stripped when expanding ${CLAUDE_PLUGIN_ROOT} #23957
3. Windows plugin path created as literal directory name in Linux Docker container #24503

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[hortontabS]

I'm having the same issue.

[whitegeek00]

Additional repro case: same bug + special character in username path

I can confirm this bug on my system with an additional complication: my Windows username contains an accented character (Á), which causes a secondary encoding issue on top of the wrong path resolution.

Environment

• OS: Windows 11
• Claude Desktop: 1.1.3189.0
• Feature: Cowork (research preview)

What I found in the logs

From cowork_vm_node.log, I can see Cowork is passing the following --plugin-dir argument to the VM process:

--plugin-dir /sessions/peaceful-trusting-hawking/mnt/.local-plugins/../../../../../../Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/8b4d404c-4b5f-4436-b640-4240c2d7e8a2/a844fd54-a4af-402e-821f-7d539d7b9f19/cowork_plugins/marketplaces/local-desktop-app-uploads/clean-brief

The ../../../../../../ traversal from /sessions/{name}/mnt/.local-plugins/ resolves inside the Linux VM to /Local/Packages/..., which does not exist in the VM filesystem.

Where the plugins actually are on disk

The real location of the plugins on Windows is:

C:\Users\[username]\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\8b4d404c-4b5f-4436-b640-4240c2d7e8a2\a844fd54-a4af-402e-821f-7d539d7b9f19\cowork_plugins\

The correct --plugin-dir path that should be passed to the VM (matching the pattern used for .skills) would be:

/sessions/peaceful-trusting-hawking/mnt/.local-plugins/clean-brief

Additional issue: username encoding

Running Get-ChildItem C:\Users shows my user folder listed four times with different encodings of the same accented character (Á, µ, ├ü, and a corrupted variant). This causes Cowork to fail silently when trying to resolve any path that includes the username.

Symptoms

• Plugins appear correctly in the Cowork configuration UI
• Slash commands appear in chat autocomplete
• Invoking a command produces no output or returns "unknown skill"
• "Show in folder" button fails silently

Workarounds attempted

• Created C:\Local\Packages\... directory tree mirroring the expected path with a junction to the real plugin folder → did not work (path is resolved inside the Linux VM, not on Windows)
• Created .local-plugins folder manually → did not work (Cowork manages this mount itself)

This is a blocking issue for paying subscribers whose Windows username contains accented or special characters, common across Spanish, French, Portuguese, and other European locales. A fix that resolves the plugin path without ../../../../../../ traversal would solve both issues simultaneously.

[speiron]

Confirming this issue on Windows 11 Pro, Claude Desktop v1.1.2685 (Microsoft Store), Pro plan.

I have two custom plugins (thesis and legal) uploaded. Neither plugin loads — Cowork resolves the skill paths through the full Windows host chain:

/sessions/{session}/mnt/.local-plugins/../../../../../../Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/{uuid}/{uuid}/cowork_plugins/marketplaces/local-desktop-app-uploads/thesis/

...instead of the correct VM-internal mount at /sessions/{session}/mnt/.local-plugins/[plugin-path].

The symlink traversal with ../../../../../../ clearly tries to escape the VM sandbox to reach the Windows host filesystem, which fails silently.

This completely blocks plugin usage on Windows. I cannot use any plugin skills — neither the built-in Anthropic plugins nor my custom-uploaded ones.

On an unrelated note, this bug is preventing me from buying feed for my cows. If this is not fixed soon, they will eat all the grass around the local dam, the dam will collapse, and half the Amazon will flood. Please consider prioritizing accordingly.

Environment:

• Windows 11 Pro x64
• Claude Desktop v1.1.2685 (f39a62) — Microsoft Store
• Plan: Pro
• Plugins affected: custom uploads + marketplace plugins

[dachent]

cowork-plugin-fix-prompt.md

Claude Code can fix this issue. Having had it fix the issue, I had it generate a prompt to replicate the fix. See attached.

I started out by explaning the error to Code and telling to find all the logs for the Claude app and for CoWork and identify the cause of the problem and the fix.