Description of the bug

Summary

When the currently selected page is closed, the Chrome DevTools MCP session can become unusable.

After that happens, MCP keeps returning:

Error: The selected page has been closed. Call list_pages to see open pages.

The problem is that recovery commands such as list_pages, new_page, and select_page may also fail with the same error, so the session cannot recover even though the browser still has other open pages.

Environment

• Chrome DevTools MCP
• Remote debugging against Android Chrome
• Remote browser discovered through browser_url=http://127.0.0.1:9223
• The remote browser was still alive and still had open pages after the failure

Reproduction Steps

1. Connect Chrome DevTools MCP to a remote Android Chrome instance.
2. Open multiple pages so that MCP has an active selected page.
3. Close the currently selected page.
   • This may happen because of page logic, host behavior, user action, or any other normal page lifecycle.
4. Try any MCP page-management command afterwards, such as:
   • list_pages
   • new_page
   • select_page

Actual Result

Once the selected page is closed, MCP may enter a broken state.

Subsequent page-related commands fail with:

Error: The selected page has been closed. Call list_pages to see open pages.

In my case, the remote browser still had other available pages, so the browser connection itself was not lost. The issue appears to be that MCP cannot recover after its selected target disappears.

Expected Result

If the selected page is closed, MCP should recover gracefully by doing one of the following:

• allow list_pages to work without requiring a valid selected page
• automatically fall back to another existing page
• allow new_page to create a fresh page even after the selected page is gone
• expose a recoverable state instead of locking the whole session

Why This Matters

This blocks real E2E automation for flows where page closure is an expected outcome, including but not limited to:

• child tab close flows
• popup close flows
• success flows that dismiss the current page
• any scenario where the active target disappears during normal automation

In these cases, page closure is valid application behavior, but it currently breaks the MCP session itself.

Additional Notes

The browser was still reachable from the remote debugging endpoint after the failure, which suggests this is not a browser disconnect issue but a session/context recovery issue inside MCP.

Reproduction

No response

Expectation

No response

MCP configuration

No response

Chrome DevTools MCP version

latest

Chrome version

No response

Coding agent version

No response

Model version

No response

Chat log

No response

Node version

No response

Operating system

None

Extra checklist

• I want to provide a PR to fix this bug