Add Windows desktop installer support

[manishiitg]

Goal

Ship a Windows installer for Runloop, not only the current macOS DMG/ZIP release.

Current desktop release path is macOS-focused:

• .github/workflows/desktop-release.yml is named Desktop DMG
• CI builds GOOS=darwin GOARCH=arm64
• Electron packaging runs electron-builder --mac --arm64
• desktop/package.json only defines mac targets (dmg, zip)
• updater/install flow assumes GitHub DMG assets and /Applications/Runloop.app

Desired output

Produce Windows release assets, likely one or more of:

• Runloop Setup <version>.exe via NSIS
• optional .msi later if enterprise distribution needs it
• optional portable .exe for debugging/manual distribution

Major blockers / risk areas

1. Packaging config is macOS-only

desktop/package.json needs Windows config:

• win target (nsis first; maybe msi later)
• .ico icon asset
• artifact naming convention
• release asset validation in scripts/desktop-release.sh
• GitHub Actions upload/release handling for Windows artifacts

2. CI currently builds only macOS ARM binaries

Need Windows builds for bundled Go servers:

• agent-server.exe
• workspace-server.exe

Likely build matrix:

• macOS arm64 existing
• Windows x64 first
• Windows arm64 later only if needed

Need confirm whether Go dependencies build cleanly on Windows, especially anything using CGO/native SQLite/process APIs.

3. Desktop main process assumes macOS update/install flow

desktop/main.js currently has DMG-specific update logic:

• downloads Runloop-<version>-arm64.dmg
• runs shell install script with bash
• assumes /Applications/Runloop.app
• uses macOS dock/menu-bar behavior in several places

Windows needs separate update/install path:

• use electron-updater or Windows-specific installer update flow
• download .exe/NSIS asset, not DMG
• handle app restart/install safely
• avoid macOS-only commands in Windows path

4. Terminal/runtime transport depends heavily on Unix + tmux

This is the biggest functional blocker.

A lot of coding-agent flows rely on tmux for interactive terminal transport, capture, attach, idle detection, and live output.

Windows does not have native tmux. Options to decide:

• require WSL for coding-agent providers that need tmux
• build a Windows ConPTY-backed terminal adapter
• support only non-tmux/structured providers on native Windows initially
• ship a clear unsupported-provider state in UI

This needs explicit product decision because Claude Code / Cursor / Pi CLI integrations may depend on tmux-like behavior today.

5. Shell and process-management assumptions

Audit and replace platform-specific calls such as:

• /bin/bash, /bin/sh, /bin/zsh
• bash -lc
• chmod
• lsof, pgrep, pkill, kill
• POSIX signal/process-tree handling
• macOS open, osascript, dock/menu-bar APIs where not guarded

Windows equivalents may require:

• PowerShell / cmd.exe
• taskkill
• Windows process tree cleanup
• different port-listener detection
• Windows-specific path/env handling

6. PATH and CLI discovery on Windows

Current desktop startup imports login-shell PATH on darwin/linux, but returns empty env on Windows.

Need Windows-specific CLI discovery for:

• Codex CLI
• Claude Code
• Cursor CLI
• Pi CLI
• Node/Python/git if used by workflows
• MCP bridge binaries/tools

Likely need to inspect common install locations and merge user/system PATH from Windows environment/registry where necessary.

7. File paths, permissions, and workspace behavior

Need test path behavior carefully:

• Windows drive letters (C:\...)
• backslashes vs slash-normalized workflow paths
• spaces in paths
• executable suffix .exe
• no Unix executable bit semantics
• symlink behavior and permissions
• long paths
• antivirus/Defender interference with generated executables/scripts

8. Localhost servers and firewall prompts

Runloop starts bundled local servers. On Windows this may trigger firewall prompts or Defender scans.

Need verify:

• localhost binding only
• ports are available and recoverable
• server startup logs are readable from app UI
• process cleanup works after app quit/crash/update

9. Browser tooling / agent-browser binaries

Any bundled or downloaded browser automation binaries need Windows support.

Need verify:

• agent-browser Windows binary availability
• Playwright/Chrome install behavior on Windows
• cleanup/leaked-browser detection uses Windows process APIs
• CDP/local Chrome behavior works without macOS assumptions

10. Code signing and SmartScreen

Windows releases should be signed before broad distribution.

Need decide:

• Authenticode certificate source
• timestamp server
• whether EV cert is needed to reduce SmartScreen friction
• CI secret storage for signing cert/password
• unsigned-dev artifact policy for internal testing

Suggested phased plan

Phase 1: Build artifact only

• Add Windows packaging config to Electron Builder.
• Add GitHub Actions job on windows-latest.
• Build frontend static assets.
• Build agent-server.exe and workspace-server.exe.
• Produce unsigned NSIS installer artifact.
• Do not claim all coding providers work yet.

Phase 2: App launches and core UI works

• Install on clean Windows VM.
• Verify app launches.
• Verify bundled servers start and stop.
• Verify workflow list, files, reports, org dashboard, settings.
• Verify local workspace path creation.

Phase 3: Runtime compatibility

• Decide WSL-required vs native ConPTY strategy for coding agents.
• Validate provider matrix:
  • Codex CLI
  • Claude Code
  • Cursor CLI
  • Pi CLI
  • non-coding LLM providers
• Update UI to show unsupported provider states clearly.

Phase 4: Release-quality installer/update

• Add signing.
• Add Windows update path.
• Add release script validation for Windows assets.
• Add smoke tests and manual QA checklist.

Manual test checklist

• Install on fresh Windows 11 machine/VM.
• Launch app from Start Menu and desktop shortcut.
• Confirm local servers start without firewall/network errors.
• Create/open workflow.
• Use Files pane, reports, Pulse dashboard, org dashboard.
• Run a simple non-coding LLM task.
• Test at least one coding-agent provider based on chosen Windows strategy.
• Quit app and verify no leaked agent-server.exe / workspace-server.exe / browser processes.
• Relaunch and verify schedules/state survive.
• Test update flow once Windows updater exists.

Acceptance criteria

• CI produces a Windows installer artifact.
• Installer launches Runloop on Windows.
• Bundled Go servers start and stop correctly.
• App can open the main UI and load workspace/report views.
• Windows-specific unsupported runtime limitations are explicit in UI/docs.
• Release script and GitHub release validation handle Windows assets.

[manishiitg]

Additional risk areas to include in the Windows investigation:

MCP bridge compatibility

The Windows plan must explicitly validate the MCP bridge path, not just the Electron shell and bundled servers.

Things to check:

• mcpbridge builds as mcpbridge.exe on Windows.
• Coding agents can discover and launch the bridge correctly.
• Bridge env vars and auth headers work with Windows process/env semantics.
• JSON/stdin/stdout transport behaves correctly on Windows terminals/processes.
• Any shell wrappers around MCP bridge do not assume /bin/sh, bash -lc, chmod, or Unix paths.
• Bridge path quoting works when app/workspace path contains spaces.
• Bridge can call the correct local backend endpoint and workspace endpoint.
• Bridge failure messages are surfaced clearly in the UI.

Filesystem access restrictions / OS-level path guards

We also need to audit the file access restriction layer because path enforcement and OS permissions can behave differently on Windows.

Things to check:

• Read/write path allowlists handle drive letters, backslashes, UNC paths, symlinks/junctions, and case-insensitive paths.
• Path normalization cannot be bypassed with .., mixed separators, short names, symlinks, or junctions.
• Workspace guard correctly maps workflow-relative paths to Windows absolute paths.
• Tool calls cannot escape the allowed workspace through Windows-specific path forms.
• Generated file writes, report updates, DB access, backups, and publish staging respect the same restrictions.
• File locking behavior does not break SQLite, report writes, or background agents.
• Antivirus/Defender interference is considered for generated scripts/binaries.

These should be part of the Phase 2/3 manual test checklist before we call the Windows build usable for real workflows.