The windows-x86_64 build was the one supported target left out of the
ACP bundling series: no lock entries, no staged resources, and — since
the series made the claude/codex catalog entries platform-unconditional
(empty install commands, "ships with the Buzz desktop app" hint) — a
Windows user without their own claude-agent-acp hit a dead end that
reinstalling could never fix. Everything upstream already exists (both
bridges publish win32-x64 native packages; the release job already runs
under Git Bash; the desktop's resolution/spawn layer is Windows-aware),
so extend the bundle to Windows. The one genuinely Windows-shaped
problem is the runtime shim: the staged bridges are bash wrappers that
Windows cannot execute — and the resolver only looks for <binary>.exe
anyway. Solve it with a tiny compiled launcher instead of .cmd shims,
which would have rippled a two-candidate list (.exe, .cmd) through the
shared resolution code and left an intermediate cmd.exe in the spawn
chain that kill_on_drop cannot reap through.
- New root-workspace crate buzz-acp-node-launcher: reads the sibling
<binary>.shim.json ({entrypoint, nodeEngine, requiredNodeMajor})
written by the staging scripts, resolves node from PATH, enforces the
lock's Node major with the exact wrapper-shim error message and exit
codes (127 missing / 1 too old), then runs node on the vendored
entrypoint, proxying stdio and the exit code. On Windows the child
joins a Job Object with KILL_ON_JOB_CLOSE (mirroring buzz-dev-mcp's
KillGroup) so terminating the launcher — as buzz-acp's kill_on_drop
does — takes the node tree with it; on Unix it execs node like the
bash shim, existing there so workspace clippy/tests pass everywhere.
Unsafe is confined to the Win32 FFI, cfg-forbidden elsewhere, per the
buzz-dev-mcp precedent.
- update-acp-tools-lock.mjs gains x86_64-pc-windows-msvc (npmOs win32,
npmCpu x64, no libc; native executables claude.exe and
vendor/x86_64-pc-windows-msvc/bin/codex.exe). The committed lock
grows 8 -> 10 entries via a partial --target run: the two new
Windows pins match the other targets' versions exactly (0.58.1 /
1.1.2, sdk 0.3.205, codex 0.144.1-win32-x64) and the existing 8
entries are preserved byte-identically.
- The staging scripts branch per target family through the shared
wrapper lib: Unix targets keep the bash wrapper; Windows targets
stage the launcher as <binary>.exe next to <binary>.shim.json
(write_windows_node_launcher). The launcher builds via cargo on
first use (ACP_NODE_LAUNCHER_EXE overrides; target dir resolved via
cargo metadata, never ./target), a target with no locked tools still
stages nothing without needing cargo, and dev-cache shims embed
bin-dir-relative entrypoints because Git Bash absolute paths
(/c/Users/...) are unresolvable to a native exe. The freshness path
re-copies the launcher when the built binary changes (cmp-gated: a
running agent's open .exe is never rewritten), the prune reduces
<binary>[.exe][.stamp] and <binary>.shim.json to the lock's bare
binary name, and harness-clis.json drops the .exe suffix from its
cli keys so the app's bare-name auth probes ("claude", "codex")
resolve the vendored CLIs on Windows too.
- release.yml's Windows job needs no extra wiring: the staging step
added with the previous commit now finds lock entries and builds the
launcher with the job's already-installed MSVC toolchain. The
windows-rust CI job gains a cargo test step for the launcher so its
spawn path gates on a real Windows runner.
Per the plan's risk note, codex-on-Windows maturity is a validate-
before-release concern: the lock's per-tool-per-target shape allows
dropping the codex-acp windows entry if a real session shakes out
badly. win32-arm64 packages exist but there is no arm64 Windows
release job; deferred until one exists. Node.js stays a user
prerequisite, surfaced by the existing node-runtime Doctor section.
Verification (macOS host):
- cargo test -p buzz-acp-node-launcher: 9 passed — manifest parsing,
version parsing, path resolution, plus end-to-end launcher runs
(arg/stdio/exit-code proxying via real node, missing-manifest,
missing-entrypoint, and too-old-Node failures with the wrapper-shim
message). cargo clippy --all-targets -D warnings and
cargo fmt --all --check: clean.
- Cross-staged the Windows target end-to-end with
ACP_NODE_LAUNCHER_EXE standing in for the MSVC launcher: both win32
npm trees install and validate against the lock (integrity + X_OK on
the vendored claude.exe/codex.exe, confirming the locked vendor
paths), bin dir stages <binary>.exe + .exe.stamp + .shim.json with
relative entrypoints, re-run performs zero installs, stray
.exe/.shim.json artifacts are pruned, and prepare writes
harness-clis.json with bare "claude"/"codex" keys mapping to the
vendored .exe paths.
- Empty-target Windows staging (aarch64-pc-windows-msvc) exits 0 with
the notice, without cargo on PATH.
- Darwin re-stage after the cross-stage: bash wrappers report 0.58.1 /
1.1.2, manifests back to darwin shape — Unix staging unregressed.
- biome check on update-acp-tools-lock.mjs: clean.
Windows-runner validation (NSIS install, Doctor states, live claude +
codex sessions, auth probes against the vendored CLIs) needs a real
Windows machine and rides the first release train with these entries.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
The bundling series wired ACP tool staging into `just dev`, `just
staging`, and `just desktop-release-build`, and flagged the internal
sprout-releases pipeline as follow-up — but the OSS release workflow
was missed entirely. None of release.yml's four platform jobs ran
prepare-acp-tools-resource.sh before `pnpm tauri build`, so every OSS
release artifact (DMGs, deb/AppImage, NSIS installer) shipped an empty
resources/acp: the app silently fell back to unpinned user-installed
bridges, which is exactly the drift the bundling series exists to
prevent, while the catalog's "ships with the Buzz desktop app…
Reinstall Buzz" copy pointed users at a reinstall that could never fix
it.
Add a "Stage bundled ACP tools" step to all four jobs, after the
sidecar build and before the Tauri build (tauri.conf.json already
bundles resources/acp):
- macOS arm64 / Intel and Linux stage their target's pinned npm trees
and bash wrapper shims; node + npm come from the already-activated
hermit toolchain.
- Windows runs the same script under Git Bash (the job already runs
every step with `shell: bash`; node comes from setup-node). The lock
currently pins no windows-msvc entries, so the step is a visible
no-op — ensure-acp-tools.sh prints its empty-target notice to the
build log and stages nothing — until the Windows bundling lands.
Ensuring the staging scripts run before every `tauri build` invocation
path was the first work item of the Windows-bundling plan, independent
of the Windows decision itself.
Verification:
- prepare-acp-tools-resource.sh aarch64-apple-darwin: staged wrappers
report the pinned 0.58.1 / 1.1.2 versions (same invocation the new
steps run, on the same runner OS as the arm64 job).
- ensure-acp-tools.sh --target x86_64-pc-windows-msvc (pre-Windows-
bundling lock state): "No ACP tools locked" notice on stderr, empty
staging, exit 0 — the Windows job stays green before the lock gains
windows entries.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
