[BUG] Windows: Chrome opens 4 junk tabs (`native`/`host`/`wrapper`/`script`) on every launch — comment line from `chrome-native-host.bat` leaks as URLs

Summary

On Windows, every Chrome launch opens 4 additional tabs titled native, host, wrapper, and script. All fail with DNS_PROBE_FINISHED_NXDOMAIN. The tabs accumulate — 4 more on each launch.

The four words match, in order, the tail of the REM comment line in the Claude Code generated native host launcher:

REM Chrome native host wrapper script
           ^^^^^^ ^^^^ ^^^^^^^ ^^^^^^

Disabling the Claude in Chrome extension stops it completely. Re-enabling reproduces it.

Environment

• Windows 11 Home 26200
• Chrome 152.x
• Claude in Chrome extension 1.0.81
• Native host launcher: C:\Users\<user>\.claude\chrome\chrome-native-host.bat

Steps to reproduce

1. Install Claude Code and the Claude in Chrome extension on Windows
2. Have the native host registered at HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
3. Launch Chrome
4. Observe 4 extra tabs: native, host, wrapper, script — all DNS_PROBE_FINISHED_NXDOMAIN
5. Close and relaunch Chrome → 4 more tabs (8 total, two sets of the same 4)

Expected

No extra tabs. The launcher's comment lines are not URLs.

Actual

4 tabs per launch, matching the words in the REM comment line.

Confirmation that the extension is the cause

chrome://extensions → toggle Claude 1.0.81 off → relaunch Chrome → no extra tabs.

This was the decisive test. Everything else was ruled out first (see below).

Ruled out (verified, not assumed)

| Suspect | Result | How verified |
|---|---|---|
| chrome://settings/onStartup | Clean — one unrelated site only | Screenshot |
| Chrome enterprise policy | Only LocalNetworkAccessAllowedForUrls (2 SharePoint URLs) | Registry dump of HKLM\SOFTWARE\Policies\Google\Chrome |
| Chrome shortcut arguments | No URL args (--profile-directory="Default" only) | WScript.Shell inspection of all .lnk |
| Windows startup entries | All accounted for (OneDrive, ESET, Adobe, AMD, Roland) | Run keys + Startup folders |
| Other extensions | 8 others identified; the two "new tab" type ones are in a different profile and not loaded in the affected one | Extension folder IDs + chrome://extensions |
| Startup page site itself | Ordinary RSS portal, no window.open | Fetched and inspected |

The launcher file

164 bytes, LF line endings, UTF-8 encoded (contains a non-ASCII username in the path):

@echo off
REM Chrome native host wrapper script
REM Generated by Claude Code - do not edit manually
"C:\Users\<user>\.local\bin\claude.exe" --chrome-native-host

Byte-level detail:

• Line endings are bare 0A (LF), not 0D 0A (CRLF)
• The file is UTF-8; batch files are read using the system codepage (932 / Shift-JIS on this machine)
• The final line has no %*, so arguments Chrome passes (the calling extension's origin) are not forwarded to claude.exe

What I could and could not confirm

Confirmed:

• The 4 tab titles match the REM comment words exactly, in order
• Disabling the extension stops it; the extension is the cause
• Tabs accumulate per Chrome launch, so something at startup emits them
• Running the .bat directly via cmd /c ... < NUL produces empty stdout and exit code 0 — the comment does not leak in that path
• Running claude.exe --chrome-native-host directly starts normally and creates its named pipe

Not confirmed — I could not reproduce the leak outside Chrome:

• The exact mechanism by which the comment text reaches Chrome. Invoking the .bat by hand behaves correctly, so the leak appears to require Chrome's actual native-messaging invocation (stdio wired to pipes), which I could not replicate locally.
• Whether the LF line endings, the UTF-8 encoding, or the missing %* is the trigger. These are all deviations from what a Windows batch launcher should be, but I have not proven which one (if any) causes the leak.

I am reporting the observations rather than a diagnosis, since my attempts to pin the mechanism were inconclusive.

Possibly related

• #58559 — native host fails to claim bridge pipe on Windows (ERR_INVALID_ARG_TYPE)
• #58220 — framing protocol mismatch between MCP client and native host on Windows
• #15336 — native messaging host not installing on Windows
• #21426 — native messaging host never called

These all concern the same Windows native-host path but describe connection failures, not tabs being opened. The extension also reported "not connected" throughout my investigation, which is consistent with those issues.

Suggested fixes (in order of confidence)

1. Write the launcher as a proper Windows batch file — CRLF line endings, system-codepage (or ASCII-safe) encoding. The current file is generated with Unix conventions.
2. Drop the REM comment lines, or move them after the executable invocation. They carry no function and are the string that surfaces as tabs.
3. Forward arguments with %* so the calling extension origin reaches claude.exe.
4. Sanity-check what the extension treats as a URL — whatever parses the native host's output should not turn arbitrary whitespace-separated words into tab navigations. A malformed host response opening tabs is a failure mode worth guarding against regardless of the root cause.

Workaround for other users

Disable the Claude in Chrome extension (chrome://extensions → toggle off). Editing the .bat is not advisable — it is regenerated, and it says "do not edit manually."