Installer overwrites existing Chromium installation instead of separate install

[get-n8n]

Issue Type

Agent Issue

Operating System

Windows

Description of the bug

After installing BrowserOS, it is combined with my main browser and all the history and data become shared.

How can I install BrowserOS in a separate directory so that it doesn't install on top of my Ungoogled Chromium browser?

Steps to Reproduce

1. Install BrowserOS
2. It is placed on top of Ungoogled Chromium

Screenshots / Videos

No response

BrowserOS Version

No response

Additional Context

No response

[lrq3000]

Same for me, and it is horrible. My Ungoogled Chromium was replaced without my consent with BrowserOS. This is a critical bug..

[lrq3000]

FYI I checked where the bin were installed and indeed they were moved to Program Files > Chromium, so this replaced my Ungoogled Chromium install. Whereas before it was installed in Application Data/Local/BrowserOS.

[shadowfax92]

Hey get-n8n and Stephen Karl Larroque (@lrq3000) — thanks for reporting this, and sorry it happened! BrowserOS should never replace an existing Chromium install. This is a serious installer bug — logged with high priority and added to our backlog. Can you both share your OS version and how you installed BrowserOS (direct download, package manager, etc.)? That'll help us reproduce it.

[lrq3000]

Nikhil (@shadowfax92) Thank you very much for taking this bug seriously.

I have Windows 11 Pro version 23H2 (build 22631.6199). It was a direct download install (I used the .exe installer), because the update was not detected (it was stuck at 0.41 and the latest was 0.44).

[get-n8n]

Windows 10 IoT LTSC 21H2 (19044.7184)

My browser Ungoogled Chromium is also installed by the installer from the official website https://ungoogled-software .github.io/ungoogled-chromium-binaries/releases/windows/64bit/

I downloaded the installation file from the website https://browseros.com / and installed it. It stood on top of my browser.

[get-n8n]

Friends, will there be a fix?

[lrq3000]

I would also like a fix, as I had to uninstall browseros fully meanwhile because it cannot be used as the primary browser because of memory management issues (it regularly overflows for big web apps such as long threads on llm web interfaces eg chatgpt).

[lrq3000]

I made an agent-assisted PR in #1003, hopefully this should fix the issue once a BrowserOS maintainer tackles it. This issue only affects Windows users, but still it would be nice to help us.

Meanwhile here is a workaround (AI-generated answer):

---

Based on the codebase search, the root cause of this issue stems from how the Windows installer (mini_installer.exe) and Chrome paths are configured for BrowserOS compared to standard Chromium or Ungoogled Chromium.

While BrowserOS patches the product name to BrowserOS in chrome/install_static/chromium_install_modes.h:

// The brand-specific product name to be included as a component of the install
// and user data directory paths.
-inline constexpr wchar_t kProductPathName[] = L"Chromium";
+inline constexpr wchar_t kProductPathName[] = L"BrowserOS";

There can still be registry or data directory conflicts if the base Ungoogled Chromium patches (which BrowserOS applies in series_patches/windows/ungoogled-chromium/) enforce shared user data directories, or if the mini_installer.exe uses the standard Chromium registry keys under HKCU\Software\Chromium or HKLM\Software\Chromium which causes Windows to treat them as the same application update rather than side-by-side installations.

Suggested Fixes / Workarounds

For the user right now (Workaround):
You can use the portable ZIP version of BrowserOS instead of the installer, and manually separate the user data directory by launching it with a custom command line flag.

1. Download the BrowserOS_installer.zip (Portable version) instead of the .exe.
2. Extract it to a separate directory (e.g., C:\BrowserOS).
3. Create a shortcut to BrowserOS.exe and modify the Target to include:
   --user-data-dir="C:\BrowserOS\User Data"
   This forces BrowserOS to keep its history and settings completely sandboxed from your Ungoogled Chromium installation.

For the codebase (Permanent Fix):

1. Windows Registry Separation: The installer script needs to be audited to ensure it replaces all Chromium references in the registry (e.g., in chrome/installer/mini_installer/ and the setup.exe generation) so Windows doesn't treat BrowserOS as an update to an existing Chromium installation. (Human edit: this is what Fix Windows install branding constants #1003 does).
2. Channel Suffixes: In chromium_install_modes.h, introducing a distinct install_suffix (e.g., L"BrowserOS") instead of L"" can force Windows to treat it as a side-by-side installation:

   .install_suffix = L"BrowserOS",  // Separate suffix to avoid Chromium conflict

(Also what #1003 does).

[lrq3000]

Any update on this issue?

[lrq3000]

The issue seems to have appeared in v0.42 with the update of the chrome version, as it was not present in 0.41 (I just reinstalled it, it does not overwrite the existing chromium install).