Skip to content

Add macOS Brave profile path + port-9222/9223 CDP probe fallback#173

Open
drichman1-maker wants to merge 1 commit intobrowser-use:mainfrom
drichman1-maker:fix/macos-brave-and-port-fallback
Open

Add macOS Brave profile path + port-9222/9223 CDP probe fallback#173
drichman1-maker wants to merge 1 commit intobrowser-use:mainfrom
drichman1-maker:fix/macos-brave-and-port-fallback

Conversation

@drichman1-maker
Copy link
Copy Markdown

@drichman1-maker drichman1-maker commented Apr 23, 2026

Summary

Two small additive fixes in daemon.py so macOS users running Brave (or any Chromium variant launched with --remote-debugging-port) can attach without manual BU_CDP_WS wiring.

  1. Add macOS Brave profile path to PROFILES. The list previously only had the Linux Flatpak path for Brave (~/.var/app/com.brave.Browser/...), so macOS Brave users hit DevToolsActivePort not found even with the sticky inspect checkbox enabled. Adds ~/Library/Application Support/BraveSoftware/Brave-Browser.

  2. Probe 127.0.0.1:9222 / :9223 /json/version as a final fallback in get_ws_url(). When Chromium is launched with an explicit --remote-debugging-port flag, DevToolsActivePort is not always written to the profile dir — CDP is fully live but the existing scan misses it. The fallback runs only after the profile-dir scan fails, and is gated to the standard debugging ports, so the normal sticky-checkbox flow is unaffected.

Both changes are additive — no existing behavior is altered.

Test plan

  • On macOS with Brave launched via open -a "Brave Browser" --args --remote-debugging-port=9222 and no DevToolsActivePort file present, browser-harness <<<'print(page_info())' attaches to the running browser via the new probe fallback.
  • Sanity-check on Chrome with the sticky inspect checkbox (existing flow) still works unchanged.
  • Linux/Windows users unaffected (paths and probe are macOS/Linux-friendly; probe is universal).

🤖 Generated with Claude Code


Summary by cubic

Enable automatic CDP attachment for macOS Brave and Chromium launched with --remote-debugging-port, removing the need to set BU_CDP_WS. Adds a macOS Brave profile path and a last-resort probe of ports 9222/9223; existing flows stay the same.

  • Bug Fixes
    • Added macOS Brave profile path: ~/Library/Application Support/BraveSoftware/Brave-Browser.
    • If no DevToolsActivePort is found, probe http://127.0.0.1:9222/json/version and :9223 and use webSocketDebuggerUrl.

Written for commit 704b1d4. Summary will update on new commits.

Two small fixes in daemon.py for macOS users running Brave (or any
Chromium variant launched with --remote-debugging-port):

1. PROFILES list was missing the macOS path for Brave
   (~/Library/Application Support/BraveSoftware/Brave-Browser).
   The Linux Flatpak path was the only Brave entry, so macOS Brave
   users got "DevToolsActivePort not found" even after enabling
   remote debugging.

2. When Chromium is launched with an explicit --remote-debugging-port
   flag, the DevToolsActivePort file is not always written to the
   profile dir. CDP is fully live, but get_ws_url() can't find it.
   Added a final fallback that probes 127.0.0.1:9222 and :9223 via
   /json/version and uses the returned webSocketDebuggerUrl. The
   loop is gated to the standard debugging ports and only runs after
   the existing profile-dir scan fails, so it doesn't interfere with
   the normal sticky-checkbox flow.

Both changes are additive — no existing behavior is altered.
Copy link
Copy Markdown
Contributor

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

Choose a reason for hiding this comment

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

No issues found across 1 file

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