Skip to content

Fix MS Store dialog when opening chrome://inspect on Windows#431

Open
Jovenkemp wants to merge 1 commit into
browser-use:mainfrom
Jovenkemp:fix/windows-chrome-inspect
Open

Fix MS Store dialog when opening chrome://inspect on Windows#431
Jovenkemp wants to merge 1 commit into
browser-use:mainfrom
Jovenkemp:fix/windows-chrome-inspect

Conversation

@Jovenkemp

@Jovenkemp Jovenkemp commented Jun 12, 2026

Copy link
Copy Markdown

Problem

On Windows, _open_chrome_inspect() ends up at webbrowser.open("chrome://inspect/#remote-debugging"). Python's webbrowser module hands the URL to ShellExecute, which resolves the scheme through the registry — and Windows has no protocol handler registered for chrome://. The result is that the inspect page never opens; instead Windows pops a "You'll need a new app to open this chrome link" Microsoft Store dialog. Since _open_chrome_inspect() runs on every failed daemon attach, Windows users get this dialog over and over while trying to set up the remote-debugging checkbox.

Fix

Add a Windows branch that locates chrome.exe in the three standard install locations (machine-wide 64-bit, machine-wide 32-bit, per-user) and passes the URL as a process argument instead:

subprocess.Popen([chrome, url])

Chrome resolves chrome:// URLs natively when they arrive as arguments, and when an instance is already running the new process just forwards the URL to it as a new tab — which is exactly the desired behavior here, since the user's Chrome is normally already open.

This mirrors the existing macOS special case in the same function, which already routes around the OS default-handler path for the same reason (AppleScript open location instead of open).

Behavior when Chrome isn't found

If chrome.exe isn't in any of the three locations (e.g. an Edge- or Brave-only machine, or a portable install), the function falls through to the existing webbrowser.open() call — identical to current behavior, no regression. Unset environment variables are also safe: os.path.expandvars leaves the %VAR% text literal, which simply fails the os.path.exists check.

Testing

  • Windows 10 (build 19045), Chrome installed machine-wide: before the patch, every failed daemon attach popped the Store dialog; with the patch the inspect page opens as a tab in the running Chrome.
  • Verified all three path expansions resolve correctly and that the fallback is reached when no path matches.
  • macOS and Linux code paths are untouched (the new block is gated on platform.system() == "Windows").

🤖 Generated with Claude Code


Summary by cubic

Fixes Windows opening of chrome://inspect by launching chrome.exe directly from standard install paths, avoiding the Microsoft Store “You'll need a new app to open this chrome link” dialog. Falls back to webbrowser.open() if Chrome isn’t found; macOS/Linux unchanged.

Written for commit 8cc4a28. Summary will update on new commits.

Review in cubic

webbrowser.open() on Windows hands the URL to ShellExecute, which has
no protocol handler registered for the chrome:// scheme, so every
failed daemon attach pops a "You'll need a new app to open this chrome
link" Microsoft Store dialog instead of opening the inspect page.

Locate chrome.exe in the three standard install locations and pass the
URL as a process argument instead; Chrome forwards it to the running
instance as a new tab. Falls back to webbrowser.open() when Chrome
isn't found in any of them.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/browser_harness/admin.py">

<violation number="1" location="src/browser_harness/admin.py:738">
P2: Windows Chrome path lookup misses `%ProgramW6432%`, causing the fix to silently fail on 32-bit Python running on 64-bit Windows with 64-bit Chrome installed.</violation>
</file>

Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic

# dialog); pass the URL as an argument to the Chrome binary instead.
for chrome in (
os.path.expandvars(r"%ProgramFiles%\Google\Chrome\Application\chrome.exe"),
os.path.expandvars(r"%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe"),

@cubic-dev-ai cubic-dev-ai Bot Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: Windows Chrome path lookup misses %ProgramW6432%, causing the fix to silently fail on 32-bit Python running on 64-bit Windows with 64-bit Chrome installed.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/browser_harness/admin.py, line 738:

<comment>Windows Chrome path lookup misses `%ProgramW6432%`, causing the fix to silently fail on 32-bit Python running on 64-bit Windows with 64-bit Chrome installed.</comment>

<file context>
@@ -730,6 +730,20 @@ def _open_chrome_inspect():
+        # dialog); pass the URL as an argument to the Chrome binary instead.
+        for chrome in (
+            os.path.expandvars(r"%ProgramFiles%\Google\Chrome\Application\chrome.exe"),
+            os.path.expandvars(r"%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe"),
+            os.path.expandvars(r"%LocalAppData%\Google\Chrome\Application\chrome.exe"),
+        ):
</file context>
Fix with cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant