Chrome DevTools MCP --autoConnect: tool calls hang indefinitely through MCPProxy stdio transport #1317

Activity

1. Hronom commented on Sep 19, 2026

   

   Hronom

   on Sep 19, 2026

   More actions

   I checked current main because there are two lifetimes mixed together here: the tools/call request and the managed stdio process/connection generation.

   On current main, core/client.go wraps the call in call_tool_timeout (default 2m) and returns a timeout error, while managed/calltool_cancel_test.go explicitly asserts that this timeout must leave the upstream Ready and must not evict it. So if the child PID/connection generation really changes after the 60s failure on v0.67.0, that looks like a second owner reacting to cancellation/health state rather than the intended per-call timeout path.

   A useful regression fixture would be a stdio MCP that:

   1. initializes and reports an instance_id;
   2. accepts tools/call, emits waiting_for_human, then blocks on a test gate longer than the call budget;
   3. lets the proxy call time out;
   4. proves the same PID/instance_id and connection generation remain alive;
   5. releases the gate and defines what happens to the late response before allowing another call.

   That last part matters: preserving the process fixes the consent loop, but a timed-out browser mutation is still an ambiguous outcome. I would return a typed waiting_human/deadline_exceeded result with a call id, reject blind retry while that call is unresolved, and require either explicit cancellation or a fresh read-only reconciliation (list_pages) on the same generation. A longer timeout is then a workaround, not the correctness contract.

   For diagnosis, logging {server, pid/instance_id, connection_generation, request_id, cancellation_source, resulting_state} at timeout should show which layer actually restarts v0.67.0. The argument-stripping symptom should probably stay separate unless the same trace proves it shares the dispatch path.

   I maintain Hronaut, a local persistent browser workspace, so this human-consent/session-lifetime boundary is directly relevant to our work. This analysis is AI-assisted; I have not reproduced the Windows/Chrome flow.
2. Dumbris commented on Sep 20, 2026

   

   Dumbris

   on Sep 20, 2026

   Member

   More actions

   Good catch, thanks for digging into this.

   You're right on both counts. The process kill wasn't the per-call timeout path (that one already leaves the connection alone, there's a test asserting exactly that) — it was a second, independent thing: the background health check's own concurrent ping timing out on the same single-flight stdio pipe, which then tripped a reconnect that killed the process out from under the still-running call. Fixed in #1320, along with a couple more automatic-reconnect paths that had the same problem once I went looking.

   Arg-stripping was indeed a separate bug, also fixed in #1320 — nothing to do with the dispatch/health path, just a plain arg-resolution bug in call_tool_write.

   Your regression fixture idea (block a call past its timeout, confirm the same process/connection survives) is basically what the new tests do. The last part of your comment — typed waiting_human/deadline_exceeded results, blocking retries on an unresolved call, structured timeout logging — is a good idea but a separate, bigger piece of work. Opened #1321 to track it so it doesn't get lost.
3. Dumbris

   closed this as completedin #1320on Sep 20, 2026
4. Dumbris

   added a commit that references this issue on Sep 20, 2026

   fix: don't kill an in-flight stdio process on ambiguous health-check …

   ...

   40c214f
5. electrolobzik

   added a commit that references this issue on Oct 13, 2026

   Merge upstream/main into feat/tool-response-save-to-file

   ...

   c281e3f