Bring Windows and Linux support to macOS parity

[chaqchase]

Summary

Sentinel feels most mature on macOS right now. We should explicitly invest in Windows and Linux support so the desktop/runtime experience, setup flow, and verification quality are on par with macOS instead of being "best effort" on non-mac platforms.

Why this matters

• Platform-specific gaps usually show up in runtime discovery, shell behavior, path handling, packaging, permissions, and desktop window chrome.
• We already have platform branches in runtime discovery (win32 vs POSIX), shell defaults, bundled tool handling, and desktop UI, which is a sign we should treat cross-platform quality as a first-class product area.
• As we add more external runtimes, non-mac regressions will get easier to introduce unless we also raise the QC bar.

Scope

• Improve Windows setup, runtime detection, and execution behavior.
• Improve Linux setup, runtime detection, and execution behavior.
• Audit desktop UI/platform-specific polish so Windows and Linux don’t feel like second-tier ports.
• Add a repeatable QC matrix for both platforms and treat parity as a release quality gate.

High-level implementation overview

1. Audit platform-sensitive paths across runtime discovery, shell/process spawning, local state paths, file permissions, packaged binaries, and desktop window chrome.
2. Fix the highest-friction Windows issues first: executable discovery, PATH/PATHEXT handling, process launch semantics, file permission assumptions, shell command rendering, and installer/setup guidance.
3. Fix the highest-friction Linux issues next: distro variance, PATH/login-shell assumptions, desktop chrome/layout quirks, binary discovery, and environment propagation.
4. Add explicit QC coverage for both Windows and Linux. This should include smoke tests for app launch, workspace open, shell/tool execution, Codex/Claude runtime detection, provider setup, thread creation, repo flows, automations, and settings pages.
5. Document the platform matrix and expected support level so releases are checked against the same standard instead of ad hoc spot testing.

QC expectations

A release should not be considered platform-ready unless Windows and Linux each pass a defined smoke/regression checklist that is comparable to macOS. At minimum, QC should cover:

• Install/launch/update flow
• First-run onboarding and settings access
• Workspace selection and persistence
• Shell/tool execution in a real project
• Git/repo flows
• Runtime detection for external engines
• Provider configuration and chat model selection
• Thread creation, streaming, approvals, and resume behavior
• Visual polish/usability issues in desktop chrome and core navigation

Acceptance criteria

• Windows and Linux each have a documented QC checklist and owner-ready verification flow.
• The biggest platform-specific runtime/setup bugs are fixed or explicitly tracked as follow-ups.
• Desktop UI/platform chrome behaves cleanly on Windows and Linux instead of assuming macOS conventions.
• CI and/or release verification includes meaningful coverage for both platforms.
• New features stop shipping as effectively macOS-only unless a platform gap is explicitly called out.

References

• src/lib/ai/chat/engines/codex-cli.ts
• src/lib/ai/chat/engines/claude-sdk.ts
• src/lib/ai/chat/tools/ripgrep.ts
• src/lib/ai/chat/tools/shell.ts
• src/components/shell/app-shell.tsx
• src/components/shell/sidebar-window-chrome.tsx