take_screenshot times out (-32001) when called immediately after navigate_page #2459

Bug: take_screenshot times out (MCP -32001) when called immediately after navigate_page

Summary

take_screenshot reliably times out with MCP error -32001: Request timed out when called immediately after navigate_page. Waiting 5-6 seconds before the screenshot makes it succeed 100% of the time. evaluate_script on the same freshly-navigated page works fine, and direct CDP screenshots (bypassing the MCP server) complete in ~100ms.

Updated root cause (after controlled testing, see comments): the failure is an internal race/lock contention in the server right after navigation — when take_screenshot arrives while the post-navigation render-stabilization wait (see #2426 waitForStableDom mutex stall and #2338) is still settling, the screenshot request blocks until the MCP client's request timeout fires. This is reproducible in a fresh process with low memory, so memory leak (#2431) is NOT the cause of this specific symptom.

Environment

• OS: Windows 10.0.26200 x64
• Chrome: 150.0.7871.187 (stable)
• chrome-devtools-mcp: 1.6.0 (via npx -y chrome-devtools-mcp@latest --autoConnect)
• MCP host: opencode CLI 1.18.11 (stdio transport)
• Chrome debug port: 127.0.0.1:12885 (DevToolsActivePort, remote debugging enabled)

Steps to reproduce

1. Start chrome-devtools-mcp with --autoConnect (Chrome already running with remote debugging).
2. Call navigate_page (url: https://example.com) — succeeds.
3. Immediately call take_screenshot (format: png) — fails with -32001 Request timed out.

Reproducible both in opencode (4/4 immediate failures) and with an independent MCP client (round 2 of navigation→screenshot hung >30s while round 1 completed in 70ms).

Timeline of measurements

Additional observations

• CDP-layer screenshots are fast (89-190ms) even on pages with heavy DOM churn (setInterval mutating DOM every 5ms), so Chrome/rendering itself is not slow.
• Once the page is settled, consecutive screenshots (PNG/JPEG/WebP, inline or filePath) all succeed reliably.
• The failure appears specific to the window right after navigation while the page is still loading/settling. evaluate_script does not suffer because it does not wait for render stabilization.
• In-session failures consistently take exactly the client timeout (60s in opencode, 30s in my independent client) and then succeed on retry after the page settles — consistent with a blocked/stalled wait rather than slow processing.
• Investigation history: initial hypothesis (no upper bound on post-navigation render wait) → memory leak hypothesis (ruled out, fresh low-memory process reproduces) → current: internal race/lock contention with the post-navigation stabilization wait (see A dialog opened during a no-handleDialog action freezes the whole session for ~180s (mutex stall in waitForStableDom) #2426 / Allow read-only evaluate_script calls to skip the stable DOM wait #2338).

Request

Could the post-navigation wait used by take_screenshot (and possibly other render-dependent tools) be bounded by a configurable/server-side timeout or made non-blocking (e.g., proceed without waiting for full render stabilization, or serialize against the navigation wait without holding the client hostage)? Happy to provide DEBUG logs (DEBUG=* --logFile) on the next hang if that would help pinpoint the lock.