CDP WebSocket drops after first navigation — daemon logs "Connection lost", second Page.navigate times out

[keven221]

Before submitting

• I searched existing issues for duplicates.
• I ran browser-harness --doctor and read the output.
• I read the troubleshooting section of install.md.
• This is a reproducible bug in browser-harness — not a question, feature request, or cloud.browser-use.com issue.

Summary

Daemon connects to Chrome, first navigation works, then WebSocket drops. All subsequent CDP write commands (Page.navigate, Target.createTarget) timeout. Daemon log: "conn: Connection lost". Workaround: js("window.location.href=...") instead of new_tab().

Repro

Steps

# Chrome with remote debugging enabled (Way 1 or Way 2)
browser-harness --doctor  # chrome ok

# First nav WORKS
browser-harness <<'PY'
new_tab("https://example.com")
print(page_info())  # ✅ Example Domain
PY

# Second nav TIMEOUT
browser-harness <<'PY'
new_tab("https://httpbin.org/ip")
PY
# TimeoutError: timed out at _ipc.py line 99

cat /tmp/bu-default.log
# conn: Connection lost

Workaround

browser-harness <<'PY'
js("window.location.href = 'https://example.com'")
import time; time.sleep(2)
print(page_info())  # ✅ Works
PY

Environment

macOS 26.4.1 | Chrome 147 & 148 | Python 3.11.15 | browser-harness 0.1.0 | cdp-use 1.4.5 | websockets 15.0.1 | Both Way 1 & Way 2 identical behavior | chrome-devtools-mcp (Node.js) works perfectly

[honor2030]

I verified current main behavior for this issue and could not reproduce the second-navigation WebSocket drop in my local environment.

Environment:

• checkout: browser-use/browser-harness main at 9e47d2b77754
• OS/runtime: macOS 26.4.1, Python 3.12.4 via uv run, Chrome remote debugging on 127.0.0.1:9222
• daemon name used for isolation: BU_NAME=oss370

Current code path checked:

• src/browser_harness/helpers.py:317-325 — new_tab() creates about:blank, switches to the target, then calls goto_url(url).
• src/browser_harness/helpers.py:159-164 — goto_url() sends Page.navigate through the daemon.
• src/browser_harness/daemon.py:343-356 — regular CDP calls use the attached session except Target.*, and stale-session errors trigger attach_first_page() before one retry.
• src/browser_harness/daemon.py:359-368 — this is where IPC handler exceptions would be logged as conn: ....

Static checks:

• uv run --with pytest --with pillow python -m pytest tests/unit/test_daemon.py tests/unit/test_admin.py -q → 46 passed
• uv run python -m compileall -q src tests → passed

Dynamic probe:

BU_NAME=oss370 uv run browser-harness <<'PY'
import time
print('first nav')
new_tab('https://example.com')
time.sleep(1)
print(page_info())
print('second nav')
new_tab('https://httpbin.org/ip')
time.sleep(1)
print(page_info())
PY

Observed result:

first nav
{'url': 'https://example.com/', 'title': '🐴 Example Domain', ...}
second nav
{'url': 'https://httpbin.org/ip', 'title': '🐴', ...}
probe_exit=0

Daemon log tail for that run:

connecting to ws://127.0.0.1:9222/devtools/browser/...
attached ... session=...
listening on /tmp/bu-oss370.sock (name=oss370, remote=local)

No conn: Connection lost entry appeared during this probe.

Design note:
This looks environment-sensitive rather than a straightforward current-HEAD failure. The remaining differentiators from the report may be Chrome 147/148 behavior, profile/remote-debugging permission state, or a stale/expired browser WebSocket path after first navigation. If helpful, I can follow up with a narrower probe around the daemon's browser-level WebSocket liveness and target/session state immediately before and after each Target.createTarget / Page.navigate call.

[honor2030]

Opened a small scoped PR with the evidence above: #372

Scope: this does not claim to fully fix the underlying WebSocket drop. I still could not reproduce that drop on current main. The PR hardens the daemon boundary so if a regular CDP call (for example Page.navigate) stops answering, the daemon returns a useful timeout error before the helper IPC socket hits its 5s read deadline. That should make this failure mode easier to diagnose than a client-side _ipc.request() timeout plus a later conn: Connection lost log.

Verification included in the PR:

• RED focused test failed before the fix with an outer TimeoutError.
• GREEN focused test passed after the fix.
• tests/unit passed: 91 passed.
• compileall and git diff --check passed.
• Dynamic two-navigation probe still succeeds locally on current Chrome.

Using Refs #370 rather than Closes #370 because this is mitigation/diagnostic hardening, not a proven full root-cause fix.