Skip to content

roadmap(windows): make Windows a supported platform #2142

Description

@liugddx

Problem

Maka can already build and launch its CLI and Electron desktop app on Windows, and the codebase includes Windows-specific paths for named pipes, PowerShell/cmd shell detection, ConPTY, process-tree termination, and filesystem behavior. However, Windows is not currently a supported platform because these paths are not continuously tested or released, and several product guarantees remain platform-specific.

A local Windows baseline on Node 22 found:

  • the full repository build succeeds;
  • script tests can pass after removing POSIX-only assumptions from macOS development helper tests;
  • managed workspace tests require Git for Windows long-path support (core.longpaths=true);
  • the storage suite currently reports 514 pass / 100 fail / 40 skip;
  • most remaining storage failures are EBUSY cleanup failures caused by SQLite handles still owning runtime.sqlite or runtime.sqlite-shm, which POSIX permits unlinking but Windows does not;
  • restricted sandbox profiles fail closed on Windows;
  • computer-use has no Windows backend.

Being able to open the app is therefore not the same as having a tested, secure, releasable Windows product.

Desired outcome

Define and deliver an explicit Windows support tier for Maka. At minimum, supported CLI and desktop workflows should build, test, install, update, recover from crashes, and fail safely on every release. Features that cannot initially be supported, especially sandboxing and computer-use, must be clearly surfaced rather than silently degraded.

Current support status (2026-08-21)

Windows 11 x64 is an active preview target, not a fully supported Maka platform. Phase 0-2 build, baseline, crash-recovery, process-cleanup, and durability evidence are in place. Preview installer/ZIP artifacts, checksum/install documentation, closed-app upgrade/uninstall, automatic update, and the Runtime Host update-handoff fix (#3382, closing #3340) are complete. #3265 has exact-head CI, audit, and Windows rollback evidence green and is waiting for independent human review. Full support still requires signed artifacts, a clean/authoritative Windows baseline, the remaining sandbox security gates, and explicit handling of deferred capabilities such as computer-use.

The packaged AppContainer backend (#2961), production-identity readiness probe, and private-desktop placement/RFC alignment (#3174, including #3161) are on main. They complete the shipped-preview alignment milestone, not the Windows support declaration. The remaining Phase 4 lifecycle evidence promotion, adversarial matrix, and independent human security-review gates below are still open.

Phase 0: establish the baseline

Tracking PR: #2156

  • Document supported Windows versions, architecture, Node version, shell prerequisites, and Git requirements.
  • Run the complete test plan on windows-latest and publish pass/fail/skip results.
  • Inventory every process.platform === 'win32' skip and classify it as POSIX-only, portable, or missing Windows implementation.
  • Add a Windows CLI smoke test and Electron startup smoke test.

Phase 1: continuous Windows correctness

Tracking PR: #2173

Current status (2026-08-08): the combined Node 24 main Windows storage baseline is 703 pass / 6 fail / 47 skip, improved from the original 514 / 100 / 40. The non-blocking baseline lane retains complete diagnostics as artifacts.

Completed Phase 1 failure groups include project-catalog and usage-store SQLite shutdown, portable Codex/sandbox path handling, and deterministic Git worktree retirement on Windows. Current implementation focus is grouped by root cause rather than individual failing tests:

Phase 2: crash and recovery guarantees

Repository administration follow-up:

Phase 3: distribution

Current status (2026-08-21): Windows x64 preview packaging, checksum verification, installation documentation, closed-app upgrade/uninstall, CI-verified automatic updates (#3240), and safe Runtime Host update handoff (#3382) are complete. #3265 now has exact-head CI/audit/Windows rollback evidence green but remains open for independent human review. Signing is still blocked on an Authenticode certificate decision, so the preview is not a signed release channel.

Phase 4: sandbox security

Current status (2026-08-21): #2961 provides the Maka-owned packaged AppContainer backend. #3174 merged the production-identity readiness probe, per-launch private-desktop placement, and EN/zh RFC alignment (fully containing the earlier #3161 work). The supported claim remains limited to a Windows 11 x64 preview with packaged fail-closed enforcement and initial private-desktop placement; it does not claim escape-proof GUI/window-station isolation or make Windows generally supported.

Mechanism-level cancellation, parent-death, concurrency, Job drain, and ACL-ledger recovery evidence exists, but the lifecycle checkbox remains open until that evidence is promoted to a required packaged/per-release gate and the cross-boundary/soak gaps below are covered.

Windows sandbox support remains preview-only until the remaining lifecycle, adversarial, documentation-alignment, and independent-review gates are complete.

Phase 5: computer-use

  • Define a Windows backend using UI Automation plus an appropriate capture API.
  • Design consent, secure-desktop, elevation, multi-monitor, scaling, and session-lock behavior.
  • Reuse the platform-neutral computer-use host event contract.
  • Add Windows-specific integration and end-to-end evidence.

Support criteria

Windows should be advertised as supported only when:

  • the supported CLI and desktop workflows pass on a clean Windows CI runner;
  • no required feature silently falls back to an unenforced security boundary;
  • crash recovery and process cleanup have release evidence;
  • signed install and update artifacts are published;
  • unsupported or deferred capabilities are explicit in-product and in documentation.

Alternatives or workarounds

Today, developers can run the CLI directly and launch the Electron desktop app in development mode on Windows. WSL2 can provide a Linux execution environment for some workflows. Neither workaround supplies a native Windows release, Windows sandbox enforcement, Windows computer-use, or release-level regression coverage.

This umbrella issue is intentionally phased. CI, storage lifecycle correctness, and distribution can proceed before the sandbox and computer-use projects, while the support criteria prevent partial availability from being mistaken for full platform support.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions