sz-chrome-remote-cdp.git/FORK.md, branch masterpi-browser-harness, patched to drive a Chrome on another host over CDP, with castle_cdp_search web search
https://git.soarez.net/sz/sz-chrome-remote-cdp.git/atom?h=master2026-10-17T10:20:04+00:00Start a local Chrome when the target is an explicit local and none answers2026-10-17T10:20:04+00:00Igor Soarezigor@soarez.org2026-10-17T10:20:04+00:00urn:sha1:f61c43418d704cccb67132540ed7feceacef1d2a
Dedicated profile (~/.chrome-cdp-profile), macOS only, never for the
castle default. BU_LOCAL_CHROME_LAUNCH=off disables it.
castle-search: pi-castle-cdp-search joins the fork as sz-chrome-remote-cdp2026-10-15T22:08:24+00:00Igor Soarezigor@soarez.org2026-10-15T22:08:24+00:00urn:sha1:99d5702cb2ff0ead8e3a2b7a95fd057eefa89862fix(cdp): give the castle default 1.5s, not 5s, inside upstream's connect budget2026-10-15T21:25:41+00:00Igor Soarezigor@soarez.org2026-10-15T21:25:41+00:00urn:sha1:08c0c3a8b4fe755f7fe65ea8d258d77971503882feat(cdp): report a BU_CDP_WS pin in status, /browser-target and the prompt2026-10-15T06:07:58+00:00Igor Soarezigor@soarez.org2026-10-15T06:07:58+00:00urn:sha1:3e761274fe7b0e6be4a162e880293150ad9d9fbe
Upstream 0.11.0 made BU_CDP_WS reach the daemon, and discoverEndpoint()
returns it before the fork's target is consulted. resolveCdpTarget() did
not know about it, so /browser-status and the system prompt named the
BU_CDP_HTTP/stored/default target while the daemon dialled the pinned URL,
and /browser-target claimed to switch browsers when it could not.
resolveCdpTarget() now puts BU_CDP_WS first, as a remote target with
source "ws". /browser-target warns that it takes precedence, as it already
did for BU_CDP_HTTP. Only host:port is ever shown: the path carries the
browser id and a proxied URL may carry a token. /browser-status does not
probe a pinned URL, since /json/version answering says nothing about
whether the pinned browser id is still current.
FORK.md: upstream 0.11 made BU_CDP_WS reach the daemon2026-10-14T11:21:39+00:00Igor Soarezigor@soarez.org2026-10-14T11:21:39+00:00urn:sha1:19c6f64c8561e286687e2b81a2e1e82fb21fd73b
Upstream 0.11.0 moved BU_CDP_WS into discoverEndpoint(), so the claim
that the daemon ignores it is no longer true. Say why BU_CDP_HTTP is
still needed, where BU_CDP_WS sits in the precedence, and what to
expect and run when taking upstream releases now that upstream has a
boundary scanner and a daemon import-graph test.
FORK.md: rewrap2026-10-14T11:19:26+00:00Igor Soarezigor@soarez.org2026-10-14T03:13:38+00:00urn:sha1:a9b124e5bf09208a6e656027f8a31fff9e36b21eFORK.md: hosted on git.soarez.net, not castle2026-10-14T11:19:26+00:00Igor Soarezigor@soarez.org2026-10-14T03:13:33+00:00urn:sha1:b8f54767135e268f9ebb4ff99f080cfabebcbea4fix(profile): never prompt for a profile when driving a remote browser2026-10-14T11:19:26+00:00Igor Soarezigor@soarez.me2026-08-30T15:27:22+00:00urn:sha1:c8fd7b7078da841d5537aee9334291887445889f
Profile selection works by launching the browser with --profile-directory and
letting ProcessSingleton delegate to the running process, which only reaches a
browser on this machine. discoverEndpoint() already withholds userDataDir for a
remote target, but resolveUserDataDir() fell through to the local candidate
dirs, so the picker offered this disk's Chromium profiles for a browser on
another host - on castle, Brave's profiles for a Chrome on :9223. Pinning one
launched a local browser and polled the remote for a sentinel that could never
appear, failing after the seed deadline; seedProfileWindow()'s mismatch guard
missed it because connectedDir is undefined on the remote path.
Setup now returns early instead of prompting - the question had no actionable
answer, and since cancelling stores nothing it returned every session.
/browser-profile and seedProfileWindow() refuse with the reason, the latter
catching a pin left over from a local session.
docs: castle restarts Chrome on failure, not hourly2026-10-14T11:19:26+00:00Igor Soarezigor@soarez.me2026-08-30T15:17:49+00:00urn:sha1:3a0bfc3af446a947f8392aaa3e3b2605ea7ad2dafix(setup): skip local-browser precondition for every remote target2026-10-14T11:19:26+00:00Igor Soarezigor@soarez.org2026-08-29T21:59:29+00:00urn:sha1:cfa0b6f854e7f15717db385df0e43f974a4b1e67
The pre-flight check only skipped isBrowserRunning() when BU_CDP_HTTP was
set, so a machine with no local browser failed /browser-setup with 'No
browser instance running' before discovery ever dialed the built-in
castle default. Resolve the target the same way discovery does and skip
the local-process check whenever it resolves remote — env var,
/browser-target choice, or default. A resolved local target still
requires a local browser, and an unreachable remote still fails loudly
in step 4.