External/buzz - buzz - Gitea: Git with a cup of tea

External/buzz

Fork 0

mirror of https://github.com/block/buzz.git synced 2026-08-18 06:50:31 +02:00

Commit Graph

Author	SHA1	Message	Date
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
Matt TooheyandClaude Fable 5	a29a3da6fe	feat(desktop): pin and stage bundled ACP bridge tools Buzz desktop spawned the claude-agent-acp and codex-acp bridges from whatever the user had installed globally — an unpinned `npm install -g` surface with no integrity checking, which produced stale-bridge drift (the deprecated @zed-industries/codex-acp 0.16.x gate) and missing-tool failures. Bundle both bridges as app resources instead, pinned per target: - desktop/acp-tools.lock.json pins @agentclientprotocol/claude-agent-acp 0.58.1 and @agentclientprotocol/codex-acp 1.1.2 (npm `latest` at time of commit) for the four supported targets, with integrity hashes and Block Artifactory tarballs for the package, its claude-agent-sdk / @openai/codex dependency, and the per-target native package. - desktop/scripts/update-acp-tools-lock.mjs regenerates the lock from the registry's `latest` dist-tags, failing loudly on any unresolvable package — never silently pinning an older version. Ranged dependencies (codex-acp's ^0.144.0) resolve to the highest matching version when `npm view` returns an array. - desktop/scripts/ensure-acp-tools.sh installs the locked tools into a shared dev cache (~/Library/Caches/buzz-dev/acp-tools), validates versions + integrity against the lock, and stamps staged binaries next to the shared bin dir so any lock change — including a revert — forces a re-stage; binaries no longer in the lock are pruned. - desktop/scripts/prepare-acp-tools-resource.sh stages the vendored npm trees + node wrapper shims into desktop/src-tauri/resources/acp, writes the node-runtime.json manifest for the app's Node.js doctor check, and ad-hoc signs every nested Mach-O (file(1) scan — the codex package vendors rg, zsh, and codex-code-mode-host beyond the main CLIs) so Gatekeeper doesn't kill them in local builds. - desktop/scripts/lib/acp-node-wrapper.sh is the single wrapper-shim generator shared by both scripts, so the dev-cache and bundled wrappers (and the Node major they enforce) cannot drift. - Wiring: `just dev` / `just staging` stage the resources and export BUZZ_ACP_TOOLS_DIR; `just desktop-release-build` stages per target before `tauri build`; `just bump-acp-tools` reruns the lock updater; tauri.conf.json bundles resources/acp; staged artifacts are gitignored with a .gitkeep placeholder. Runtime resolution of the staged dir follows in the next commit. The sprout-releases internal pipeline will need the same staging step before its `tauri build`; that lives in a separate repo. Ports the build-time half of the Staged implementation in block/builderbot#876 (branch commits 16b115a7 bundle feature, f5c6bba9 re-stage after lock revert, 288fa7eb shared node wrapper lib, adea4017 node-runtime manifest, 5124302a sign all nested Mach-Os, de6a9782 ranged-dependency updater fix), itself ported from squareup/berd f07df1d2 + 1db993fb + 24d7518b + 07087303 + 737e33a5. Verified: update-acp-tools-lock.mjs regenerated the lock against the Block registry (byte-identical pins to the donor lock; both packages confirmed at npm `latest`); fresh stage installs both tools and the staged wrappers report 0.58.1 / 1.1.2; no-op re-run performs zero npm installs; a stamp/lock mismatch forces a re-stage and stray binaries are pruned; all five staged Mach-Os pass `codesign --verify`; cargo check on desktop/src-tauri passes with the new resources entry. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>	2026-07-15 13:38:21 +10:00

Author

SHA1

Message

Date

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

Matt TooheyandClaude Fable 5

a29a3da6fe

feat(desktop): pin and stage bundled ACP bridge tools

Buzz desktop spawned the claude-agent-acp and codex-acp bridges from
whatever the user had installed globally — an unpinned `npm install -g`
surface with no integrity checking, which produced stale-bridge drift
(the deprecated @zed-industries/codex-acp 0.16.x gate) and
missing-tool failures. Bundle both bridges as app resources instead,
pinned per target:

- desktop/acp-tools.lock.json pins @agentclientprotocol/claude-agent-acp
  0.58.1 and @agentclientprotocol/codex-acp 1.1.2 (npm `latest` at time
  of commit) for the four supported targets, with integrity hashes and
  Block Artifactory tarballs for the package, its claude-agent-sdk /
  @openai/codex dependency, and the per-target native package.
- desktop/scripts/update-acp-tools-lock.mjs regenerates the lock from
  the registry's `latest` dist-tags, failing loudly on any unresolvable
  package — never silently pinning an older version. Ranged
  dependencies (codex-acp's ^0.144.0) resolve to the highest matching
  version when `npm view` returns an array.
- desktop/scripts/ensure-acp-tools.sh installs the locked tools into a
  shared dev cache (~/Library/Caches/buzz-dev/acp-tools), validates
  versions + integrity against the lock, and stamps staged binaries
  next to the shared bin dir so any lock change — including a revert —
  forces a re-stage; binaries no longer in the lock are pruned.
- desktop/scripts/prepare-acp-tools-resource.sh stages the vendored npm
  trees + node wrapper shims into desktop/src-tauri/resources/acp,
  writes the node-runtime.json manifest for the app's Node.js doctor
  check, and ad-hoc signs every nested Mach-O (file(1) scan — the codex
  package vendors rg, zsh, and codex-code-mode-host beyond the main
  CLIs) so Gatekeeper doesn't kill them in local builds.
- desktop/scripts/lib/acp-node-wrapper.sh is the single wrapper-shim
  generator shared by both scripts, so the dev-cache and bundled
  wrappers (and the Node major they enforce) cannot drift.
- Wiring: `just dev` / `just staging` stage the resources and export
  BUZZ_ACP_TOOLS_DIR; `just desktop-release-build` stages per target
  before `tauri build`; `just bump-acp-tools` reruns the lock updater;
  tauri.conf.json bundles resources/acp; staged artifacts are
  gitignored with a .gitkeep placeholder.

Runtime resolution of the staged dir follows in the next commit. The
sprout-releases internal pipeline will need the same staging step
before its `tauri build`; that lives in a separate repo.

Ports the build-time half of the Staged implementation in
block/builderbot#876 (branch commits 16b115a7 bundle feature, f5c6bba9
re-stage after lock revert, 288fa7eb shared node wrapper lib, adea4017
node-runtime manifest, 5124302a sign all nested Mach-Os, de6a9782
ranged-dependency updater fix), itself ported from squareup/berd
f07df1d2 + 1db993fb + 24d7518b + 07087303 + 737e33a5.

Verified: update-acp-tools-lock.mjs regenerated the lock against the
Block registry (byte-identical pins to the donor lock; both packages
confirmed at npm `latest`); fresh stage installs both tools and the
staged wrappers report 0.58.1 / 1.1.2; no-op re-run performs zero npm
installs; a stamp/lock mismatch forces a re-stage and stray binaries
are pruned; all five staged Mach-Os pass `codesign --verify`; cargo
check on desktop/src-tauri passes with the new resources entry.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>

2026-07-15 13:38:21 +10:00