[BUG] Chrome Extension MCP: native host binary copy fails with EBUSY whenever the old host is running, leaving it stale #93083

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version

What's Wrong?

On Windows, the desktop app copies chrome-native-host.exe out of the installed package into %APPDATA%\Claude\ChromeNativeHost\ at startup. If a chrome-native-host.exe from a previous run is still alive — which is normal, since Chrome keeps native messaging host processes running — the destination file is locked, fs.promises.copyFile fails with EBUSY, and the copy is abandoned with no retry and no fallback.

This has fired 219 times over 20 days on my machine, roughly 10 times a day, on every app version in that window (1.34493.1.0 through 1.49585.0.0).

The concerning part is not the log line itself but the consequence: after an app update, the native host binary on disk can silently remain the old version, because the only code path that refreshes it is the one that just failed. The error is logged and execution continues as if nothing happened.

What Should Happen?

copyFile onto a running executable is expected to fail on Windows; the app should use the standard pattern instead of treating it as a hard failure:

• Write to a temporary name in the same directory, then rename() over the target. rename succeeds against a locked destination in cases where copyFile does not, and is atomic.
• If the rename also fails, fall back to MoveFileEx(..., MOVEFILE_DELAY_UNTIL_REBOOT), or retry after terminating/waiting for the old host process.
• Failing all of that, the app should at least retry with backoff and surface a real warning that the Chrome native host is stale, rather than logging an error and proceeding.

Error Messages/Logs

2026-09-09 21:33:01 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile '<drv>:\Program Files\WindowsApps\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe' -> '<home>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'
    at async Object.copyFile (node:internal/fs/promises:1327:10)
    at async jjn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2245502)
    at async Njn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2246141)
    at async Fjn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2246860)
    at async Ijn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2247723)
    at async Vjn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2249079) {
  errno: -4082,
  code: 'EBUSY',
  syscall: 'copyfile',
  path: '<drv>:\\Program Files\\WindowsApps\\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\\app\\resources\\chrome-native-host.exe',

Note the source path is inside WindowsApps\Claude_<version>_..., so the source changes with every app update — meaning every update is an opportunity for the destination to be left stale.

It reproduces continuously, not just at first launch. Occurrences per day (recent):

      9 2026-09-02
      7 2026-09-03
     15 2026-09-04
     17 2026-09-05
     10 2026-09-06
      8 2026-09-07
     13 2026-09-08
     11 2026-09-09

219 total across main1.log + main.log, first seen 2026-08-21 on app version 1.34493.1.0.

Steps to Reproduce

1. Windows, Claude desktop app with the Chrome extension connected.
2. Open Chrome with the extension active, so chrome-native-host.exe is running. (Get-Process chrome-native-host to confirm.)
3. Restart the Claude desktop app, leaving Chrome open.
4. Check %LOCALAPPDATA%\Claude\Logs\main.log — the EBUSY error above is logged and %APPDATA%\Claude\ChromeNativeHost\chrome-native-host.exe is not refreshed.

Is this a regression?

No, this never worked — it is present in the oldest logs I have.

Additional Information

• Claude desktop for Windows 1.49585.0.0 (also 1.34493.1.0, 1.37937.x, 1.40609.x, 1.44121.x, 1.46388.x)
• Claude Code 2.1.216
• Windows 11 Pro build 26220
• Installed from the Microsoft Store (Program Files\WindowsApps\...), which may matter: the package directory is read-only and versioned per update.