[BUG] Chrome Native Host copy fails with EBUSY on every startup (should check hash first)

Resolved 💬 2 comments Opened Feb 26, 2026 by bjlin-meshy Closed Mar 1, 2026

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:

  1. Eliminate the EBUSY error when browsers are running
  2. Avoid unnecessary file I/O on every startup
  3. 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

View original on GitHub ↗

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