Browser runtime does not recover when context closes during initial adapter navigation

[rishabhraj36]

Summary

Browser-backed adapter commands can repeatedly fail during their initial navigation with:

Target page, context or browser has been closed

The failure is not site-specific. It reproduced across multiple YouTube adapter commands and session/window modes while webcmd doctor could still report the daemon, Cloak runtime, and connectivity as healthy.

If the automation browser or its context is closed externally, Webcmd appears able to retain or lease runtime state that looks connected but loses the target during page.goto. The runtime does not invalidate and recreate that context at this failure boundary, so later adapter commands continue failing.

Reproduction

1. Start with the Webcmd daemon and Cloak runtime connected.
2. Close the automation browser/window or otherwise allow the active browser context to close.
3. Run webcmd doctor; it may report connectivity as healthy.
4. Run any browser-backed adapter command that navigates, for example:

webcmd youtube whoami -f json
webcmd youtube search "open source tools" --type video --limit 1 -f json

The problem also reproduced with foreground/background windows and ephemeral/persistent site sessions.

Actual behavior

ok: false
error:
  code: COMMAND_EXEC
  message: |-
    page.goto: Target page, context or browser has been closed
    Call log:
      - navigating to "https://www.youtube.com/", waiting until "load"
  exitCode: 1

A retained trace showed:

• trace ID: 20260812044945-e0c5af73
• initial/final page: about:blank
• the target disappeared about 0.6 seconds after navigation started
• no failed network requests
• no suspicious console messages
• no request reached the destination site

Expected behavior

When initial navigation fails with the closed-page/context/browser signature, Webcmd should:

1. invalidate the dead profile runtime/context;
2. create a fresh context and page;
3. retry the navigation once;
4. return the adapter result if recovery succeeds; or
5. return a structured BROWSER_CONNECT error with an actionable recovery instruction if it fails again.

webcmd doctor should also detect this dead-context state rather than reporting healthy connectivity while adapter navigation immediately fails.

Scope and likely boundary

This appears to be a browser runtime/session lifecycle issue rather than an individual adapter issue:

• it reproduced in more than one installed adapter command;
• it reproduced across different window and site-session modes;
• the trace contained no destination-site network or console failure;
• page creation has closed-context recovery, but a context that closes during the first navigation is not recovered;
• the higher-level Page.goto stale-page retry recognizes stale page-identity errors but not the broader closed-context signature.

Suggested regression coverage

Add a test where:

1. a context successfully returns a new about:blank page;
2. the page's first goto rejects with Target page, context or browser has been closed;
3. the runtime is invalidated;
4. a replacement context/page is created;
5. navigation is retried exactly once and succeeds.

Also cover a second closed-context failure to ensure recovery is bounded and returns BROWSER_CONNECT rather than looping.