Skip to main content
July 12, 2026

1Password-BrowserSupport.exe leaks ~60 processes/hour until Windows becomes unusable (traced: helper never exits after native messaging disconnect)

  • July 12, 2026
  • 2 replies
  • 9 views

Environment: Windows 11, 1Password 8.12.26 (reproduced on both the Microsoft Store build and the direct download; fresh reinstall does not help). Browser extension installed in Chrome, Yandex Browser and Edge.

Summary: 1Password-BrowserSupport.exe never exits when its native messaging channel closes. Since Chromium-based browsers regularly suspend and restart MV3 extension service workers, every restart spawns a new helper (plus its conhost.exe), and the old one stays alive forever. The result is a steady leak of roughly one process per minute per browser, 24/7, that slowly kills the whole machine.

Measured impact on my system (Ryzen 9 7950X, 64 GB RAM):

- After ~2.5 days of uptime: 2,510 × 1Password-BrowserSupport.exe + 2,520 × conhost.exe = 5,399 total processes (normal for this machine is ~370).
- Commit charge 83 GB of 127 GB.
- Ephemeral UDP port exhaustion (Tcpip event 4266), DNS timeouts.
- Performance counter subsystem failing with WMI quota violations — Task Manager's Performance tab hangs.
- System-wide input freezes for ~1 minute every time the display wakes (power/session notifications being broadcast to 5,000+ processes).
- Several hard system lockups while idle, logged as Kernel-Power 41 with bugcheck code 0.

Rebooting "fixes" it for about two days, which is exactly how long the leak takes to reach critical mass — this masquerades as many unrelated hardware problems (I ruled out RAM with a full MemTest86+ pass and updated GPU/chipset drivers before finding the real cause).

How I traced it: subscribing to Win32_Process creation events shows the spawn chain clearly. Each time a browser restarts the extension's service worker, it launches:

cmd.exe /d /s /c ""...\1Password-BrowserSupport.exe" chrome-extension://aeblfdkhhhdcdjpifhhbdiojplfjncoa/ --parent-window=0"
  < \\.\pipe\chrome.nativeMessaging.in.… > \\.\pipe\chrome.nativeMessaging.out.…

A new helper appears roughly every 60 seconds (one per browser with the extension enabled), and no helper ever exits — the process count only grows. All spawned helpers survive their parent and their pipe. Timestamps of accumulated processes show a flat ~40 spawns/hour around the clock, including hours when the machine is untouched.

Note also that the helpers are protected from termination (access denied from a non-elevated context), so regular users can't even clean this up without admin rights.

Expected behavior: the helper should exit when its stdin pipe closes, like any native messaging host.

Current workarounds I'm using:

- Hourly scheduled task running as SYSTEM: kill 1Password-BrowserSupport.exe processes older than 10 minutes (first run killed 122 of them; active connections just reconnect, nothing breaks).
- Alternatively, disabling "unlock with the desktop app" integration in the extension stops the spawning entirely.

Related reports: this looks like the same issue as the "BrowserSupport process spam" topic (June 24) and "1Password Browser Support process keeps opening new processes" (July 10) — users there report the same on Windows 10/11, including on the beta channel.

Could you confirm this is a known defect and share a timeline for a fix? Happy to provide the full process-creation trace, event log extracts, or run a diagnostic build.

2 replies

July 13, 2026

I am also having this issue however it seems it isn’t Chromium specific as I am using Librewolf (firefox). I am not tech savvy enough to go deep into it but with some help I have narrowed it down to the 1password extension being the cause of a conhost spam I was getting every couple of days.

Only temporary fix that works for me is to use “taskkill /F /IM conhost.exe” to stop the spam for a few hours or if I am lucky the rest of the day. 

1P_Gem
1Password Employee
July 13, 2026

Hi ​@Shattenjagger and ​@SomeoneNotImportant, thanks for reaching out to report this!

 

I’ve come across a couple of reports of similar behaviour recently, and so far in the cases I’ve seen, it seems as if it’s happening when integration is enabled in an unsupported browser and it hasn’t been added to the trusted browsers list. 

 

Just to confirm, have you added any unsupported browsers to the additional browsers list in 1Password? You can find steps for this here: Connect additional browsers to the 1Password app

 

If you’ve done this already, could you try removing and then re-adding any additional browsers to test whether this resolves the issue?

 

In addition to trying this, I'd like to ask you to create and share a diagnostics report from the 1Password desktop app, so our support team can investigate further: Send a diagnostics report

 

Attach the diagnostics to an email message addressed to: support@1password.com 

 

With your email please include:

 

 

 

You’ll receive a reply with a Support ID number. Please post that number here. Thanks!