Node.js on Windows: child.kill() leaves the grandchild running, and node --test with a directory argument fails

Two Node.js behaviours seen on Windows. The first comes from a recorded incident; the second was recorded and then reproduced.

child.kill() reaches only the shell wrapper

A Node program started a helper with spawn(command, args, { shell: true }). On Windows that creates a cmd wrapper process, which in turn starts the real program (here an npx launcher and a node process beneath it). When the parent decided to stop the helper and called child.kill(), only the wrapper was terminated. The node grandchild survived and went on holding a local TCP port (an OAuth callback listener), so later launches failed with EADDRINUSE against a process nobody owned. This repeated on every restart of the host application, because the host terminated the bridge process without closing its stdin, which also meant cleanup hooked to the stdin end event never ran.

The fix that worked was to terminate the whole tree:

taskkill /pid <pid> /T /F

with /T as the part that matters, run from process.on('exit') and from handlers for SIGTERM, SIGINT, SIGHUP and SIGBREAK. On other platforms the same handlers used SIGKILL. A plain child.kill() was the cause; no variant of it was recorded as reaching the grandchild.

Not recorded: whether spawning without shell: true (so that the target executable is the direct child) would have let child.kill() work. The description above rests on the original incident and was not reproduced in isolation. A related mcp-remote debugging article covers the same incident from the OAuth side.

node --test with a directory argument

A project note records that node --test test/ failed on Windows and that naming the file worked: node --test test/lib.test.js. Reproduced on Node 24.22.1 on Windows 11:

> node --test test/
Error: Cannot find module '<full path to the project>\test'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1564:15)

Results from the same project folder, with one test file in test/:

• node --test test/a.test.js ran and passed (1 test).
• node --test test/*.test.js ran and passed (1 test); the glob was expanded by the shell.
• node --test with no argument ran and found the test (1 test).
• node --test ./test failed with the same Cannot find module error.

So the directory argument is treated as a module path to load, not as a folder to search. Whether this is specific to Windows was not tested on another operating system, and the note's label of Windows only follows the host it was observed on. Documentation for recent Node versions treats the arguments as glob patterns, which would explain the behaviour, but that was not checked against the Node 24 documentation here. Older Node versions were not tested; an earlier release that searched a directory recursively would behave differently.