PR #69733: fix(browser): reset Chrome MCP session after navigate_page timeout

• Repository: openclaw/openclaw
• Author: ayeshakhalid192007-dev
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/69733

Description (problem / solution / changelog)

Summary

Fixes #69624 — browser profile existing-session gets permanently stuck after the first navigation timeout, requiring a gateway restart.

Root Cause

navigateChromeMcpPage() only forwarded a timeout to the Chrome MCP navigate_page tool when the caller explicitly provided timeoutMs. The route in agent.snapshot.ts never provides one, so Chrome MCP's subprocess could block indefinitely on a slow navigation. Because the stuck session was cached and returned to all subsequent callers, the entire profile became unresponsive until the gateway restarted.

callTool() also lacked a safety-net: even if Chrome MCP honoured its own timeout internally, there was no outer guard to tear down and evict the session. The existing catch block also had a pre-existing race where it deleted the session cache entry without a transport-identity check, so a concurrently-created replacement session could be clobbered.

Changes

extensions/browser/src/browser/chrome-mcp.ts

• callTool() gains an optional timeoutMs parameter. When set, Promise.race competes the raw MCP call against a setTimeout-based rejection; on timeout the session is torn down (transport-identity-checked) and the error surfaces to the caller so the next request reconnects with a fresh subprocess.
• navigateChromeMcpPage() now defaults timeoutMs to CHROME_MCP_NAVIGATE_TIMEOUT_MS (20 s) and always forwards it to Chrome MCP, plus passes CHROME_MCP_NAVIGATE_CALL_SAFETY_TIMEOUT_MS (25 s) as the outer safety-net to callTool().
• The catch block in callTool() gains the same transport-identity guard used elsewhere in the file, fixing the pre-existing replacement-session race.

extensions/browser/src/browser/chrome-mcp.test.ts

• Two new tests: one asserting the default timeout is always forwarded; one using vi.useFakeTimers() to advance past the 25 s safety-net and confirm the session is reset and the next call reconnects.

extensions/browser/src/browser/chrome.internal.test.ts

• Pre-existing test failures on Linux: existsSync mocks matched only the macOS Chrome app path ("Google Chrome"). Extended all affected mocks to also match Linux paths (google-chrome, /usr/bin/chromium). No logic changes to the tests themselves.

Why This Is Safe

• No change to any public export signatures — timeoutMs was already an optional parameter on navigateChromeMcpPage().
• The 25 s safety-net gives Chrome MCP the full 20 s to honour its own timeout plus a 5 s buffer; the two timeouts do not conflict.
• openChromeMcpTab() already passed an explicit timeoutMs — its behaviour is unchanged.
• agent.snapshot.ts passes no timeoutMs; the new default covers it with no edit to that file.

Testing

All 94 browser extension test files pass (809 tests), including two new cases:

• "always passes a default timeout to navigate_page when none is specified"
• "resets the Chrome MCP session when a navigate_page call hangs past the safety-net timeout"

Fixes #69624

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/browser/src/browser/chrome-mcp.test.ts (modified, +66/-1)
• extensions/browser/src/browser/chrome-mcp.ts (modified, +56/-13)
• extensions/browser/src/browser/chrome.internal.test.ts (modified, +50/-10)