browser_navigate reports success but the page context is about:blank on the next tool call (v0.0.79, headless, HTTP transport)

[rwlove]

Summary

On v0.0.79, headless, HTTP transport, browser_navigate and browser_tabs(new) both return a successful result containing the correct Page URL and Page Title — but the very next tool call sees about:blank and an empty accessibility tree. No error is raised at any point.

This is the silent variant of the "dies between tool calls" class (cf. microsoft/playwright-mcp#1597, which errored explicitly on 0.0.73 with Target page, context...). Here nothing errors, so a caller has no signal that the navigation was lost.

Reproduction

Against a self-hosted SPA over HTTPS:

browser_tabs(action="new", url="https://<app>/#/home")
→ ### Result
  - 0: (current) [Music Assistant](https://<app>/#/home)
  ### Page
  - Page URL: https://<app>/#/discover
  - Page Title: Music Assistant          <-- loaded fine, title resolved

Immediately after:

browser_snapshot(depth=18)
→ ### Page
  - Page URL: about:blank
  ### Snapshot
  (empty)

Re-navigating reports success again with the correct URL and title:

browser_navigate(url="https://<app>/")
→ - Page URL: https://<app>/#/
  - Page Title: Music Assistant

…and the following browser_snapshot again returns about:blank with an empty tree. browser_tabs(action="list") also shows a single about:blank tab:

### Result
- 0: (current) [](about:blank)

Repeated 4 times in a row, with and without depth, and with no arguments at all.

Expected

Either the snapshot reflects the page that navigate just reported, or the tool reports an error. Returning a correct Page URL + Page Title from navigate while the context has actually reset to about:blank makes the failure undetectable from the tool results alone.

Environment

• Image: mcr.microsoft.com/playwright/mcp:v0.0.79
• Entrypoint: node /app/cli.js --headless --browser chromium --no-sandbox, plus HTTP transport flags
• Chromium, headless, containerised (Kubernetes), accessed via an MCP gateway over HTTP
• Target is a client-side-routed SPA served over HTTPS (hash routing); the reported title resolving correctly suggests the page did load before the context was lost

Notes

The title being populated in the navigate response implies the navigation genuinely succeeded and the context was discarded afterwards, rather than the navigation never happening. If that's the same underlying lifecycle problem as microsoft/playwright-mcp#1597/#1599, it appears to have become silent rather than fixed on 0.0.79.

I did not find an open issue describing the silent form; closing as a duplicate is fine if this is already tracked.

[yury-s]

What MCP client are you using, and what are the exact steps to reproduce?

Also, can you try if it still reproduces with PLAYWRIGHT_MCP_PING_TIMEOUT_MS=0 in the server env?

[rwlove]

Sorry for the slow reply — you'd already found it by the time I saw the question, but for the record: the client is Kuadrant mcp-gateway, brokering to the Playwright MCP container over streamable HTTP. It's POST-only — it never opens the GET event stream — which matches your diagnosis in #42189 exactly. That also explains why it presented as idle- and call-count-dependent on my side rather than deterministic.

Thanks for the quick turnaround.

Any sense of when this lands in a tagged mcr.microsoft.com/playwright/mcp image? Currently pinned to v0.0.79.