claude-code - 💡(How to fix) Fix [Windows] Cowork: Session VM process not available - cowork-plugin-shim.sh copy fails from WindowsApps directory (VFS limitation) [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48289Fetched 2026-04-16 07:04:00
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
labeled ×4

Error Message

This FAILS:

Copy-Item 'C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh' -Destination $dest

Error: "The given path's format is not supported" (NotSupportedException)

This WORKS:

$bytes = [System.IO.File]::ReadAllBytes('C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh') [System.IO.File]::WriteAllBytes($dest, $bytes)

Root Cause

Windows Store apps install into C:\Program Files\WindowsApps\, which uses NTFS + VFS package overlays. While files in this directory can be read via standard stream I/O (ReadFile / [System.IO.File]::ReadAllBytes), they cannot be copied using CopyFileW (the API underlying Node.js fs.copyFile() and PowerShell Copy-Item).

Attempted manual copy confirms the failure:

# This FAILS:
Copy-Item 'C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh' -Destination $dest
# Error: "The given path's format is not supported" (NotSupportedException)

# This WORKS:
$bytes = [System.IO.File]::ReadAllBytes('C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh')
[System.IO.File]::WriteAllBytes($dest, $bytes)

Fix Action

Workaround

Manually reading and writing the file via byte stream works. I wrote a PowerShell script as a temporary fix:

$src = "C:\Program Files\WindowsApps\Claude_1.2581.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-plugin-shim.sh"
$bytes = [System.IO.File]::ReadAllBytes($src)
# Then WriteAllBytes to each session's shim-lib\shim.sh

Code Example

[warn] [LocalAgentModeSessionManager] Failed to start shim permission bridge: 
UNKNOWN: unknown error, copyfile 
'C:\Program Files\WindowsApps\Claude_1.2581.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-plugin-shim.sh' 
-> 'C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\...\shim-lib\shim.sh'

---

# This FAILS:
Copy-Item 'C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh' -Destination $dest
# Error: "The given path's format is not supported" (NotSupportedException)

# This WORKS:
$bytes = [System.IO.File]::ReadAllBytes('C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh')
[System.IO.File]::WriteAllBytes($dest, $bytes)

---

$src = "C:\Program Files\WindowsApps\Claude_1.2581.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-plugin-shim.sh"
$bytes = [System.IO.File]::ReadAllBytes($src)
# Then WriteAllBytes to each session's shim-lib\shim.sh

---

// Instead of:
fs.copyFileSync(srcShimPath, destShimPath);

// Use:
const data = fs.readFileSync(srcShimPath);
fs.writeFileSync(destShimPath, data);
RAW_BUFFERClick to expand / collapse

Environment

  • OS: Windows 11 Home (Build 26200)
  • Claude Desktop version: 1.2581.0.0 (Windows Store / MSIX package)
  • Installation type: Windows Store app (C:\Program Files\WindowsApps\)

Bug Description

When using Cowork (Local Agent Mode), sessions consistently fail with:

Session VM process not available. The session may not be fully initialized.

The root cause is that Claude Desktop attempts to copy cowork-plugin-shim.sh from its WindowsApps installation directory to the session's shim-lib/shim.sh using the standard copyFile (CopyFileW) API. This operation always fails on Windows Store installs because the WindowsApps directory uses a VFS (Virtual File System) overlay that does not support CopyFileW.

Error in Logs

%APPDATA%\Claude\logs\main.log shows the following warning repeated for every session start attempt:

[warn] [LocalAgentModeSessionManager] Failed to start shim permission bridge: 
UNKNOWN: unknown error, copyfile 
'C:\Program Files\WindowsApps\Claude_1.2581.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-plugin-shim.sh' 
-> 'C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\...\shim-lib\shim.sh'

Root Cause

Windows Store apps install into C:\Program Files\WindowsApps\, which uses NTFS + VFS package overlays. While files in this directory can be read via standard stream I/O (ReadFile / [System.IO.File]::ReadAllBytes), they cannot be copied using CopyFileW (the API underlying Node.js fs.copyFile() and PowerShell Copy-Item).

Attempted manual copy confirms the failure:

# This FAILS:
Copy-Item 'C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh' -Destination $dest
# Error: "The given path's format is not supported" (NotSupportedException)

# This WORKS:
$bytes = [System.IO.File]::ReadAllBytes('C:\Program Files\WindowsApps\Claude_...\cowork-plugin-shim.sh')
[System.IO.File]::WriteAllBytes($dest, $bytes)

Workaround

Manually reading and writing the file via byte stream works. I wrote a PowerShell script as a temporary fix:

$src = "C:\Program Files\WindowsApps\Claude_1.2581.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-plugin-shim.sh"
$bytes = [System.IO.File]::ReadAllBytes($src)
# Then WriteAllBytes to each session's shim-lib\shim.sh

Suggested Fix

In the Claude Desktop source code, replace the copyFile() / fs.copyFileSync() call used for staging cowork-plugin-shim.sh with a stream-based copy (read + write), for example:

// Instead of:
fs.copyFileSync(srcShimPath, destShimPath);

// Use:
const data = fs.readFileSync(srcShimPath);
fs.writeFileSync(destShimPath, data);

This will work correctly for both Windows Store (MSIX) installs and traditional EXE installs.

Impact

All Cowork sessions are broken on Windows Store installs. The VM starts successfully, but every session fails immediately because the permission shim cannot be initialized.

extent analysis

TL;DR

Replace the copyFile() call with a stream-based copy using readFileSync() and writeFileSync() to fix the session initialization issue on Windows Store installs.

Guidance

  • Verify that the issue is indeed caused by the CopyFileW API limitation in the Windows Store app installation directory by checking the error logs and attempting a manual copy using Copy-Item.
  • Use a stream-based copy approach, such as reading and writing the file via byte stream, to work around the CopyFileW limitation.
  • Consider implementing the suggested fix in the Claude Desktop source code to replace the copyFile() call with a stream-based copy.
  • Test the fix by running a Cowork session on a Windows Store install and verifying that the session initializes successfully.

Example

// Replace the copyFile() call with a stream-based copy
const srcShimPath = 'C:\\Program Files\\WindowsApps\\Claude_1.2581.0.0_x64__pzs8sxrjxfjjc\\app\\resources\\cowork-plugin-shim.sh';
const destShimPath = 'C:\\Users\\<user>\\AppData\\Roaming\\Claude\\local-agent-mode-sessions\\...\\shim-lib\\shim.sh';
const data = fs.readFileSync(srcShimPath);
fs.writeFileSync(destShimPath, data);

Notes

The suggested fix assumes that the fs module is available and that the file paths are correct. Additionally, this fix may need to be adapted to work with the specific requirements of the Claude Desktop application.

Recommendation

Apply the workaround by replacing the copyFile() call with a stream-based copy using readFileSync() and writeFileSync(), as this will fix the session initialization issue on Windows Store installs.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING