[Bug] Windows: cancelling a running shell tool call kills the dsh web host (console-wide CTRL_C)

[OverDustD7]

Hi,

On Windows 11 with dsh 0.1.5-rc.2 (the limitation is still documented in 0.1.7-rc.2), cancelling a
running shell tool call takes down the whole dsh web host:

• the host exits silently — no stderr stack, no Windows Application-Error event;
• launched as dsh web *>&1 | Tee-Object <log>, the log ends at startup with no error;
• plugins get disposal at that moment (a background git-sync plugin recorded "operation stopped"
  while mid-sync), and the terminal returns to a prompt.

Repro: start dsh web from a console → have the agent run a shell command → cancel that tool call
→ the host exits.

My reading: dsh-subprocess-local delivers SIGINT on Windows as a \u0003 write, which conhost
turns into a console-wide CTRL_C (documented in its README under "Known Limitations"). The host is
started from that same console and the provider's tool session is its child, so the host receives
that CTRL_C as well. The same README notes that an application only covers the default signal
disposition by installing a handler — so: does the host install a SIGINT handler? If not, that
would explain the silent exit, and installing one (or starting the host detached from the shared
console) would fix it.

Impact: cancelling a tool call tears down in-flight agent sessions and plugin operations, and a
plugin performing a git sync leaves a stale lock directory behind (reproduced several times here).

Happy to test a build. Related: discussions/7531.

Technical details (source references and log evidence)

Source references (published packages):

• @deepseek-ai/dsh-subprocess-local lib/runner-launch-*.js — Windows inspector returns the shell
  pid as the foreground process group: foregroundPgid(shellPid) { return shellPid; }
• same package lib/index.js signalForeground():
  if (signal === "SIGINT") { this.terminal.write("\u0003"); return foreground.processGroupId; }
  (only SIGKILL on the provider's own pid is refused: "refusing to SIGKILL the terminal shell")
• same package README, Known Limitations: "Windows terminal signalling is console-wide — SIGINT is
  delivered as a \x03 Ctrl-C input write that conhost turns into a console-wide CTRL_C event…"
• same package README, Shutdown behavior: "…The default OS disposition for an unhandled SIGTERM,
  SIGINT, or SIGHUP bypasses that event; an application covers those signals only by installing a
  handler that performs normal disposal or calls process.exit()."

Observed on this machine:

• plugin history recorded operation failures with reason "stopped" exactly when the host vanished,
  while a git sync was in flight;
• the host process was started from the interactive console (parent = the Windows Terminal's
  powershell.exe) and the tool session is its child → same console;
• the tee'd host log held only startup lines, no error, before the exit;
• Windows Application log shows no Application Error/WER entry, and System log shows no shutdown or
  resource-exhaustion event around those times → not an OS kill, not a native crash.

Suggested fix (host side): install a SIGINT handler (dispose-then-exit, or ignore a console-wide
CTRL_C that was not addressed to the host); alternatively start the host detached from the shared
console so console-wide CTRL_C cannot reach it.

[OverDustD7]

Follow-up from the reporter (one correction + confirmation).

Correction: the host does install signal handlers — dsh/lib/profile-boot-*.js:
const interrupt = (code) => { signalShutdown.abort(); shutdown.interrupt(code) }
process.on("SIGTERM", () => { interrupt(0) })
process.on("SIGINT", () => { interrupt(130) })
So the console-wide CTRL_C is treated as "the user asked to quit" and the host shuts down
gracefully (exit 130) — which is exactly why the log ends silently and plugins get disposal.

Confirmation of the path: the model-facing pwsh tool is dsh-tool-pwsh-persistent
("persistent pwsh tool over the owner-scoped PTY seam"), i.e. shell tool calls run inside a
persistent PTY session, so dsh-subprocess-local's terminal-session signalling is the one in play:
signalForeground() writes \u0003, conhost raises a console-wide CTRL_C, and the host — started from
the same console — receives it.

So the question narrows to: should cancelling a tool call be able to look like an intentional user
Ctrl+C? Two possible directions:

1. deliver SIGINT scoped to the tool session's own process group (spawn the shell with
   CREATE_NEW_PROCESS_GROUP; use GenerateConsoleCtrlEvent(CTRL_C_EVENT, pgid)) instead of writing
   \u0003 into a console shared with the host; or
2. have the host ignore a console-wide CTRL_C it did not ask for.

Local mitigation we are testing meanwhile: a preload that captures the host's SIGINT listener and
requires two Ctrl+C within 4 s to quit, logging stray signals to a file — the stray-SIGINT
timestamps line up exactly with tool-call cancellations.