MCP debug_continue

Description

Resumes execution on the debugged Roku app. Routes to CDP (Hermes/TypeScript) or DAP (BrightScript) depending on the session's active backend(s) and the optional runtime parameter.

On the BrightScript side, CONTINUE carries NO thread argument on the wire at all -- it always resumes the whole app (every thread: main, render, and every task thread), never a single thread. There is no such thing as a thread-scoped continue for BrightScript; this tool does not accept a threadId for that reason.

If the app is already running when this is called, device behavior differs depending on exactly why: firmware source describes a SILENT no-op when no primary shell has ever been selected for debugging (a session that has never yet stopped) -- but live-device testing found that continuing an app that is genuinely mid-execution (a primary exists and is already running) instead answers with a distinct device error, surfaced here as a typed 409 CANT_CONTINUE. Treat that 409 as a real, expected device response describing the app's current state (check debug_state before retrying), not as a bug in this tool.

Optional parameters:

• runtime ("typescript" | "brightscript"): Force a backend. Defaults to the session's own mode
  (cdp_only -> typescript, dap_only -> brightscript, unified -> typescript).
• sessionId (string): Session id returned by debug_session_create. Uses the active session when
  omitted.

Aliases

Aliases: cdp_debugger_resume.

See also

• HTTP debugContinue (POST /api/debug/continue)
• rk debug continue

Parameters

additionalProperties: false

runtime

Force a backend

sessionId

Session id returned by debug_session_create