JavaScript attach_to_process silently drops processId and fails with a generic "adapter exited during attach verification" #871

Summary

attach_to_process { processId } on a JavaScript session does not attach by PID and does not say so. transformAttachConfig (packages/adapter-javascript/src/javascript-debug-adapter.ts:925-937) destructures processId out of the config and discards it (void _processId), so js-debug receives an attach with neither port nor processId, tries its default localhost:9229, finds nothing, and exits. The tool then answers a generic verification failure that names neither the dropped key nor the port js-debug fell back to.

Measured (Windows 11, main at 6cb0c52 + #869/#870, js-debug 1.112.0, Node 24.14.1, dev server)

Target: a plain node forever.js (no --inspect), pid 8648.

create_debug_session { language: "javascript" }
attach_to_process     { sessionId, processId: 8648, stopOnEntry: false, verifyTimeout: 8000 }
  -> success: false, state: "error",
     message: "Failed to attach: Attach failed: the debug adapter reported an error and exited during
               attach verification: debug adapter exited during attach verification (code=null)"

The request js-debug received (proxy log, [MinimalDapClient] Sending request: seq 4):

{"__workspaceFolder":".","autoAttachChildProcesses":false,"console":"internalConsole","cwd":"…","host":"127.0.0.1",
 "name":"Attach to Node.js process","outputCapture":"std","pauseForSourceMap":false,"program":"attach://remote",
 "request":"attach","resolveSourceMapLocations":["**","!**/node_modules/**"],"runtimeExecutable":"…\node.exe",
 "smartStep":false,"stopOnEntry":false,"type":"pwa-node"}

— no port, no processId. js-debug's stderr, 10 s later: Error: Could not connect to debug target at http://localhost:9229: Could not find any debuggable target.

Why it matters

• The tool schema advertises processId ("Process ID (for local attach, language-specific)") with no per-language caveat, and the JavaScript docs only describe host/port attach. A caller who passes a PID gets a failure that points at nothing they did.
• js-debug's pwa-node attach does support processId (it activates the inspector of a running Node process — process._debugProcess(pid) on Windows, SIGUSR1 elsewhere — then attaches). mcp-debugger is the one dropping it, so by-PID attach is within reach.

Expected — either

1. Forward it: pass processId through to js-debug (like the other unlisted attach keys since adapterConfig: unknown keys are accepted silently — a typo of a supported key (pathMapping vs pathMappings) gets no warning #466/Fix: Typo tolerance and clean attach configurations #488) so attach_to_process { processId } attaches to a running Node process without a prior --inspect; or
2. Refuse it by name: when processId is given and port is not, answer before spawning the adapter: "JavaScript attach needs port (the target's --inspect port); processId is not forwarded to js-debug" — and, when the adapter then exits anyway, include js-debug's own last stderr line (Could not connect to debug target at http://localhost:9229) in the failure message instead of only code=null.

Found while trying to reach a nested mcp-debugger's proxy worker from the self-debug rig (#865 verification).