Native messaging hosts are launched via `cmd.exe` (regression vs upstream M113), orphaning host processes — 1,196 leaked processes / 20 GB / 318k handles in 21 hours

[hirosatosou]

Summary

BrowserOS launches native messaging hosts through cmd.exe instead of launching the executable directly. Upstream Chromium stopped doing this in M113 (2023). Because the intermediate cmd.exe exits immediately, every native messaging host process is orphaned at birth, and the browser's normal teardown — which terminates the process it spawned — targets the already-dead cmd.exe rather than the host. The hosts are therefore never terminated and accumulate without bound.

This is likely the same root cause as #1841 (flashing CMD windows), reported from the user-visible side.

Impact (measured)

With the 1Password extension installed and normal daily browsing:

Metric	Value
Orphaned 1Password-BrowserSupport.exe processes	1,196
Working set	20.3 GB (30.9% of 63.5 GB physical)
Open handles	318,404
Spawn rate	~48/hour (bursty: 11 spawns in 2 min, then 13–38 min quiet)
Accumulation window	2026-07-30 10:25 → 2026-07-31 07:38 (~21 h)

Side effect: handle exhaustion destabilised the 1Password desktop app's IPC, causing intermittent cannot connect to 1Password app failures in unrelated tooling (1Password CLI).

This is not specific to 1Password — it should affect any native messaging host (password managers, hardware token bridges, etc.).

Environment

• BrowserOS 148.0.7966.97 (chrome.exe signed by Felafax, Inc., signature valid)
• Windows 11 Pro 26200
• 1Password 8.12.30 (MSIX), host executable 1Password-BrowserSupport.exe
• No enterprise policies were set at the time of these observations — verified that no keys existed under HKLM\SOFTWARE\Policies\{Chromium,BrowserOS,Google\Chrome,Microsoft\Edge} or the HKCU equivalents, so NativeHostsExecutablesLaunchDirectly was unset (i.e. left to the browser's own default). See the workaround section below for what changed after.
• The manifest declares an .exe, so it should qualify for direct launch:

{
  "name": "com.1password.1password",
  "path": "1Password-BrowserSupport.exe",
  "type": "stdio"
}

Evidence

1Password's native host logs the chain of parent processes it is launched from. Every one of 1,001 log files (one per spawn) shows the same chain — BrowserOS chrome.exe → cmd.exe → host:

INFO  [windows.rs:63] Verifying browser "C:\Windows\System32\cmd.exe"
ERROR [windows.rs:72] WinApi(Error HRESULT(0x80092009))
INFO  [windows.rs:82] name: cmd, publisher: Unknown Publisher, pid: 119856, version: 10.0.26100.8737
WARN  [windows.rs:34] Failed to verify process parent. ParentVerificationFail(...)
INFO  [windows.rs:63] Verifying browser "C:\Users\<user>\AppData\Local\BrowserOS\Application\chrome.exe"
INFO  [windows.rs:82] name: chrome, publisher: Felafax, Inc., pid: 22820, version: 148.0.7966.97

Process inspection confirms the orphaning — the host's parent PID (the cmd.exe) no longer exists:

host PID=119456  ParentPID=119856  -> parent no longer exists

Expected behaviour

Since M113, Chromium launches native messaging hosts that are Windows executables directly, rather than via cmd.exe. See "Improving Native Message Host Reliability on Windows" and the NativeHostsExecutablesLaunchDirectly policy, whose Disabled state is documented as "launch hosts using cmd.exe as an intermediary process" — i.e. the behaviour BrowserOS currently exhibits by default at M148.

Steps to reproduce

1. Install any native-messaging-based extension (e.g. 1Password) in BrowserOS on Windows.
2. Browse normally for a few hours.
3. Observe: Get-Process 1Password-BrowserSupport grows without bound; every instance is orphaned.
4. Compare with Chrome/Edge >= M113, where hosts are launched directly and do not accumulate.

Workaround (confirmed working)

BrowserOS does honour the NativeHostsExecutablesLaunchDirectly policy, and it reads it from the unbranded Chromium root (SOFTWARE\Policies\Chromium — confirmed by locating that string in chrome.dll and chrome.exe; there is no SOFTWARE\Policies\BrowserOS). Setting it to 1 fixes the leak:

# Requires elevation: HKCU\SOFTWARE\Policies is writable only by Administrators
New-Item -Path 'HKCU:\SOFTWARE\Policies\Chromium' -Force | Out-Null
New-ItemProperty -Path 'HKCU:\SOFTWARE\Policies\Chromium' `
  -Name 'NativeHostsExecutablesLaunchDirectly' -Value 1 -PropertyType DWord -Force | Out-Null
# then restart BrowserOS — policies are read at startup

Measured before and after, same machine, same extension:

	Before	After
Launch chain	chrome.exe → cmd.exe → host	chrome.exe → host (direct)
Hosts spawned	1,001	4
Hosts that exited	0	3 (the 4th is the live one)
Count over 10 min	+~8 (≈48/h)	0 (flat at baseline)

Note for anyone diagnosing this: the host process is orphaned in both cases, because the launching process is short-lived either way. Orphan status is not the discriminator — whether the host ever exits is.

Questions for maintainers

• Is the pre-M113 cmd.exe launch path intentionally retained in the fork, or is this an unintended carry-over? Since the policy resolves it, the underlying code path appears to be present and working — only the default differs from upstream.
• Would you consider making direct launch the default, matching upstream M113+? That would also resolve CMD terminal windows constantly flashing / popping up on Windows 11 #1841 for users who never find this policy.