[bug]: Claude Code string-form hooks fail on Linux — spawned via cmd.exe (spawn cmd.exe ENOENT)

[maximevct]

Environment

• Package: claude-desktop 1.15962.1-2.0.22 (upstream Claude 1.15962.1, port 2.0.22)
• OS: Ubuntu, native Linux x86_64, Electron 41.5.0
• Install: native Linux Electron (/usr/lib/claude-desktop/...), not Wine

Summary

When the Cowork agent (Claude Code) runs a project hook declared in string form — a command with no args array — the bundled app.asar wraps it in cmd.exe unconditionally, with no process.platform check. On Linux cmd.exe doesn't exist, so the hook fails with:

"$CLAUDE_PROJECT_DIR"/scripts/worktree-setup.sh: Error: Failed to spawn cmd.exe: spawn cmd.exe ENOENT

This breaks any string-form hook on Linux (WorktreeCreate, SessionStart bash …, PreToolUse, …), not just the one above.

Root cause

In the bundled app.asar, the hook command runner (minified fn A5t) builds the spawn target like this (de-minified):

const hasArgs = hook.args !== undefined;
const [cmd, args] = hasArgs
  ? [expand(hook.command), hook.args.map(expand)]          // exec form → run directly
  : ["cmd.exe", ["/d", "/s", "/c", `"${hook.command}"`]];  // string form → cmd.exe, NO platform check
// … later: spawn(cmd, args, { cwd, stdin })

Searchable strings in app.asar: "/d","/s","/c" and process.env.comspec||"cmd.exe".

Note: the standalone Claude Code CLI and the VS Code extension run these same string-form hooks correctly on Linux (e.g. SessionStart: bash … hooks) — only this desktop bundle reaches cmd.exe.

Steps to reproduce

1. Open a project whose .claude/settings.json defines a string-form hook, e.g.:

   "WorktreeCreate": [
     { "hooks": [ { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/scripts/setup.sh" } ] }
   ]

2. In Cowork, trigger it (e.g. create a new worktree session).
3. → Failed to spawn cmd.exe: spawn cmd.exe ENOENT.

Suggested fix (port-side patch)

The string-form branch should use the POSIX shell on non-Windows. A regex patch of app.asar (same spirit as the existing patch methodology, cf. #559) rewriting the hardcoded cmd.exe string-form spawn to "/bin/sh", ["-c", command] on Linux would resolve it. Worth reporting upstream too, so the runner picks the shell from process.platform.

User-side workaround

Declare the hook in exec form (command + args), which bypasses the cmd.exe branch entirely:

{ "type": "command", "command": "${CLAUDE_PROJECT_DIR}/scripts/setup.sh", "args": [] }

(The target script must be executable and have a shebang.)

[github-actions]

Automated draft — AI analysis, not maintainer judgment. This bot won't close issues, apply labels beyond triage routing, or claim fixes are shipped. Findings below are starting points; the code citations are what to verify first.

Looks like the A5t hook-spawner in the upstream bundle unconditionally falls back to cmd.exe for string-form hooks (when A.args is undefined), with no process.platform guard, so every string-form hook on Linux likely fails with ENOENT.

• Looks like the A5t ternary emits ["cmd.exe", ["/d","/s","/c", ...]] in its else-branch whenever A.args is undefined, with no process.platform check, so string-form hooks on Linux attempt to spawn cmd.exe and fail with ENOENT. (reference-source/.vite/build/index.js:407422-407424)
• Appears that A5t — the sole dispatch point that selects the shell for string-form hooks — contains no process.platform === 'win32' guard before the cmd.exe branch, so a POSIX /bin/sh -c path is entirely absent from this function. (reference-source/.vite/build/index.js:407412-407445)
• Worth checking first whether windowsVerbatimArguments: !n further signals that the string-form else-branch was authored exclusively for Windows — in that branch n is false, so this flag resolves to true, a Windows-only spawn option that has no effect on Linux but reinforces the platform assumption baked into the surrounding logic. (reference-source/.vite/build/index.js:407432-407432)

Full investigation artifacts (investigation.json, validation.json) are attached to the triage workflow run.