[BUG] Cowork file bridge returns I/O error (errno 5) when accessing mounted folders containing files

Resolved 💬 3 comments Opened Feb 22, 2026 by bcfox2 Closed Mar 22, 2026

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?

When accessing a Windows folder mounted through the Cowork file bridge (VirtioFS/WinFSP), any folder containing files returns OSError [Errno 5] Input/output error. Empty folders work fine. This occurs regardless of file type, NTFS permissions, or read-only attributes.

Environment:

  • OS: Windows 11 Pro 25H2 (Build 26200)
  • Computer: KBY-VIVOBOOK17
  • User: KoLIS
  • Product: Claude Desktop - Cowork mode (Research Preview)

Steps to Reproduce:

  1. Open Cowork mode in Claude Desktop
  2. Select a Windows folder containing files (e.g., C:\Users\KoLIS\Desktop\0_미정리 with ~375 image files)
  3. Try to list or access any files through the VM mount path
  4. Result: OSError [Errno 5] Input/output error

What we tried (all failed):

  • Moving folder to different locations (C:\Users\KoLIS\.claude\, C:\Users\KoLIS\Documents\, etc.)
  • Removing read-only attributes (attrib -r, PowerShell, takeown + icacls + attrib)
  • Copying with robocopy /E /A-:R to strip attributes
  • Restarting Cowork app
  • Verified NTFS permissions are correct (Full Control for user and Everyone via icacls)

What works:

  • Empty folders mount and are accessible
  • Creating new files (e.g., hello.txt) in an empty mounted folder works
  • Short-named files (e.g., test01.jpg) work fine

Support ticket reference: Anthropic Support Conversation ID: 215473191741813

What Should Happen?

The Cowork file bridge should be able to access and list files in any mounted Windows folder without I/O errors, regardless of the number of files, filename length, or character encoding. Users should be able to mount folders containing existing files and work with them seamlessly through the VM.

Error Messages/Logs

$ ls "/sessions/.../mnt/새 폴더/"
ls: reading directory '/sessions/.../mnt/새 폴더/': Input/output error

Python equivalent:
OSError: [Errno 5] Input/output error: '/sessions/.../mnt/새 폴더/'

Steps to Reproduce

  1. Open Claude Desktop with Cowork mode enabled on Windows 11 Pro 25H2
  2. Prepare a Windows folder with multiple files (e.g., 375 image files with Korean filenames)
  3. In Cowork, select this folder for mounting
  4. Try to list directory contents via ls or Python os.listdir()
  5. Observe: Input/output error (errno 5)

Additional testing performed:

  • Empty folder: mounts and works correctly
  • Folder with 1 short-named file (e.g., test01.jpg): works correctly
  • Folder with 50 long-named Korean files: sometimes works after fresh mount
  • Folder with 100+ files: always fails with I/O error
  • Tried multiple folder locations under C:\Users\KoLIS\ - same result
  • NTFS permissions verified correct (Full Control via icacls)
  • Read-only attributes removed (verified with attrib) - still fails
  • robocopy with /A-:R flag to strip attributes - still fails

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop - Cowork mode (Research Preview)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This issue has also been reported to Anthropic Support (Conversation ID: 215473191741813). The support AI agent acknowledged the issue but could not resolve it. The ticket was escalated to a human agent.

This bug makes Cowork essentially unusable for Korean users who have files with Korean filenames, which is extremely common. The VirtioFS/WinFSP file bridge needs to properly handle Unicode filenames and larger directory listings.

Related issue also filed: Long Korean filenames specifically cause I/O errors even with a single file (see separate issue).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗