Windows: dsh plugin add splits paths with spaces, and hook bridges fail open silently

[wenqifu]

Two Windows issues found while evaluating dsh on Windows 11, both reproduced on 47f94385 with Node 24.19.0. Posting here since CONTRIBUTING.md asks for Discussions rather than PRs.

1. dsh plugin add splits a package path that contains a space

apps/cli/src/plugin.ts calls spawnSync('pnpm', args, { shell: process.platform === 'win32' }). With shell: true and CMD, Node sets windowsVerbatimArguments, so the argv is concatenated into one unquoted command line and cmd re-tokenizes it.

dsh plugin --profile web add "D:\Repo Clones\lhh010\dsh-minigames"

installs two dependencies, Repo and a broken link:Clones\lhh010\dsh-minigames, then prints the misleading Repo declares no dsh.bundle warning. Staging the package at a space-free path works around it. Relative specifiers also resolve against the caller's cwd rather than the profile directory, which surprised me separately.

One fix that passes here removes shell: true and spawns the command processor directly, so Node applies its own quoting:

export function buildPnpmSpawn(
  anchored: readonly string[],
  platform: NodeJS.Platform,
  comspec: string | undefined,
): { command: string; args: readonly string[] } {
  if (platform !== 'win32') return { command: 'pnpm', args: anchored }
  return { command: comspec ?? 'cmd.exe', args: ['/d', '/s', '/c', 'pnpm', ...anchored] }
}

with runPlugin calling spawnSync(command, pnpmArgs, { cwd: dir, stdio: 'inherit' }) and no shell option. A four-case regression test on that builder passes locally; happy to paste it if useful.

2. Hook bridges fail open on Windows, silently, for any hook that invokes an interpreter

packages/hooks/hooks-claude-code runs a hook's command through the host shell. On Windows that is PowerShell, which does not adopt a native child's exit code as its own process exit code:

powershell -NoProfile -Command "py -3 hook.py"                     # exits 1 when hook.py exits 2
powershell -NoProfile -Command "py -3 hook.py; exit $LASTEXITCODE" # exits 2

Since a non-2 exit is classified as a non-blocking error, a PreToolUse deny hook is skipped and nothing reports it. Verified by canary in the headless profile: the identical hook blocks with the suffix and does not block without it, so a user can have a hook config that loads, runs, and enforces nothing.

A bash-idiom hook fails harder, because PowerShell parses the whole command before running any of it. With echo MARKER > file; echo x >&2; exit 2, the marker file was never written: >&2 is not valid PowerShell, so the leading write never executed either.

Suggestion: either run hook commands through a shell that propagates child exit codes, or document the trailing ; exit $LASTEXITCODE requirement in both bridge READMEs. The Codex bridge README already lists commandWindows as ignored, which is a related trap for anyone bringing an existing config over.

Happy to provide full patches or the canary scripts if that would help.

[sjh9714]

Excellent report, and the canary methodology on part 2 is the right way to prove it. Your PowerShell finding is the runtime half of a wider class in that bridge, "a config that loads, runs, and enforces nothing". I measured the config half against the same source and there are two more surfaces, one of which is fully silent.

Silent. Events outside the supported seven are never read.

parseClaudeCodeConfig iterates the supported list, not the user's map:

const CLAUDE_EVENTS = [
  'SessionStart', 'UserPromptSubmit', 'PreToolUse', 'PostToolUse',
  'Stop', 'SubagentStart', 'SubagentStop',
] as const

for (const event of CLAUDE_EVENTS) {
  const rawGroups = hooksMap[event]
  ...
}

So a Notification, PreCompact or SessionEnd group in a carried-over settings.json is not skipped with a warning, it is simply never visited. The config loads clean, the log says nothing, and the hook never fires. Same end state as your exit-code case, reached at parse time instead of run time.

Not silent, credit where due. Non-command hook types do warn, skipping unsupported "<type>" hook on <event> (only command hooks run). That one is handled well.

Silent in a different way. A matcher can be valid and still never select anything.

matcherDiagnostic only rejects patterns that fail to compile:

if (mode === 'claude-code' && CLAUDE_LITERAL.test(pattern)) return undefined
return compileRegex(pattern) === undefined ? `invalid ${mode} regex matcher ...` : undefined

Bash passes CLAUDE_LITERAL and is therefore accepted without a diagnostic, but DSH's tool names are lowercase, so a Claude Code matcher: "Bash" selects nothing forever. That is #582, and the validation as written cannot catch it because the pattern is not invalid, only inapplicable.

Taken together with your finding, there are four ways to end up with an enforcing hook that enforces nothing, and only one of them warns:

Surface	Warns?
Event outside the seven	no
Non-command type	yes, at load
Matcher case mismatch (#582)	no
Windows exit code not propagated (yours)	no

On your suggestion, documenting the trailing ; exit $LASTEXITCODE would help, but a load-time diagnostic covering all four would help more, since every one of these is knowable before a single hook runs. If you file the Windows patch I would happily add a config-side counterpart.

Disclosure, I ran into these building a Claude Code to DSH migration tool, so it now names dead hooks before you move them. The measured notes live at https://github.com/sjh9714/dsh-movein/blob/main/docs/compat.md if useful. Your Windows canary is the piece I did not have, thanks for posting it.

[weijiafu14]

第 2 条的 canary 方法论确实是证明这类问题的正确做法（@sjh9714 说得对）。我想把这一条的诉求形状往前推一步——因为按现在的提法修完，同一个洞还会以别的形式回来。

"补一个 ; exit $LASTEXITCODE" 治不住这个类

你给的两条建议是：

either run hook commands through a shell that propagates child exit codes, or document the trailing ; exit $LASTEXITCODE requirement

两条都对，但它们修的是这一次的原因（PowerShell 不继承原生子进程退出码），而这个洞的形状是别的东西：

一个 PreToolUse deny hook 被跳过了，而且没有任何东西报告这件事。

也就是说：桥拿到了一个它无法确定含义的退出码，然后把它归类成"非阻塞错误"——在不确定的时候选择了放行。

@sjh9714 补的那条更能说明问题：Notification / PreCompact / SessionEnd 这些事件组根本不会被遍历，配置加载得干干净净、日志一个字不说、hook 从不触发。原因完全不同（一个是运行时退出码，一个是解析时事件名），结果一模一样：一份"加载了、跑了、什么都没拦住"的配置。

所以真正该提的是：

当一个 enforcement hook 的裁决无法确定时，默认必须是阻塞，不是放行。

这条为什么值得单独立：

• 它与 shell 无关。今天是 PowerShell 不传退出码，明天可能是某个 shell 吞了信号、某个包装器改写了退出码、或者一次超时。每换一种，; exit $LASTEXITCODE 就得重打一遍补丁；而"不确定就拦"一次覆盖全部。
• 它方向正确。这是一个安全控制。安全控制 fail open 是缺陷本身，跟触发它的具体 bug 无关。用户配了 deny hook，说明他明确表达过"这里要拦一下"——在系统搞不清楚状态的时候把它当成"放行"，是把用户的意图反过来执行。
• 它让剩下的问题变得可见。fail closed 之后，PowerShell 那个退出码问题会变成"我的 hook 现在总在拦"，用户当天就来报；而现在它是"我的 hook 从来不拦"，没有人会来报，因为没有任何现象。

同理，@sjh9714 那条解析时的洞对应的是：遇到不认识的事件名要 warn，不能静默跳过。他自己也点出了对照——非 command 类型的 hook 是会 warn 的，说明这个惯例在同一个文件里就有先例，只是没覆盖到事件名这一层。

一个可以立刻做的自查（给读到这帖的人）

在等修复期间，你的 canary 方法本身就是最好的运维手段，而且值得固化：

准备一个必然阻塞的 hook（比如无条件 exit 2），挂上去，跑一次会被它拦的动作。拦住了，说明这条链路是通的；没拦住，说明你所有的 hook 现在都是摆设。

这个检查值得在每次改 hook 配置之后、每次升级之后都跑一遍——因为它验证的是"我的 enforcement 还活着吗"，而这件事今天没有任何其它信号。

（这一条和我们自己的一条规矩同源：我们的发版回归里，装完必须回读装到的那份再和期望比对。起因是有一次 dsh plugin add 因为过期的 registry 缓存装到了旧版本，我据此"发现"了两个几周前就不存在的 bug，差点照着假象改代码。任何"我以为它生效了"的环节，都值得有一个能证伪它的探针。）

第 1 条：你那个修法看着是对的，另外你顺带提的那句可能是第三个 bug

shell: true + CMD 触发 windowsVerbatimArguments、argv 被拼成一条未加引号的命令行——这个链条和你的修法（直接 spawn cmd.exe /d /s /c，让 Node 自己做引用）都成立。

我想说的是你括号里那句：

Relative specifiers also resolve against the caller's cwd rather than the profile directory, which surprised me separately.

这个可能比空格那条影响更广，因为它不需要路径里有空格就能触发，而且失败形态更隐蔽：装上去了，只是装的不是你想的那个东西。建议把它从括号里拿出来单独列成第 3 条——你现在这个帖子里，它是唯一一个连复现步骤都没写的发现，最容易被漏掉。

（顺带提醒一句 profile 目录的纪律：profile 的组合安装是 CLI 的私有流程，它会按 bundle 关系重算依赖集。所以排查这条时别在 profile 目录里裸跑 pnpm install 去对照，那会让 profile 状态和 CLI 的认知对不上，反而制造出新的假象。要对照就重跑 dsh plugin add。）

边界与利益相关

我们不修 DSH 自家组件——apps/cli/src/plugin.ts、hooks-claude-code 桥都在 DSH 里。上面全是意见和运维建议，没有一条是我能替你落地的。我没有在 Windows 上复现过你这两条（我在 macOS），第 1 条的机制是按你给的代码和 Node 的公开行为读的，第 2 条我完全采信你的 canary。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——你踩的是 DSH 自己的 CLI 和 hook 桥，换任何插件都不会让 dsh plugin add 正确处理带空格的路径。