Local report generation (ACP) fails on Windows: ENOENT or EINVAL spawning codex-acp/claude-code-acp

[tony-ipnet-vivo]

Environment

• OS: Windows 11 (10.0.26200)
• Node: v22.23.1 (also reproduced on v24.18.0) via nvm-windows
• vibe-log-cli: 0.8.14
• Shell: PowerShell

Steps to reproduce

1. npm install -g vibe-log-cli@latest
2. vibe-log, select a local productivity report, choose either "Generate with Codex via ACP" or the Claude Code ACP option.
3. Report generation starts, pre-fetches sessions successfully, then crashes when spawning the ACP adapter process.

Actual behavior

With the codex-acp shim as normally installed by npm on Windows, resolveExecutableFromPath (src/utils/acp-executor.ts) uses where <command> to find the binary. where returns the extensionless POSIX shell shim first:

C:\...\node_modules\.bin\codex-acp
C:\...\node_modules\.bin\codex-acp.cmd

spawnAcpConnection then calls spawn(commandPath, ...) on the extensionless shim (a #!/bin/sh script), which Windows CreateProcess cannot execute:

Error: spawn C:\...\node_modules\.bin\codex-acp ENOENT

As a workaround I renamed the extensionless shims out of the way so where would resolve to the .cmd file instead. That changes the failure mode but does not fix it — spawn() is called without shell: true, and Node's child_process on Windows requires shell: true (or going through cmd.exe /c) to execute .cmd/.bat files:

Error: spawn EINVAL

So local ACP report generation is broken on Windows regardless of which of the two resolved paths ends up being used.

Expected behavior

Local report generation via ACP should work on Windows for both the Claude Code and Codex providers.

Suggested fix

In spawnAcpConnection (src/utils/acp-executor.ts), when process.platform === 'win32', either:

• pass { shell: true } to spawn(), or
• resolve/prefer the .cmd shim explicitly and spawn it via cmd.exe /c "<path>" <args>, or
• use a cross-platform spawn helper (e.g. cross-spawn) that already handles this Windows quirk.

Happy to test a fix if useful.