Skip to content

feat(windows): add supported acq install path #461

Open
3 of 8 issues completed
Open

Description

@mogul

Summary

We want a supported Windows install path for acq so Windows users can get to a working MSB-backed agent environment without cloning the repo manually or reverse-engineering dependencies.

The proposed front door is a PowerShell bootstrap, roughly:

irm https://github.com/GSA-TTS/agentic-coding-quickstart/releases/download/v<version>/install.ps1 | iex

That bootstrap should use WinGet where possible to install acq and its host-side dependencies. The expected dependency chain is acq plus Git for Windows / Git Bash and MSB (microsandbox). MSB remains the initial Windows backend target.

Recommended implementation split

Increment 1: Windows preview install path

Goal: make the install path discoverable and usable for early Windows validation without claiming full native support.

Deliverables:

  • Publish a Windows release artifact, likely acq-windows-x64.zip.
  • Add a Windows launcher (acq.cmd and/or acq.ps1) that invokes the existing Bash acq implementation through Git Bash.
  • Add install.ps1 with dry-run / inspect-first support.
  • Bootstrap or verify Git for Windows, MSB, and acq through WinGet where available.
  • Document Windows 11 + PowerShell + Git Bash + MSB as preview support.
  • Keep scope to the MSB backend initially.
  • Detect Windows and skip or clearly warn on host ssh-agent forwarding if unsupported.
  • Add offline/CI smoke tests for the PowerShell installer and launcher where possible.

Increment 2: Windows supported path

Goal: move from preview to a supportable Windows host experience.

Deliverables:

  • Add real Windows secret storage using Windows Credential Manager, DPAPI, or a small cross-platform helper.
  • Harden Windows path normalization for PowerShell paths, Git Bash paths, spaces, drive letters, mount paths, NAME:path, and port syntax.
  • Validate and document Windows Hypervisor Platform setup, including elevation and reboot requirements.
  • Validate MSB guest creation and acq run opencode <workspace> on real Windows 11 hardware or an equivalent machine with WHP available.
  • Validate GFE/Zscaler/host CA behavior on Windows.
  • Decide whether Windows ssh-agent forwarding is unsupported, warning-only, or implemented through a named-pipe bridge.
  • Wire release automation and WinGet manifests so Windows artifacts are versioned, hashed, and repeatable.

Known obstacles / risks

  • acq is currently Bash-first (#!/bin/bash), so Windows support initially depends on Git Bash rather than native PowerShell.
  • Git Bash / MSYS path and argument conversion can corrupt native Windows arguments unless carefully handled.
  • MSB on Windows requires Windows Hypervisor Platform, which may require an elevated PowerShell window and a reboot.
  • MSB Windows support is documented as preview, so live validation is required before this can be called supported.
  • Current acq secret storage supports macOS Keychain, Linux Secret Service, and file fallback; Windows needs a better storage backend before we should call the path fully supported.
  • Host ssh-agent forwarding currently assumes Unix sockets; Windows OpenSSH/Pageant typically uses services or named pipes.
  • Non-Windows development hosts can cover scripts and unit tests, but cannot complete live validation of WinGet, WHP, MSB create/run, Windows CA trust, or path conversion.

Acceptance criteria

  • There is a documented Windows preview install command.
  • The preview installer can install or verify Git for Windows, MSB, and acq without silently changing system state.
  • acq version works from PowerShell after install.
  • A real Windows 11 validation run can create an MSB sandbox and run an agent against a test workspace.
  • Limitations are documented honestly until the supported-path increment is complete.
  • The final supported path avoids plaintext-ish secret fallback on Windows and has live Windows verification evidence.

Notes

This issue is intentionally a heads-up and tracking point for the Windows support effort. The implementation should proceed in the two increments above rather than trying to make the first package publication carry the full supported-host claim.

Activity

  1. self-assigned this
    on Sep 11, 2026
  2. 6 remaining items

  3. added theissue type on Oct 1, 2026
  4. mogul commented on Oct 5, 2026

    @mogul
    ContributorAuthor

    Status:

    • Increment 1: Windows preview install path
    • Increment 2: Windows supported path (in progress)
  5. mogul commented on Oct 29, 2026

    @mogul
    ContributorAuthor

    🤖: AI agent (OpenCode), posting on behalf of @mogul. Linking the work tracked under this epic so it is discoverable from here. The items below are also attached as native sub-issues; PRs and the cross-repo item cannot be sub-issues, so they are listed here.

    Increment 1: Windows preview install path

    Increment 2: Windows supported path

    The two directory-symlink tests in #644 are still unverified on a Developer-Mode or elevated host.

    This is a tracking comment only; it does not close anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions