[BUG] Orphaned chrome-native-host.exe blocks native-host binary sync (and eventually app launch) after Scheduled Task browser automation runs

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?

Summary

After a Claude Scheduled Task that uses browser automation completes, chrome-native-host.exe (the Chrome native messaging host Claude spawns) is left running with no living Chrome ancestor. It never exits, holds an open handle on its own binary inside the app's per-user resource copy, and every subsequent attempt by the app to sync/update that binary fails with EBUSY — a failure that is then silently logged as success. Left unaddressed long enough, the same lock pattern extends to blocking Windows package servicing for the app itself.

This is the same general failure class already tracked for CoworkVMService/cowork-svc.exe in #84005, #83968, and #80286 (a long-lived process Claude itself manages holds a lock on a binary inside its own MSIX package resources, and the app's own startup/sync logic then fails trying to touch that exact file). This report covers a second, distinct binary hitting the same underlying pattern — chrome-native-host.exe — with a specific, reproducible trigger (Scheduled Task browser automation) and a root-cause hypothesis those other issues don't cover, since none of them mention the native messaging host.

Environment

• App: Claude desktop app (Windows, installed via Microsoft Store / MSIX, package family Claude_pzs8sxrjxfjjc)
• Versions where reproduced: 1.22209.0.0, 1.24012.9.0, 1.24012.11.0 (persisted across at least 3 releases over multiple weeks)
• OS: Windows 11 (WSL2 host environment, but issue is native Windows-side)
• Browser: Chrome, Claude extension IDs seen in native messaging manifest allowed_origins: fcoeoabgfenejglbffodgkkbkcdhcgfn (primary, observed spawning the host), dihbgbndebgnbjfmelmegjepbnkhlgni, dngcpimnedloihjnnfngkgjoidhnaolf
• Native host manifest: %APPDATA%\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json, registered at HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension

Steps to Reproduce (best-effort reconstruction)

1. Have a Claude Scheduled Task configured that uses browser automation (in this case a task named research-article-digest, cron 0 7 * * *, i.e. daily at 7am).
2. Let the scheduled task fire and run to completion (log shows: task dispatched, session spawned, task run confirmed).
3. After the session ends, check running processes — chrome-native-host.exe (parented by a cmd.exe wrapper, which is Chrome's standard way of launching native messaging hosts on Windows) is still running, with no living Chrome process as an ancestor.
4. This process does not exit on its own. In the case reported here, it survived 6+ days until manually killed.
5. While it's alive, every subsequent attempt by the app to sync/update the native host binary fails.

What Should Happen?

Expected Behavior

• When a Scheduled Task session that used browser automation completes, the native messaging connection to Chrome should be closed, which should cause chrome-native-host.exe's stdin read to hit EOF and the process should exit.
• Native host binary sync failures (EBUSY) should not be silently logged as "Native host sync complete" — this masks the real problem and gives no signal to the user or telemetry that something is wrong.
• A stale/orphaned native host process should not be able to block the desktop app's own launch/update.

Error Messages/Logs

## Observed Behavior (from `%APPDATA%\Claude\logs\main.log` / `main1.log`)

Recurring failure pattern, observed on **July 17, 18, 19, and 29** (i.e., recurs regularly, not a one-off):


2026-07-29 13:04:08 [info] [Chrome Extension MCP] Copied native host binary to <home>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe
2026-07-29 13:04:08 [info] [Chrome Extension MCP] Installed native host manifest for All at ...
2026-07-29 13:04:08 [info] [Chrome Extension MCP] Registering native host for Chrome in Windows registry: ...
2026-07-29 13:04:08 [info] [Chrome Extension MCP] Native host sync complete

2026-07-29 13:08:19 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile
  '<drv>:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
  -> '<home>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'
2026-07-29 13:08:19 [info] [Chrome Extension MCP] Native host sync complete   <-- failure is swallowed, logged as "complete"


The timestamp `13:08:19` on the first `EBUSY` matches exactly when a new `chrome-native-host.exe` process (PID 23388, parent `cmd.exe` PID 26780) was spawned — i.e., the freshly-copied binary was immediately locked by a new host process, and every subsequent sync attempt failed against that lock from then on.

Confirmed via `Get-CimInstance Win32_Process` 6 days later (Aug 4):

ProcessId       : 23388
ParentProcessId : 26780   (cmd.exe, no living parent — orphaned from Chrome)
Name            : chrome-native-host.exe
CommandLine     : "...\ChromeNativeHost\chrome-native-host.exe" chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ --parent-window=0
StartTime       : 2026-07-29 13:08:19


Related scheduled task activity in the same log window:

2026-07-18 07:00:58 [info] [CCDScheduledTasks] Delaying dispatch for research-article-digest by 227s (jitter)
2026-07-18 07:04:45 [info] [CCDScheduledTasks] Spawning new session for scheduled task research-article-digest
  { cronExpression: '0 7 * * *', lastRunAt: '2026-07-17T14:04:30.071Z' }
2026-07-18 07:04:45 [info] [CCDScheduledTasks] Confirmed task run for: research-article-digest


Eventually (observed after this pattern accumulated across multiple days/app updates), launching the app produces a native Windows dialog:

C:\Program Files\WindowsApps\Claude_1.24012.11.0...
Another program is currently using this file.

This is Windows failing to service/repair the MSIX package because a stale file handle on a package-owned resource (`chrome-native-host.exe`) is still held by the orphaned process — the same user-facing symptom described in #84005, #83968, and #80286, but with `chrome-native-host.exe` as the locked file rather than `cowork-svc.exe`.

Steps to Reproduce

Steps to Reproduce (best-effort reconstruction)

1. Have a Claude Scheduled Task configured that uses browser automation (in this case a task named research-article-digest, cron 0 7 * * *, i.e. daily at 7am).
2. Let the scheduled task fire and run to completion (log shows: task dispatched, session spawned, task run confirmed).
3. After the session ends, check running processes — chrome-native-host.exe (parented by a cmd.exe wrapper, which is Chrome's standard way of launching native messaging hosts on Windows) is still running, with no living Chrome process as an ancestor.
4. This process does not exit on its own. In the case reported here, it survived 6+ days until manually killed.
5. While it's alive, every subsequent attempt by the app to sync/update the native host binary fails.

Observed Behavior (from %APPDATA%\Claude\logs\main.log / main1.log)

Recurring failure pattern, observed on July 17, 18, 19, and 29 (i.e., recurs regularly, not a one-off):

2026-07-29 13:04:08 [info] [Chrome Extension MCP] Copied native host binary to <home>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe
2026-07-29 13:04:08 [info] [Chrome Extension MCP] Installed native host manifest for All at ...
2026-07-29 13:04:08 [info] [Chrome Extension MCP] Registering native host for Chrome in Windows registry: ...
2026-07-29 13:04:08 [info] [Chrome Extension MCP] Native host sync complete

2026-07-29 13:08:19 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile
  '<drv>:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
  -> '<home>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'
2026-07-29 13:08:19 [info] [Chrome Extension MCP] Native host sync complete   <-- failure is swallowed, logged as "complete"

The timestamp 13:08:19 on the first EBUSY matches exactly when a new chrome-native-host.exe process (PID 23388, parent cmd.exe PID 26780) was spawned — i.e., the freshly-copied binary was immediately locked by a new host process, and every subsequent sync attempt failed against that lock from then on.

Confirmed via Get-CimInstance Win32_Process 6 days later (Aug 4):

ProcessId       : 23388
ParentProcessId : 26780   (cmd.exe, no living parent — orphaned from Chrome)
Name            : chrome-native-host.exe
CommandLine     : "...\ChromeNativeHost\chrome-native-host.exe" chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/ --parent-window=0
StartTime       : 2026-07-29 13:08:19

Related scheduled task activity in the same log window:

2026-07-18 07:00:58 [info] [CCDScheduledTasks] Delaying dispatch for research-article-digest by 227s (jitter)
2026-07-18 07:04:45 [info] [CCDScheduledTasks] Spawning new session for scheduled task research-article-digest
  { cronExpression: '0 7 * * *', lastRunAt: '2026-07-17T14:04:30.071Z' }
2026-07-18 07:04:45 [info] [CCDScheduledTasks] Confirmed task run for: research-article-digest

Eventually (observed after this pattern accumulated across multiple days/app updates), launching the app produces a native Windows dialog:

C:\Program Files\WindowsApps\Claude_1.24012.11.0...
Another program is currently using this file.

This is Windows failing to service/repair the MSIX package because a stale file handle on a package-owned resource (chrome-native-host.exe) is still held by the orphaned process — the same user-facing symptom described in #84005, #83968, and #80286, but with chrome-native-host.exe as the locked file rather than cowork-svc.exe.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.222

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Root Cause (hypothesis, based on available logs — host binary is not source-available to us)

1. Chrome launches native messaging hosts on Windows via a cmd.exe wrapper; chrome-native-host.exe communicates over stdio.
2. Something in the scheduled-task/browser-automation flow ends the session without the extension side (background/service worker) explicitly disconnecting the native messaging port, OR the automated browser context is torn down in a way that doesn't close the underlying pipe (e.g., forceful tab/profile teardown rather than a clean port.disconnect()).
3. chrome-native-host.exe blocks forever on ReadFile(stdin) and never receives EOF, so it never exits.
4. The long-lived process holds an OS-level exclusive-enough lock on its own .exe file, which lives inside the app's per-user resource copy (%APPDATA%\Claude\ChromeNativeHost\) — a copy that's re-synced from the MSIX package on every app start/update.
5. Repeated EBUSY on that copy operation is swallowed/ignored, so nothing surfaces it until the lock eventually also blocks Windows package servicing for the parent app itself.

Impact

• App becomes unable to launch after auto-update, requiring the user to manually find and kill an orphaned background process via Task Manager/PowerShell to recover — most users would not know how to diagnose this.
• Happens repeatedly (recurred across at least 4 separate dates over 3+ weeks in this case), tied directly to daily Scheduled Task usage.

Suggested Fixes

1. Primary: ensure the native messaging port is explicitly closed (or the host process is force-terminated) when a Scheduled Task / automated browser session ends, regardless of how that session terminates.
2. Defense in depth: have chrome-native-host.exe implement an idle/heartbeat timeout so it self-terminates if it hasn't received traffic in N minutes, rather than blocking on stdin forever.
3. Observability: don't log a swallowed EBUSY copy failure as "Native host sync complete" — surface it as a real error/warning so it's visible to both users and any crash/error telemetry.
4. Consider having the app detect and clean up orphaned chrome-native-host.exe processes (no living Chrome ancestor) on startup, before attempting to sync/replace the binary.
5. Given #84005 / #83968 / #80286 show the identical "long-lived self-owned process locks its own package binary" pattern for cowork-svc.exe, any general fix to that lock-handling/retry logic (e.g., retry-with-backoff instead of hard failure on first sharing violation) should be applied to the native host sync path as well, since both binaries live under the same app\resources\ tree and hit the same class of failure.

Workaround (in use until fixed)

Manually identify and kill orphaned chrome-native-host.exe / parent cmd.exe processes after each Scheduled Task run that uses browser automation, before relaunching the app.

Related issues

• #84005 — Windows MSIX updater repeatedly fails: CoworkVMService locks its own file, PreserveApplicationData rejection, stale-retry race
• #83968 — Windows/MSIX: auto-update never stops the old package — CoworkVMService orphans, locks WindowsApps, app cannot relaunch
• #80286 — Windows (MSIX): App fails to launch with "Another program is currently using this file" after update

These describe the same class of bug (self-owned long-running process locking a file inside the app's own MSIX package resources) for cowork-svc.exe. This report documents the same pattern for chrome-native-host.exe, with a specific trigger (Scheduled Task browser automation) and root-cause hypothesis not covered by those issues.