Every subprocess spawn costs 4-6s on Windows — hooks, pwsh, MCP alike, independent of what the process does

[Yebeimu]

Environment
DSH desktop (Electron) on Windows 10, Chinese-localized UI. Four Claude-Code-style hooks configured via hooks.json (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse). All hook commands are D:\Node\node.exe <script>.

Symptom
Every tool call that spawns a subprocess takes 4-6 seconds longer than the work itself. This is steady, not intermittent: 4,298-4,429 ms across 8 consecutive calls (spread 131 ms).

Measurements from one session (37c0c192, ~14 hours of normal use):

Hook duration as recorded by DSH itself (hook/result.durationMs):

• PreToolUse: 324 calls, mean 4,046 ms, total 1,311 s
• PostToolUse: 64 calls, mean 4,024 ms, total 258 s
• UserPromptSubmit: 33 calls, mean 4,310 ms, total 142 s
  => 421 hook spawns, 1,711 s (~28.5 min) spent waiting on hooks alone.

Tool call duration (tool/call -> tool/result), by tool:

• read: 49 calls, mean 4,860 ms (no subprocess involved)
• grep: 11 calls, mean 4,309 ms (no subprocess)
• mcp__dmind__save: 13 calls, mean 4,251 ms (MCP stdio child)
• pwsh: 174 calls, mean 10,621 ms
• Total across all tool calls in the session: 3,058 s (~51 min)

The control that isolates it

1. Same hook scripts run manually from a terminal: block_delete.js 206 ms, post_edit_check.js 51 ms, route_hook.js 51 ms. Twenty to eighty times faster than inside DSH.
2. I temporarily made block_delete.js exit immediately as its first statement (process.exit(0) — zero work), then triggered one tool call. DSH still recorded 4,298-4,429 ms for that PreToolUse hook. So the time is not the script.
3. A pwsh call running just echo 1 took 10 s end to end: 4.4 s PreToolUse hook, then another 6 s from hook completion to tool result. echo 1 itself is milliseconds.

Where I got to in the source
hooks-claude-code/lib/index.js:182 -> hook-protocol runHook() -> await bash.run(bash.resolve(request)) with ctx.shell. durationMs wraps that entire await. So the 4-6 s is inside ctx.shell / the subprocess runner, before and after the child actually works.

Related

• 修复 DSH 兼容性 Hooks 通过 shell bridge 执行导致会话无响应 #5635 proposes running compatibility hooks through ctx.subprocess instead of ctx.shell to fix "session unresponsive" cases, with a runHookOnHost path. It has 0 replies. My case is not a hang — the session recovers every time — but it looks like the same layer.
• A community write-up describes a Windows failure mode where "the runner waits for a launch frame that never arrives and there is no timeout". Mine behaves like a mild version of that: a fixed ~4 s wait, then it proceeds.

Questions

1. Is a 4-6 s fixed cost per subprocess spawn a known Windows issue, or is something in my setup making the runner wait?
2. Is there a config knob (runner timeout, start-frame wait, sandbox mode) that would reduce it? I am on workspace-write.
3. Does the runner do any Windows ACL / sandbox setup per spawn that could account for a fixed multi-second cost? If so, is it cached across spawns?

Numbers table (same as above, for clarity)
hook PreToolUse 324 4046 ms avg 1311 s total
hook PostToolUse 64 4024 ms avg 258 s total
hook UserPromptSubmit 33 4310 ms avg 142 s total
tool read 49 4860 ms avg
tool grep 11 4309 ms avg
tool pwsh 174 10621 ms avg
tool mcp dmind save 13 4251 ms avg
manual block_delete.js 206 ms
manual post_edit_check.js 51 ms
manual route_hook.js 51 ms

[MuriloDPV]

Looking at your numbers, I don’t think the extra time is coming from the tools themselves.

read and grep don’t spawn anything, but they still average about 4.3-4.8 s. That’s almost exactly your PreToolUse average (about 4.0 s), and PreToolUse runs before every tool call. So most of the time on read/grep is the hook, not the tool. pwsh fits the same pattern: about 4.4 s of hook, plus about 6 s for the pwsh process itself (your echo 1 test shows that split).

So it looks like one fixed cost every time ctx.shell starts a process, and pwsh adds its own startup on top. Since node.exe runs your scripts in 50-200 ms from a terminal, my guess is that ctx.shell doesn’t start node directly but goes through a shell first, and that shell is what’s slow to start.

Things I’d check:

Which shell ctx.shell uses on Windows. If it’s PowerShell, compare Measure-Command { pwsh -c exit } with Measure-Command { pwsh -NoProfile -c exit }. If the first one takes around 4 s, your profile or module autoloading is the cost.
Windows Defender real-time scanning. Temporarily add D:\Node and the DSH install folder as exclusions, run a few tool calls and see if the 4 s drops. Remove the exclusions afterwards if it doesn’t help.
Process Explorer (or Task Manager with the command line column) during a hook call, to see if node.exe is a child of pwsh/cmd/bash instead of DSH.

If (1) or (3) shows a shell in the middle, that would also explain why #5635 (running hooks through ctx.subprocess) is the right direction.

[Yebeimu]

You were right, and it turned out to be the whole answer. One correction first: those numbers are from the day the report was filed. I found the shell and fixed it the same day, so the 4–6 s is gone. Details below.

The extra layer is the pwsh wrapper. DSH wraps every command as:

pwsh -NoLogo -NoProfile -NonInteractive -Command "<command>"

Hooks and most tool calls are just "absolute path + arguments", so the wrapper is pure overhead here. It is not the profile and not module autoloading — measured on this machine:

launch	steady-state
pwsh -NoProfile -Command exit	190 ms
pwsh -Command exit (profile loaded)	198 ms
powershell.exe 5.1	132–149 ms
cmd /c exit	31 ms
node -e 0	38–48 ms

-NoProfile saves 8 ms. So your check #1 rules the profile out, and nothing here is close to 4 s — the cost was never one slow shell launch. It was that launch, plus everything the runner does around it, on every single call.

What I changed. PwshLocalExecutor.prototype.argv(spec) returned the pwsh-wrapped argv unconditionally. It now tries a simple split first and connects straight to CreateProcessW when the command is only "absolute path + arguments"; everything else falls back to the original path (pipes, redirects, $, backticks, #, newlines, smart quotes, unbalanced quotes, relative first token, .cmd/.bat/.ps1, --%). Timeouts, buffers and exit-code handling are untouched.

Instrumented breakdown after the change: spawn 12–14 ms + hook script 228 ms + waiting for the output streams to close ~200 ms.

Result, same machine, same version (0.2.1-rc.2):

	PreToolUse hook	read (spawns nothing)
before	4,046 ms mean	4,860 ms mean
after	240–255 ms	177 ms, 144 ms

grep is now 362–395 ms, a python MCP call 151 ms. These are wall-clock times from the session log (tool/call → tool/result) in a fresh session with the fix in place, not estimates.

On your other two checks: Defender exclusions were never tried and are no longer needed. Parent-process inspection (#3) is exactly how I found it — node.exe was a grandchild under the pwsh wrapper rather than a direct child. Your suggestion and #5635 describe the same layer.

Not fully solved: ~1.3 s per call is still there. I traced it to NtCreateUserProcess inside CreateProcessW — the thread is waiting, not computing. That is below the JS layer, so ~240 ms is as far as this approach goes. If that wait is something DSH controls — job-object setup, sandbox ACLs, security-descriptor work done per spawn — fixing it there would get the rest, and I would like to know whether it is.

The patch only exists because of the pwsh wrapping. If hooks ran through ctx.subprocess as #5635 proposes, or if the executor skipped the shell when the command is already an argv, there would be nothing to fix.

[MuriloDPV]

Glad it helped, and nice work on the patch. If my answer was useful, could you mark it as the answer so it's easier to find for people with the same issue?

One thing I didn't get: after the fix you mention 240–255 ms per hook, but also ~1.3 s per call still left. Is the 1.3 s from a different measurement?

[Yebeimu]

Yes — different measurements, and "per call" was too broad. Thanks for catching it.

240–255 ms is one PreToolUse hook: process spawn plus script execution, read off the probe's spawn-enter → spawn-exit pair. It excludes the final wait for the output streams to drain, which is another ~200 ms, so the whole hook is ~440 ms.

~1.3 s is ChildProcess.prototype.spawn inside a tool call that goes through the pwsh wrapper. Three-layer instrumentation on one such call: wall 1360.2 ms, js 1359.2 ms, handle 1359.0 ms — 99.9% of the wall time sits in the spawn, and a minidump taken during the wait has RIP at ZwCreateUserProcess+0x14, called from CreateProcessInternalW. Hooks spawn node.exe directly and take 11–14 ms for that same step.

So the 1.3 s is not a per-call cost. It only appears on calls that go through the shell. Direct spawns — every hook, and any command that is already "absolute path + arguments" — do not pay it.

One correction that matters more than the wording: "the 4–6 s is gone" is true of this machine with the patch applied, not of the release. I re-measured today on 0.2.1-rc.3, where argv() still returns the pwsh wrapper unconditionally:

command	route	wall
D:\Python\python.exe <script path>	direct	466 / 658 / 667 ms
sixteen calls (Get-ChildItem, Get-Content, $var = …) plus a bare exit	through pwsh	4,239–4,665 ms
one Get-ChildItem -Recurse, one command with five nested pwsh launches	through pwsh	7,897 / 8,156 ms (those commands are heavy by themselves)

A bare pwsh -NoProfile -Command exit is 189–213 ms outside DSH (the first run was 1,317 ms — cold start), so the ~4 s is still there in rc.3 for anything that actually needs shell syntax. The patch hides it for argv-shaped commands; it does not remove it.

One detail worth knowing if you try this: the direct path only takes commands whose arguments contain nothing the scanner rejects. D:\Python\python.exe -c "…" is the same executable and still cost 4,506 ms, because the quoted argument sent it back through pwsh.

[Yebeimu]

Follow-up, with today's numbers and the full ruled-out list: #11068

Short version: the answer in this thread was right, and the patch removes that shell layer — but on 0.2.1-rc.3 the unpatched pwsh path still costs 4.2–4.7 s per call, while node.exe, powershell.exe and python.exe spawn through the same sandboxed path in 0.4–0.6 s. The ~1.3 s figure I mentioned came from the patched build, not from the release.