Symptom
Follow-up to #641 / #642, found during the live smoke of #642 (Godot 4.6.3-stable, macOS).
When an editor-launched game hits a GDScript parse error during boot — a broken script attached to a scene node, a broken autoload, root or non-root — the game process calls GDScriptLanguage::debug_break_parse and freezes in a remote-debugger break before the game helper goes live (confirmed by sampling the hung process: parked in RemoteDebugger::debug under GDScript::reload).
In that state there is no record anywhere for the #642 machinery to surface:
- no Debugger Errors-tab row (the break happens before the error message is flushed to the editor),
- no editor Logger entry,
- no game-log line (helper logger never attached),
project_run resolves not_live with the generic "may still be booting or may have failed silently" message (it names a parse error only if retained pre-run errors happen to correlate, labeled may_predate_run).
The error is visible only in the Debugger's Stack Trace panel — which matches the original #641 report wording ("parse errors appear in the stack trace") and is scraped by nothing. The #642 mechanisms (live-message errors, game-log hint, timer-driven watermark) all work, but only when an error record exists; this path produces none.
Repro
- Attach a script containing
func f(: to any node in the main scene (or register it as an autoload).
project_run via MCP.- Game hangs pre-live in the debugger break; every MCP surface reads clean.
sample <game-pid> shows the debug_break_parse stack.
Proposed direction
Capture the break editor-side in McpDebuggerPlugin: a debug_enter/breaked notification arriving while the run is not yet live is almost certainly a boot-time script failure — record it (message + stack when available) into the surfaced-error tracker so project_run's liveness decision can report a run-scoped parse failure instead of the generic not-responding message, and consider auto-continuing or flagging the frozen-at-break state explicitly in game_status (e.g. status: "break"), since agents currently can't distinguish it from a slow boot.
Full smoke evidence: PR #642 discussion / smoke report (2026-07-05).
Symptom
Follow-up to #641 / #642, found during the live smoke of #642 (Godot 4.6.3-stable, macOS).
When an editor-launched game hits a GDScript parse error during boot — a broken script attached to a scene node, a broken autoload, root or non-root — the game process calls
GDScriptLanguage::debug_break_parseand freezes in a remote-debugger break before the game helper goes live (confirmed by sampling the hung process: parked inRemoteDebugger::debugunderGDScript::reload).In that state there is no record anywhere for the #642 machinery to surface:
project_runresolves not_live with the generic "may still be booting or may have failed silently" message (it names a parse error only if retained pre-run errors happen to correlate, labeledmay_predate_run).The error is visible only in the Debugger's Stack Trace panel — which matches the original #641 report wording ("parse errors appear in the stack trace") and is scraped by nothing. The #642 mechanisms (live-message errors, game-log hint, timer-driven watermark) all work, but only when an error record exists; this path produces none.
Repro
func f(:to any node in the main scene (or register it as an autoload).project_runvia MCP.sample <game-pid>shows thedebug_break_parsestack.Proposed direction
Capture the break editor-side in
McpDebuggerPlugin: adebug_enter/breaked notification arriving while the run is not yet live is almost certainly a boot-time script failure — record it (message + stack when available) into the surfaced-error tracker soproject_run's liveness decision can report a run-scoped parse failure instead of the generic not-responding message, and consider auto-continuing or flagging the frozen-at-break state explicitly ingame_status(e.g.status: "break"), since agents currently can't distinguish it from a slow boot.Full smoke evidence: PR #642 discussion / smoke report (2026-07-05).