Debuggee stdout/stderr is never forwarded to the MCP client

[debugmcpdev]

🐛 Bug Report

Summary

Debuggee stdout/stderr never reaches the MCP client. A Python script's print() output is not surfaced by any tool response or notification — there is no way for an agent to see what the program it is debugging printed.

Reported as a side-finding in #215 (comment) and confirmed on main: the reporter tested markers on both streams under two interpreters, and we reproduced it while validating the #215 fix (a script ending in print(f"result={total}") — the text appears nowhere in the MCP conversation).

Why this should already be plumbed

The Python launch config sets redirectOutput: true with console: 'internalConsole', so debugpy emits the debuggee's output as DAP output events to its client (the proxy). The events arrive; they are just never forwarded to the MCP tool surface.

Expected

Debuggee output should be queryable or streamed — e.g. buffered per session and exposed via a get_output tool or included in state responses (list_debug_sessions, stop events), or emitted as MCP notifications.

Impact

An agent debugging a failing script cannot correlate the program's own output with its paused state — a basic part of "what is this program doing." Today the only workaround is evaluating expressions to reconstruct state that was already printed.

Notes

• With the Python interpreter/debugpy probe spawns lack windowsHide: a console window flashes on screen for every session (Windows) #215 fix the adapter chain runs under pythonw.exe on Windows; console-based output paths are gone for good, making DAP output forwarding the only correct channel — as it already is for internalConsole + redirectOutput on all platforms.
• Other adapters likely have the same gap (worth an audit as part of the fix).