Standalone CLI reports a paused session after its adapter exits during navigation

Read src/cli/dapClient.ts around the process-exit callback and src/cli/cliDebuggingExecutor.ts around the terminated callback and runThreadCommand error path. Trace how a rejected next or continue request can restore an older stopped state after adapter exit. Use the linked synthetic-adapter harness to check that abrupt exits leave get_debug_status at no-session, while live request rejections preserve the paused session.

Summary

When a standalone debug adapter exits while a step or continue request is
pending, the navigation call correctly returns an adapter-exit error. The next
get_debug_status nevertheless reports an active, paused session, even though
the adapter process is gone.

A rejected navigation request from an adapter that remains alive should preserve
the paused session. An adapter process exit should instead leave no active
session. The reproduction distinguishes these two outcomes.

Environment

• DebugMCP source commit: d0b4a334a6a3d8d600c5aa75ec60d9de272af3c4.
• Verified baseline: Windows x64, Node.js 24.22.1, compiled out/ modules.
• The root extension manifest at this commit reports version 2.4.4; this is not
  a claim about an installed or published standalone npm package version.
• A bounded synthetic Node DAP adapter over standard input/output; no language
  debugger, VS Code debug session or real debuggee is started.

Reproduction steps

1. In a writable working directory, create a separate upstream checkout and build the reviewed revision. The commands use PowerShell:

   $debugMcpRoot = Join-Path (Get-Location) 'DebugMCP-review-target'
   git clone https://github.com/microsoft/DebugMCP.git $debugMcpRoot
   git -C $debugMcpRoot checkout d0b4a334a6a3d8d600c5aa75ec60d9de272af3c4
   Push-Location $debugMcpRoot
   npm ci --ignore-scripts
   npm run compile
   Pop-Location
   

2. Obtain the reproduction project from its default main branch and run the test against that separate upstream checkout:

   $reproRoot = Join-Path (Get-Location) 'debugmcp-review-repro'
   git clone https://github.com/hahnfk/debugmcp-repro.git $reproRoot
   Push-Location $reproRoot
   node scripts/review/cli-adapter-exit-navigation.cjs --debugmcp-root $debugMcpRoot
   Pop-Location
   

   Reproduction sources and evidence:

   • Test harness
   • Synthetic DAP adapter
   • Module loader
   • Recorded results

3. The test creates a fresh production CliDebuggingExecutor and
   DebuggingHandler for each scenario. Their real DapClient starts the
   fixture as a child process and performs the DAP initialization and launch
   sequence. The fixture reports a breakpoint stop. The test confirms the
   public status is active and paused and reads the fixture's process ID and
   per-run marker through a public evaluation request.

4. For step_over, the handler sends DAP next. The fixture immediately calls
   process.exit(23) with that request still pending. It sends no response,
   exited event or terminated event. The actual DapClient child-process
   exit path rejects the pending request.

5. After receiving the navigation error, confirm that the fixture process is
   absent and call the public get_debug_status handler.

6. Repeat with continue_execution, which sends DAP continue. Each case uses
   a fresh executor so no previous-session startup state is involved.

The test also runs four controls: live adapters rejecting next and continue
with success:false, a normal step to a new stop, and a normal continue through
program completion. All six initial launches must succeed.

The default regression command exits nonzero on the reviewed commit. To require
the exact current bug, all positive controls and successful cleanup, use:

node (Join-Path $reproRoot 'scripts/review/cli-adapter-exit-navigation.cjs') --debugmcp-root $debugMcpRoot --expect-current-bug

An arbitrary startup failure, navigation timeout, or live adapter's ordinary
request rejection does not count as reproducing this adapter-exit bug.

Expected result

Both abrupt-exit cases should return the adapter-exit error from navigation.
Afterward, get_debug_status should report:

{
  "status": "no-session",
  "sessionActive": false,
  "paused": false
}

For comparison, a live adapter's rejected request should preserve its active,
paused session, and the adapter should still answer a fixture-identity request.
Normal step and continue operations should retain their usual behavior.

Actual result

Navigation reports an error containing:

Debug adapter exited with exit code 23

The fixture process is absent. Nevertheless, the subsequent public status is:

{
  "status": "paused",
  "sessionActive": true,
  "paused": true
}

The stale active-session result occurs for both next and continue. The
live-rejection and normal-navigation controls behave as expected. Process and
session IDs in the emitted JSON are observations from each local run, not
constants that other users must reproduce.

Cause

The production
DapClient process-exit callback
rejects pending requests and synchronously emits the client exit event. The
executor's
terminated callback
therefore marks the session terminated and clears its thread/frame context.

When the rejected navigation request resumes its asynchronous error path,
runThreadCommand restores previousState,
overwriting that newer termination with the old stopped state. The status
request then treats the dead adapter's session as active and paused.

Restoring the previous paused state is appropriate for the live-rejection
controls. It should not replace a newer adapter-exit state.

Scope and test seams

This is a standalone-executor lifecycle report. The reproduction uses the actual
compiled executor, handler and DAP-client implementations. It does not write
their private fields or replace their methods. Test seams are the synthetic DAP
peer, a deterministic configuration-manager double, the shared loader's inert
vscode import, and a quiet logger sink.

The fixture starts no debuggee and exits on closed input or its own ten-second
deadline. The harness has a separate twenty-second deadline. Normal cleanup uses
executor.dispose() and the production DAP client's owned child-process handle;
PID checks are read-only, and historical process IDs are never kill targets.
The JSON reports the tested commit, Node version, source/compiled-module hashes,
all controls and fixture-process cleanup. A rebuilt local fix can be tested with
the normal regression oracle; sourceDirty remains visible in its output.

Related reports

Issue #161 and merged
PR #162 address breakpoint
synchronization between sessions by resetting adapter initialization. This case
concerns an in-flight navigation request restoring stale execution state after
an actual adapter process exit.

Investigation tooling

This investigation and its reproduction work were carried out with assistance
from OpenAI Codex.

• Codex desktop app version: 26.1021.31345 (build 21828).
• Version verified on 2026-10-25, when this tooling disclosure was added.

The automated reproduction runs directly as an isolated Node.js harness against
the DebugMCP implementation. Codex assisted the investigation, harness authoring
and report preparation.