Files
buzz/desktop/scripts/lib/acp-node-wrapper.sh
Matt TooheyandClaude Fable 5 64eae442e3 feat(desktop): bundle the ACP bridge tools on Windows
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>
2026-07-15 13:52:14 +10:00

149 lines
6.1 KiB
Bash

# Shared Node wrapper generation for ACP bridge tools staged from npm.
# Sourced by ensure-acp-tools.sh and prepare-acp-tools-resource.sh so the
# wrapper staged into the dev cache and the wrapper bundled into app
# resources cannot drift (a drift would make dev and bundled installs fail
# differently on the same missing/old Node runtime).
#
# Unix targets stage a bash wrapper shim (write_node_wrapper); Windows
# targets stage the compiled buzz-acp-node-launcher as `<binary>.exe` next
# to a `<binary>.shim.json` manifest (write_windows_node_launcher) — Windows
# cannot execute bash shims, and the desktop's command resolution only looks
# for `<binary>.exe`. Both shims enforce the same lock-derived Node engine
# requirement.
#
# acp_target_is_windows <target-triple>
# Whether the Rust target triple names a Windows target.
acp_target_is_windows() {
[[ "$1" == *-windows-* ]]
}
# acp_staged_binary_name <binary> <target-triple>
# The filename a tool's shim is staged under for <target>: the lock's bare
# binary name on Unix, `<binary>.exe` on Windows.
acp_staged_binary_name() {
if acp_target_is_windows "$2"; then
printf '%s.exe\n' "$1"
else
printf '%s\n' "$1"
fi
}
#
# acp_required_node_major <node-engine>
# Prints the minimum Node.js major version implied by a ">=N..." engine
# range, defaulting to 22 when the range is not in that form. Shared by
# the wrapper shim below and the node-runtime.json manifest consumed by
# the app's Node.js runtime doctor check, so the version the wrapper
# enforces at spawn time and the version the doctor reports at setup
# time cannot disagree.
acp_required_node_major() {
local node_engine="$1"
local major
major="$(printf '%s\n' "$node_engine" | sed -n 's/^>=\([0-9][0-9]*\).*$/\1/p')"
if [[ -z "$major" ]]; then
major=22
fi
printf '%s\n' "$major"
}
# write_node_wrapper <wrapper> <entrypoint> [node-engine]
# Writes an executable bash shim at <wrapper> that verifies a Node.js
# runtime satisfying <node-engine> (default ">=22") is on PATH, then
# execs node on <entrypoint>. An absolute <entrypoint> is embedded
# verbatim; a relative one is resolved against the wrapper's directory
# at run time.
write_node_wrapper() {
local wrapper="$1"
local entrypoint="$2"
local node_engine="${3:->=22}"
local required_node_major
required_node_major="$(acp_required_node_major "$node_engine")"
mkdir -p "$(dirname "$wrapper")"
{
printf '#!/usr/bin/env bash\n'
printf 'set -euo pipefail\n'
printf 'if ! command -v node >/dev/null 2>&1; then\n'
printf ' echo "%s requires Node.js %s on PATH." >&2\n' "$(basename "$wrapper")" "$node_engine"
printf ' exit 127\n'
printf 'fi\n'
printf 'required_node_major=%q\n' "$required_node_major"
printf 'node_major="$(node -p '\''process.versions.node.split(".")[0]'\'' 2>/dev/null || true)"\n'
printf 'if [[ -z "$node_major" || "$node_major" -lt "$required_node_major" ]]; then\n'
printf ' echo "%s requires Node.js %s on PATH." >&2\n' "$(basename "$wrapper")" "$node_engine"
printf ' exit 1\n'
printf 'fi\n'
if [[ "$entrypoint" == /* ]]; then
printf 'entrypoint=%q\n' "$entrypoint"
else
printf 'wrapper_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"\n'
printf 'entrypoint="$wrapper_dir"/%q\n' "$entrypoint"
fi
printf 'exec node "$entrypoint" "$@"\n'
} > "$wrapper"
chmod +x "$wrapper"
}
# acp_node_launcher_exe <target-triple>
# Prints the path to the compiled Windows launcher shim for <target>,
# building it with cargo when needed (a no-op rebuild when up to date).
# ACP_NODE_LAUNCHER_EXE overrides the build entirely — for callers that
# already built the crate, and for cross-target staging tests on hosts
# without the Windows toolchain.
acp_node_launcher_exe() {
local target="$1"
if [[ -n "${ACP_NODE_LAUNCHER_EXE:-}" ]]; then
printf '%s\n' "$ACP_NODE_LAUNCHER_EXE"
return
fi
# The lib lives at desktop/scripts/lib; the launcher crate is in the repo
# root workspace so the Windows release job's warm target dir is reused.
local repo_root manifest target_dir
repo_root="$(cd "$(dirname "${BASH_SOURCE[0]}")/../../.." && pwd)"
manifest="$repo_root/Cargo.toml"
echo "Building ACP node launcher shim for $target..." >&2
cargo build --release --manifest-path "$manifest" -p buzz-acp-node-launcher --target "$target" >&2
# Resolve the target dir instead of assuming ./target — CARGO_TARGET_DIR
# and .cargo/config redirects are common.
target_dir="$(cargo metadata --format-version 1 --no-deps --manifest-path "$manifest" \
| node -e 'process.stdout.write(JSON.parse(require("node:fs").readFileSync(0, "utf8")).target_directory)')"
printf '%s/%s/release/buzz-acp-node-launcher.exe\n' "$target_dir" "$target"
}
# write_windows_node_launcher <dest-exe> <launcher-exe> <entrypoint> [node-engine]
# Stages the compiled launcher shim at <dest-exe> and writes the sibling
# `<name>.shim.json` manifest the launcher reads at spawn time. Mirrors
# write_node_wrapper's contract: a relative <entrypoint> resolves against
# the launcher's directory at run time. Idempotent — the copy is skipped
# when the staged launcher is already identical, so a re-stage never
# rewrites an .exe a running agent may hold open.
write_windows_node_launcher() {
local dest_exe="$1"
local launcher_exe="$2"
local entrypoint="$3"
local node_engine="${4:->=22}"
local required_node_major
required_node_major="$(acp_required_node_major "$node_engine")"
if [[ ! -f "$launcher_exe" ]]; then
echo "ACP node launcher shim not found: $launcher_exe" >&2
return 1
fi
mkdir -p "$(dirname "$dest_exe")"
if ! cmp -s "$launcher_exe" "$dest_exe"; then
cp -f "$launcher_exe" "$dest_exe"
fi
chmod +x "$dest_exe"
ACP_SHIM_ENTRYPOINT="$entrypoint" \
ACP_SHIM_NODE_ENGINE="$node_engine" \
ACP_SHIM_REQUIRED_NODE_MAJOR="$required_node_major" \
node -e '
const fs = require("node:fs");
fs.writeFileSync(process.argv[1], `${JSON.stringify({
entrypoint: process.env.ACP_SHIM_ENTRYPOINT,
nodeEngine: process.env.ACP_SHIM_NODE_ENGINE,
requiredNodeMajor: Number(process.env.ACP_SHIM_REQUIRED_NODE_MAJOR),
}, null, 2)}\n`);
' "${dest_exe%.exe}.shim.json"
}