[Bug] Windows: Ctrl+C 退出 dsh web 会连带关闭由它拉起的整个浏览器(全部窗口与标签页)

[hqbx]

环境
Windows 11 24H2
dsh --profile web(默认 openBrowser: true;端口无关,3080/3081 均可复现)
默认浏览器 Chrome(任何经该链冷启动的默认浏览器同理)
现象
Chrome 当时并未运行,由 dsh web 启动时自动拉起;会话期间又打开了若干标签页。在运行 dsh web 的终端按 Ctrl+C 退出后,Chrome 全部窗口与标签页被一并关闭。

复现步骤
确保 Chrome 完全退出(任务管理器确认无残留 chrome.exe);
在 Windows 终端运行 dsh --profile web(不带 --no-open),等它自动打开浏览器;
在自动打开的 Chrome 中再开几个标签页;
回到终端按 Ctrl+C;
Chrome 整个浏览器随宿主一起退出,标签页全部丢失。
关键判定(解释偶发性):若 dsh 启动前 Chrome 已在正常运行(由 GUI 正常启动、无控制台),dsh web 只是在既有主进程里开一个新标签,Ctrl+C 不影响它——只有"浏览器由 dsh 启动链冷启动"这一形态中招。

根因(代码定位)
packages/bundle/web-app/src/index.ts 的 spawnBrowserLauncher 以 stdio: ['ignore', 'inherit', 'pipe'] 且不带 detached spawn node helper——helper 与 dsh web 宿主共享同一控制台;
npm open@11 的 Windows 实现 spawn powershell.exe(执行 Start ),PowerShell 作为控制台子系统子进程附着同一控制台;
由该链冷启动的 Chrome 主进程附着该控制台(与"从 cmd 运行 chrome --enable-logging 能在控制台看到日志"是同一机制);
终端 Ctrl+C → conhost 把 CTRL_C_EVENT 广播给该控制台附着的所有进程 → Chrome 收到控制台事件后退出整个浏览器会话。
佐证:本仓库自身在 packages/subprocess/subprocess-local/src/terminal.ts(signalForeground 的 win32 分支)注释里已写明"Windows 无进程组信号:conhost 把 \x03 变成对全部附着进程的 console-wide CTRL_C event";#3195 的对照实验同样证明共享控制台是 ctrl 事件波及面的决定因素(独立控制台拉起的实例存活)。

同族讨论(方向不同):#3195 / #7957 是宿主被杂散 ctrl 事件误杀;#8734 是同一条"dsh 冷启动整个浏览器"链的另一种后果。本报告的症状(用户浏览器被 Ctrl+C 连带关闭)未见既有 issue。

建议修复(已在本地验证)
spawnBrowserLauncher 在 win32 上 detached: true(libuv 映射 DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP):

helper 自此没有控制台;它 spawn 的 PowerShell、以及 PowerShell 经 ShellExecute 拉起的浏览器均不再附着宿主控制台,后续任何 console-wide ctrl 事件都到不了它们;
helper stdout 由 inherit 改为 pipe 并由宿主转发,浏览器交接的可观测性与测试证据通道保持不变;stderr 诊断路径不变;
新增 tests/browser-open-spawn.spec.ts 钉住标志(win32 detached + pipe 转发;POSIX 保持非 detach);
README.md / README.zh.md 双语补充行为说明。
回归:vitest 4 个用例通过(browser-open.spec.ts 1 + browser-open-spawn.spec.ts 3);oxlint 0 警告;whitespace / vendor manifest 钩子通过。

验收条件
按复现步骤操作,Ctrl+C 退出 dsh web 后,Chrome 及其全部标签页存活;
Chrome 预先运行的既有形态行为不变(新标签照开、退出互不影响);
浏览器打不开时的 stderr 诊断与 "use the dsh web URL printed at startup" 兜底不变;
POSIX 平台行为不变。

[PerryLink]

本仓的代码断言逐条属实，我全核实了。但你漏掉了一个上游反证 —— open 自己考虑过 detached 并否决了它，理由正是你担心的那件事。另外你的验收条件里少两条，不补上会有回归风险。

1. ✅ 你的定位在代码层面成立

packages/bundle/web-app/src/index.ts:183-192：

function spawnBrowserLauncher(url: string): ChildProcess {
  return spawn(process.execPath, [
    '--input-type=module',
    '--eval', BROWSER_OPENER_PROGRAM,
    '--', url,
  ], {
    env: scrubbedParentEnv(),
    stdio: ['ignore', 'inherit', 'pipe'],
  })
}

确实没有 detached，stdout 是 inherit。git grep -n "detached" -- packages/bundle/web-app/ apps/cli/ 只命中无关的测试夹具。

「open 在 Windows 起 PowerShell」本仓自证：:75 const BROWSER_OPENER_MODULE = import.meta.resolve('open')；:82 注释 → // open resolves at PowerShell spawn; keep it referenced until that launcher hands the URL to Windows.；:79-80 的 await open(process.argv[1])；:92-94 的 launcher.ref() + once('close')。

依赖：packages/bundle/web-app/package.json → "open": "^11.0.2"。

console-wide CTRL_C 的注释也确实存在 —— packages/subprocess/subprocess-local/src/terminal.ts:205-213：

if (this.platform === 'win32') {
  if (signal === 'SIGINT') {
    // Windows has no process-group signalling: a `\x03` input write is the
    // Ctrl-C delivery path the console host turns into a console-wide
    // CTRL_C event for attached processes. …
    this.terminal.write('\x03')

packages/subprocess/subprocess-local/README.md:152 同义。

2. ⚠️ 我核对第三方实物后确认：open 否决过 detached

我读了本机既有的 node_modules/open@11.0.4（packages/bundle/web-app/node_modules/open/index.js）：

• :170-185 → win32 分支：command = await powerShellPath()、executePowerShell.argumentsPrefix、['$ProgressPreference = ''SilentlyContinue'';', 'Start'] ⇒ 你描述的 PowerShell + Start 属实
• :209-210 → // PowerShell will keep the parent process alive unless stdio is ignored. / childProcessOptions.stdio = 'ignore' —— 只是 stdio 重定向，不是脱离控制台；win32 分支没有 detached、没有 windowsHide
• :244 → childProcessOptions.detached = true —— 仅非 win32 的 xdg-open 分支

⭐ 关键在 :282-288 的注释：

The PowerShell launcher must ALWAYS be awaited until it closes… See #367.
…libuv puts non-detached children in a job object that kills them when the parent exits…
Before v11, piped stdio kept the parent process alive until PowerShell exited, which hid this.
Detaching the launcher instead is unverified (PowerShell would get no console), while waiting is what worked before.

两层含义：

1. 它反过来佐证了你的机制 —— 「当前不 detach ⇒ PowerShell 有控制台」这个前提，只有在共享控制台成立时才需要说；所以你的链路判断是对的。
2. 但上游已经试过并否决了同一个思路 —— 理由是「PowerShell 会失去控制台」。你的方案在 helper 层更早 detach，会让 helper 与 PowerShell 同时失去控制台，正是 open 标记为 unverified 的风险面。

⇒ 建议在验收条件里补这一条：Start 在无控制台时仍能成功交接 URL（并保留 scrubbedParentEnv()）。否则可能出现"浏览器不关了，但也打不开了"。

3. ⚠️ 第二条要补的验收条件：stdout 管道阻塞

把 helper 的 stdout 从 inherit 改成 pipe 之后，当前 openBrowser 只读 stderr：

src/index.ts:195-221 → :198-199 收集 launcherStderr、:207-212 非 0 时用 stderr 构造错误、:215 if (launcherStderr !== '') process.stderr.write(launcherStderr)。

⇒ socket 若不 drain stdout，helper 写满管道会阻塞。你的验收条件没覆盖这一点，建议补上"转发并 drain stdout"。

4. 两处现状确认（都对你的补法有利）

• 默认开：src/index.ts:66 → openBrowser: z.boolean().default(true)；:246 → config.openBrowser && !launchedThroughSsh(…))；README.md:53 表格。
• 测试确实钉不住 spawn 标志：tests/browser-open.spec.ts 只有 1 例（:36），且 :105 直接替换 internals.openBrowser；master 上没有 browser-open-spawn.spec.ts（git ls-tree -r origin/master --name-only packages/bundle/web-app/ 无此文件）。⇒ 你说的"新增 spec + 3 例"确实是新文件，"vitest 4 例 = 1 + 3"自洽。

5. 一个可能更小风险面的替代方案

与其在 helper 层 detach（连 PowerShell 一起失去控制台），不如只让 PowerShell 那一环脱离控制台 —— 也就是不经过 open，自己在 win32 上：

spawn(powerShellPath, ['-NoProfile', '-Command', `Start ${url}`], { detached: true, stdio: 'ignore', windowsHide: true })

这样 helper 仍可保留 stdout/stderr 观测通道，也避开 open 的 job-object/等待逻辑。建议把它作为备选一起提，让维护者选。

6. 一处措辞建议

你把 PTY 语境的 console-wide 结论（terminal.ts）外推到 dsh web 的启动链 —— 在 Win32 行为上成立，但本仓并未对普通（非 PTY）控制台断言过这一点。建议写成「这是 Win32 的通用行为；本仓的显式记录在 PTY 语境」——这样更严谨，也不会被当成引用错误。

7. 用户侧立即可用的规避

dsh --profile web --no-open，或配置 openBrowser: false（README.md:53），然后手动打开启动时打印的 URL（printUrl 默认 true，src/index.ts:67）—— 完全绕开这条控制台链。

8. 两条边界

• 你没写版本。我核的是 origin/master = dsh-v0.2.1-alpha.2；rc.2 的 spawnBrowserLauncher 我未单独核（master 上 detached 确认不存在）。
• open@11 结论取自本机既有 11.0.4 副本（与 ^11.0.2 range 一致），非 lockfile 实证 —— 按规范标注。
• 「Chrome 冷启动主进程附着该控制台并因 CTRL_C 退出整个浏览器会话」这一环需要 conhost/Chrome 侧实证，UNVERIFIABLE；「未见既有 issue」（#3195/#7957/#8734 是 Discussion 编号）同样无法从代码核实。