all repos — sz-chrome-remote-cdp @ 3a0bfc3af446a947f8392aaa3e3b2605ea7ad2da

pi-browser-harness, patched to drive a Chrome on another host over CDP, with castle_cdp_search web search

docs: castle restarts Chrome on failure, not hourly
Igor Soarez igor@soarez.me
Sun, 30 Aug 2026 16:17:49 +0100
commit

3a0bfc3af446a947f8392aaa3e3b2605ea7ad2da

parent

cfa0b6f854e7f15717db385df0e43f974a4b1e67

1 files changed, 3 insertions(+), 2 deletions(-)

jump to
M FORK.md → FORK.md

@@ -31,8 +31,9 @@ `BU_CDP_HTTP="host:port"` is resolved inside `discoverEndpoint()`, so daemon and

client both honour it. It names an **HTTP** endpoint, not a WebSocket URL, because it is re-resolved on every discovery call — the browser UUID is re-read after the remote browser restarts. Chrome re-mints that UUID on every launch, so -a pinned WebSocket URL breaks as soon as the remote browser is recycled (castle -recycles Chrome hourly; see `cloud-setup/macos/chrome-cdp.sh`). +a pinned WebSocket URL breaks as soon as the remote browser restarts (castle's +watchdog restarts Chrome whenever CDP stops answering, plus once a day; see +`cloud-setup/macos/chrome-cdp.sh`). ## Install