Repository navigation
feat(windows): add supported acq install path #461
Description
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 | iexThat 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.cmdand/oracq.ps1) that invokes the existing Bashacqimplementation through Git Bash. - Add
install.ps1with dry-run / inspect-first support. - Bootstrap or verify Git for Windows, MSB, and
acqthrough 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
acqis 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
acqsecret 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
acqwithout silently changing system state. acq versionworks 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
docs(adr): propose Windows-native secret storage via DPAPI-encrypted …
docs(adr): propose Windows-native secret storage via DPAPI-encrypted …
docs(adr): propose Windows-native secret storage via DPAPI-encrypted …
docs(windows): describe preview install scope
feat(windows): add Git Bash acq launcher
feat(windows): add PowerShell preview installer
test(windows): cover preview installer contracts
ci(release): publish Windows preview artifact
docs(windows): add manual validation checklist
test(windows): cover release asset wiring
ci(release): include installer in Windows bundle
ci(release): package Windows preview assets
fix(windows): install preview PowerShell script
test: isolate git identity environment
6 remaining items
feat(windows): add acq preview install path (#463)
docs(adr): propose Windows-native secret storage via DPAPI-encrypted …
feat(secrets): add Windows-native DPAPI secret backend (#464)
mogul commentedon Oct 5, 2026
Status:
mogul commentedon Oct 29, 2026
🤖: 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
feat(windows): add acq preview install pathIncrement 2: Windows supported path
fix(windows): port acq provider-input path to Windows/MSYS(path/MSYS portability; includes live Windows 11 Git Bash validation of junction handling andcurrentpublication)acq portsdrops all but the last port when native Windowsjqemits CRLFjqoutput); validated on a real Windows host (CRLF fix confirmed)ps -oandos.O_DIRECTORYgaps); fixes the remaining112-msb-portstest 11 failure found while validating fix(msb): strip CR from jq output in acq ports (Windows) #663; overlaps fix(windows): port acq provider-input path to Windows/MSYS #644 inacq.backends/common.sh.mjsentrypoint guards that silently no-op on Windows and CRLF in fixture normalizersThe 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.