bug: EPERM file watcher error on Windows when watching workspace files

[Sun-sunshine06]

Description

The file watcher (files.watch) throws an EPERM: operation not permitted, watch error on Windows. This likely occurs when the watcher tries to monitor files that are locked by another process or in a directory with restricted permissions.

Log Evidence

From main.log (2026-05-04):

[2026-05-04 ...] error: files.watch.error { error: 'Error: EPERM: operation not permitted, watch ...' }

Environment

• Version: v0.2 (experimental)
• Platform: Windows 11

Expected Behavior

File watcher should gracefully handle permission errors — either retry with backoff, fall back to polling, or silently skip the inaccessible file without crashing the watcher for the entire workspace.

Impact

File change detection breaks for the affected workspace, meaning the app won't pick up external edits to design files.

[github-actions]

Thank you for reporting this Windows-specific file watcher issue. EPERM on fs.watch is a known platform limitation — Windows locks directories/files in ways that fs.watch cannot always handle gracefully.

What we found in the codebase:

The workspace watcher is implemented in apps/desktop/src/main/workspace-watcher.ts (based on the repository structure and references to workspace watcher in dev/v0.2 planning documents). It currently uses Node.js native fs.watch, which throws EPERM on Windows when:

• A file is opened exclusively by another process
• A directory has restricted permissions
• The watcher hits a system-protected path (e.g., C:\$Recycle.Bin)

The implementation does not yet catch this specific error to retry with backoff or fall back to polling.

Suggested fix paths:

• Wrap the fs.watch call with a try-catch that specifically handles EPERM and either:
  • Retries with exponential backoff (up to a limit)
  • Falls back to polling via setInterval for the affected path
• Consider switching to chokidar (already a transitive dependency via vite), which handles EPERM internally and provides a polling fallback for Windows via the usePolling option.

To help us diagnose further:

1. Which version of Open CoDesign are you running? (The issue says v0.2 experimental — the latest release is v0.1.4, so this may be a dev build. Could you confirm?)
2. Can you share a redacted path from the log that triggered the EPERM? (e.g., a directory containing external files like node_modules, a network drive, or a OneDrive-synced folder?)
3. Does the error occur on every workspace open, or only with specific folders?

This is a valuable edge-case report — Windows file watching is notoriously tricky, and we want the watcher to be resilient there.

---

Open-CoDesign Bot

[Sun-sunshine06]

已在 PR #299 中修复并合并到 main。

现在工作区文件 watcher 在 fs.watch 启动或运行时遇到 EPERM / EACCES 时，会 graceful degradation 到 2 秒轮询工作区文件元数据，而不是让订阅失败或中断文件变更检测；普通非权限类启动失败仍会继续暴露为错误。验证包含 targeted Biome、workspace-watcher 单测、desktop typecheck 和全仓 typecheck。