js attach: pause_execution stays pending forever on an idle Node server — the stop never lands even once JS runs

[debugmcpdev]

Summary

On a javascript attach session against an idle Node HTTP server (an mcp-debugger instance, as it happens), pause_execution returns the documented pending: true shape — but the promised follow-up stop never lands, even after the target demonstrably executes plenty of JavaScript (it served multiple HTTP requests in the interim). The session stays running indefinitely; get_stack_trace keeps answering "Session is not paused". Retried twice minutes apart, same result.

Repro

1. node --inspect=127.0.0.1:9339 dist/index.js http -p 3111 (any long-lived mostly-idle Node server works)
2. create_debug_session {language: javascript} → attach_to_process {port: 9339, stopOnEntry: false} — succeeds, state running
3. pause_execution {sessionId} → {"success":true,"state":"running","data":{"pending":true,"message":"Pause requested; no 'stopped' event within 5s …"}}
4. curl http://127.0.0.1:3111/health several times — the server responds 200 each time, so JS is executing
5. list_debug_sessions → still running; get_stack_trace → "Session is not paused (state: running)" — held for minutes

Expected

The tool's own contract: "The session will report 'paused' once the stop lands." With the event loop provably running JS, the stop should land on the next dispatch — this is how CDP Debugger.pause behaves under an IDE.

Notes / suspicions

• Likely the pause is issued against the wrong thread/target in the js-debug parent/child topology (attach adopts a child session for the real target; threadId 0 quirks in that path have bitten before — cf. Rust/Windows: pause_execution reports stopReason 'exception' (0x80000003 break-in) instead of 'pause' #275/[BUG] Java attach pause_execution doesn't actually suspend the target #352/[BUG] .NET attach: pause_execution doesn't suspend, and breakpoints refuse to bind despite a valid Portable PDB #353 for other adapters' variants of "pause doesn't actually pause").
• Workaround that works every time: set a real breakpoint on a line the server executes per request (set_breakpoint on the /health handler) and trigger it — lands immediately with a full stack. This is what the ProxyManager loses a late init ACK: any worker boot >500ms fails the whole launch as 'Failed to initialize proxy after 6 attempts' #512 investigation used to get an evaluate_expression context.
• Found while dogfooding js attach to a Node process that forks children strands those children (second startDebugging target ignored, child waits forever) #501/ProxyManager loses a late init ACK: any worker boot >500ms fails the whole launch as 'Failed to initialize proxy after 6 attempts' #512 (attaching mcp-debugger to a live mcp-debugger server); it cost the investigation an instrumentation window and would confuse any agent following the tool's guidance.

Environment

main @ 9b220a2, Linux, Node 22.22.3, vendored js-debug.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NgA5kHzkhFZLqbWNZRTsVG