[BUG] Chrome Native Host copy fails with EBUSY on every startup (should check hash first)
Description
Every time Claude Desktop starts, it attempts to copy chrome-native-host.exe to the user's AppData directory. If any Chromium-based browser is running, the file is locked and the copy fails with EBUSY. This produces an error on every single app startup.
Environment
- OS: Windows 11 Pro 10.0.26100
- Claude Desktop: v1.1.4173 (MSIX/Windows Store)
Error Message (7 occurrences, once per app startup)
[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked,
copyfile 'C:\Program Files\WindowsApps\Claude_1.1.4173.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
-> 'C:\Users\fong8\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'
Analysis
After comparing both files with SHA256, the source and destination are byte-identical (same size: 1,031,504 bytes). The copy is completely unnecessary in this case.
Suggested Fix
Before attempting the copy, compare the file hash (or at minimum the file size + mtime) of source and destination. If they match, skip the copy entirely. This would:
- Eliminate the EBUSY error when browsers are running
- Avoid unnecessary file I/O on every startup
- Only copy when the binary has actually been updated (e.g., after a Claude Desktop version upgrade)
Impact
Low — the existing native host binary works fine despite the copy failure. But it generates a noisy error in logs on every startup.
🤖 Generated with Claude Code
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗