list_debug_sessions reports the previous stop's lastStop (description "Paused") on a running session

[debugmcpdev]

Summary

list_debug_sessions copies session.lastStop onto every session that has one, regardless of state (src/server/handlers/session-tools.ts, handleListDebugSessions). lastStop is cleared on a new launch and after an auto-continued entry stop (session-manager-core.ts), but not when the user continues or steps, so a running session keeps reporting the previous stop:

{ "state": "running",
  "lastStop": { "reason": "step", "threadId": 0, "timestamp": 1789268768391, "description": "Paused" } }

Seen while self-debugging: a child mcp-debugger server launched with start_debugging, paused on a statement breakpoint in tool-dispatch.ts, stepped once, then continue_execution — list_debug_sessions a few seconds later showed state: "running" with lastStop.description: "Paused".

Why it matters for an agent

The tool's own description says "Paused sessions include lastStop with the reason for the most recent stop", and continue_execution's description tells the caller to poll list_debug_sessions, "whose lastStop/stopReason tells you why it stopped". An agent polling after a continue sees a lastStop whose description says the program is paused and whose reason is the stop it already handled; only the state field says otherwise. Nothing marks the record as belonging to a stop that has since been continued past.

What would help

Any of:

• omit lastStop from the listing unless state === "paused" (matches the description as written), or
• keep it but mark it, e.g. lastStop.stale: true / resumedAt, so a poller can tell "the stop you are waiting for" from "the stop you already continued from", and
• either way, drop the description: "Paused" wording for a record that describes a stop the session has left.

The same record is what get_stack_trace reports as lastStop, but that call fails on a running session, so the listing is the only place the stale record is user-visible.