Windows support: cmd-shim CLI spawning, PowerShell dictation, NSIS packaging

[muneeb-rahmani]

Ports OpenMausBot to Windows.

Server: resolve .cmd/.bat CLI shims (claude/codex) and spawn through cmd.exe with proper quoting (server/cli-util.ts); taskkill-based process-tree kill; Windows named-pipe CUA socket.
Electron: platform-safe main process (macOS-only APIs guarded); Windows dictation via a bundled PowerShell System.Speech helper speaking the same NDJSON protocol as the Swift helper.
UI: onboarding/composer/computer-panel perm flows adapt to no-TCC platforms.
Packaging: electron-builder win x64 NSIS + zip targets, icon.ico generation (make-ico.ps1), and platform-guarded native build scripts.
Verified: typecheck, prod build, packaged app launches and serves the UI on Windows.

[milind-soni]

Thanks for the huge effort here — there's real, careful Win32 work in this PR. After deep-reviewing both this and #5 (which solve the same problem on the same files), here's where we landed:

We're basing the Windows port on #5's spawn strategy (now #10, with fixes). The deciding issue is winQuote in server/cli-util.ts: it implements the CommandLineToArgvW layer but not cmd.exe's own parser, which runs first. Concretely: a token containing &/|/^ but no whitespace is passed through unquoted (--model x&calc executes calc), and %VAR% expands even inside double quotes — and on this codebase, user-influenced strings (--append-system-prompt personas, --mcp-config JSON) ride on argv. That's the CVE-2024-27980 class, and resolving shims to their JS entry (no cmd.exe at all) avoids it structurally rather than by quoting harder.

That said, this PR has valuable pieces #5 doesn't have, and we'd love them as focused follow-up PRs on top of the port once it lands:

1. speech-helper.ps1 + the speech.mjs Windows branch — I verified it speaks the same NDJSON contract as the Swift helper, and it's spawned correctly (-NoProfile -NonInteractive -ExecutionPolicy Bypass, hidden). Worth shipping with tempered wording (System.Speech is the legacy SAPI recognizer, noticeably below the macOS on-device quality). This is the only Windows dictation implementation anyone has written — please rebase it as its own PR.
2. build/make-ico.ps1 — clean icon pipeline; just wire it into package:win (right now build/icon.ico is gitignored and nothing generates it during packaging).
3. Routines + macros are a genuinely interesting feature (~half this PR) but they're new product surface, not Windows porting — as a separate PR, with two fixes: macro-record.ps1/macro-replay.ps1 aren't in win.extraResources (record/replay throws in the packaged build), and the /api/routines/:id/run failure path writes two HTTP responses (ERR_HTTP_HEADERS_SENT).

Also for a future revision: dist-server/** shouldn't be hand-edited (it's pnpm build:server output and gets overwritten at package time), and pnpm-workspace.yaml's allowBuilds: isn't a pnpm field — the working mechanism is pnpm.onlyBuiltDependencies in package.json. Main now has a 3-OS CI matrix + test suite (see CONTRIBUTING.md), which should make all of these follow-ups much easier to validate. Thanks again — hope to see the dictation and macros PRs!

[milind-soni]

Heads-up: I pushed a merge of current main to this branch (maintainer edit) to clear the README conflict — resolution keeps your Windows requirements note alongside main's grok CLI addition, with the cmd.exe wording trimmed per the review discussion above. No changes to your code beyond the merge. Main's CI (3-OS matrix) and test suite now run on this PR, which should help when splitting out the dictation / icon / routines+macros pieces.

[milind-soni]

The Windows port this branch introduced has since landed on main through newer, tested implementations, including packaging, dictation gating, named pipes, process-tree cleanup, and desktop capabilities. This older branch would overwrite newer provider and lifecycle work and retains cmd.exe shim execution. Please close it; any remaining shim-resolution work should be rebased as a small no-shell change alongside #41.

[milind-soni]

Thank you for this — the cmd-shim spawning analysis in particular was correct and is essentially how main works today.

Closing as superseded: Windows support landed in #17 (f3bac3a). server/procs.ts is now the single place that knows Windows process differences — it resolves npm shims via a real lookup before spawning (never building a shell string), reaps process trees with taskkill /T since kill(-pid) is POSIX-only, and sets windowsHide so console CLIs don't flash windows. The permission broker uses a named pipe on win32, and NSIS packaging is in electron-builder.yml with installers now built on a Windows CI runner.

Three Windows ports arrived at once and only one could land; that's a scheduling accident, not a verdict on the code. If something here is still missing on main, a focused PR against current main is very welcome.