[Windows] Console window flashes on every shell tool call when dsh runs without a host console (Web UI / Electron)

[xswt442-cmd]

中文摘要：Windows 上以 Electron 壳 / 无控制台方式运行 dsh web 时，agent 每次调用 shell 工具都会闪出一个可见控制台窗口（标题为 Git\usr\bin\bash.exe 或 cmd.exe）。根因：Windows ACL 沙箱在受限令牌下无法使用 CREATE_NO_WINDOW（子进程会以 STATUS_DLL_INIT_FAILED / 0xC0000142 死亡），因此设计为“子进程共享宿主控制台”；但 Web/Electron 宿主本身没有控制台可共享，Windows 就为每个子进程分配一个全新的可见控制台。0.1.0-rc.6 与 0.1.1-rc.2 行为一致。详细分析与修复建议见下方英文部分。

Environment

• Windows 11 Pro build 26200
• dsh 0.1.1-rc.2 (identical behavior on 0.1.0-rc.6)
• Launch mode: GUI wrapper without a console → node ...\@deepseek-ai\dsh\lib\bin.js web --port 3080
• Executors involved: winbash (Git Bash) and pwsh tool calls from any session

Steps to reproduce

1. Start dsh web from any process that has no attached console (GUI launcher / Electron wrapper / detached service).
2. In the Web UI, trigger any shell tool call (winbash or pwsh).
3. Watch the screen/taskbar: a new console window flashes open and closes for every spawn — titled with e.g. C:\Program Files\Git\usr\bin\bash.exe or cmd.exe.

Expected

Background tool executions should not create visible console windows.

Actual

One visible console window per spawned child, on every tool call, in every active session. Very disruptive when agents run multiple commands.

Root cause analysis

sandbox-windows-acl's own README states:

Console isolation is unavailable. Under the restricted token, children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142). ... Children therefore share the host console; stdio redirection is pipe-based, unaffected.

“Children share the host console” only holds when the host has a console (CLI usage). When the host is a GUI/detached process — i.e. the graphical Web UI launch path this project ships — there is no console to share, so Windows allocates a new visible console for every child.

Verified against the installed artifacts:

• No windowsHide is set anywhere in the executor spawn paths (it is correctly set in dsh-native-command, dsh-host-directory-picker-native, and the MCP SDK stdio client).
• No difference between 0.1.0-rc.6 and 0.1.1-rc.2.

Possible directions to fix

1. If the server process has no console, allocate one hidden console at startup (e.g. AllocConsole kept hidden, or launch via a hidden conhost), so sandboxed children can share it instead of each allocating a fresh visible one.
2. Alternatively, allocate a hidden pseudoconsole (ConPTY) for restricted children instead of relying on console inheritance.
3. At minimum, set windowsHide: true on all non-restricted spawn paths, as some native helpers already do.

Happy to provide additional logs or a minimal repro script if useful. Thanks!

[xswt442-cmd]

Update: confirmed the wrapper-side workaround — launching the server without DETACHED_PROCESS (keeping windowsHide: true) gives the whole process tree one hidden shared console; zero window flashing across winbash/pwsh/cmd spawns. Upstream could do the same internally (e.g. a hidden AllocConsole for console-less hosts) to fix this for all GUI/detached launch modes.

[Mide69]

Checked this in the source. Confirmed: packages/subprocess/subprocess-local/src/spawn.ts is the actual spawn path used by winbash and pwsh, and it does not set windowsHide anywhere. Only cwd, env, stdio, and detached are set there. So your finding is accurate down to the exact file. Your workaround and fix ideas both make sense.

[xswt442-cmd]

Thanks for taking the time to dig into the source and verify this.
Glad to know the finding checks out and the fix ideas make sense.