Skip to content

fix(proxy): detect stale proxy after browser restart + surface /navigate errors#141

Open
lordk911 wants to merge 1 commit into
eze-is:mainfrom
lordk911:fix/stale-proxy-detection-and-navigate-error
Open

fix(proxy): detect stale proxy after browser restart + surface /navigate errors#141
lordk911 wants to merge 1 commit into
eze-is:mainfrom
lordk911:fix/stale-proxy-detection-and-navigate-error

Conversation

@lordk911

Copy link
Copy Markdown

Problem

When Chrome/Edge is restarted while a cdp-proxy process is already running (very common — users quit/relaunch their browser all the time), the leftover proxy keeps answering /health with connected: true, but its page-level sessions are now dead. The result:

  • Page.navigate silently fails for every call
  • tabs get stuck on about:blank
  • /navigate returns an empty response body (JSON.stringify(undefined)), so the agent calling it has no signal to act on

From the outside this looks like "CDP can do nothing / every web task fails" and it persists for as long as the stale proxy survives.

Root cause: check-deps reuses any proxy that answers /health, never verifying that sessions actually work.

Repro

# 1. Chrome with remote debugging, start the proxy
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 &
node scripts/check-deps.mjs          # -> "proxy: ready (Chrome)"

# 2. quit & relaunch Chrome (new PID, same port 9222)

# 3. check again — health still ok, but the proxy is now brain-dead
node scripts/check-deps.mjs          # -> "proxy: ready (Chrome)"  (false positive!)
# /new <url>          -> tab stuck on about:blank
# /navigate <url>     -> ""  (empty body, navigation silently failed)

Fix

1. check-deps.mjs — functional probe in the reuse branch

Before reusing a healthy-looking proxy, run a real new → eval → close round-trip on a throwaway about:blank tab. If it fails, the proxy is stale → pkill -f cdp-proxy.mjs and restart it (the same manual fix the SKILL.md already tells users to do). This makes a browser restart self-healing instead of silently breaking everything.

2. cdp-proxy.mjs/navigate surfaces errors

When Page.navigate returns a CDP {error} (or no result), return HTTP 502 + the error JSON instead of writing an empty body. Turns an invisible failure into a diagnosable one.

Both changes are minimal and additive (happy path behavior is unchanged — verified: navigate still returns full results, the probe passes on a healthy proxy without spurious restarts and leaves managedTabs at 0).

🤖 Generated with Claude Code

…ate errors

A long-running cdp-proxy left over from before Chrome/Edge restarted
passes /health (connected:true) but holds dead sessions: every
Page.navigate silently fails, tabs stay on about:blank, and the
/navigate handler returns an EMPTY response body — so the caller has no
signal to act on. This makes the skill look totally broken ("CDP can do
nothing") for as long as the stale proxy survives.

check-deps reuses any proxy that answers /health, never verifying that
sessions actually work, so the dead proxy is reused indefinitely.

Two fixes:

1. check-deps.mjs — add a functional probe (new about:blank tab -> eval
   -> close) in the reuse branch. If it fails, kill the stale proxy and
   restart, so a browser restart no longer silently breaks all CDP ops.

2. cdp-proxy.mjs — /navigate now returns HTTP 502 + the CDP error JSON
   when Page.navigate yields a {error} (or no result), instead of writing
   an empty body that hides the failure.

Repro of the original bug (any machine):
  - start Chrome with --remote-debugging-port, run check-deps (proxy up)
  - quit & relaunch Chrome (new process, same port)
  - run check-deps again -> "proxy: ready" (health still ok)
  - /new <url> -> tab stuck on about:blank; /navigate -> empty response

After this patch, step 3 detects the stale proxy and restarts it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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