## Summary
- AppImage bundles an older `libsystemd.so.0` that shadows the system
copy after `libmount` is already removed
- on systemd ≥ 251 (Arch, Fedora 41+, etc.) launch fails with
`LIBSYSTEMD_251` not found
- add `libsystemd.so*` to the existing removal list in `fix-appimage.sh`
Closes#2335
## Test plan
- [ ] rebuild / repack an AppImage with the updated script
- [ ] launch on a distro with systemd ≥ 251 without `LD_PRELOAD`
workaround
Made with [Cursor](https://cursor.com)
Signed-off-by: Taksh <takshkothari09@gmail.com>
## Summary
Introduces a single effective-config resolver that makes agent
definitions authoritative for model, provider, system prompt, and
relay-mesh routing on linked instances. Stale materialized record bytes
are never consulted at spawn, deploy, readiness, hash, card summary, or
mesh preflight.
**Resolution semantics (field-specific):**
- **model/provider (linked):** definition → global. `None` = inherit
global default. Record value never consulted.
- **model/provider (definition-less):** instance → global.
- **system_prompt (linked):** strictly from definition; blank = no
prompt. No global tier for prompt.
- **system_prompt (definition-less):** from the instance.
- **relay-mesh preflight (both):** driven by the same
`resolve_effective_config` resolution spawn's mesh env consults. For a
linked instance the record's own `provider`/`model`/`relay_mesh` bytes
are never consulted; for a definition-less instance with no provider of
its own, the legacy marker and env preset are the last fallback (see
below).
- **Orphaned (linked record, definition missing):** spawn, deploy, and
mesh preflight blocked with actionable user-facing error.
**Changes:**
- New `effective_config` resolver module with `ConfigSource` metadata
(`definition`, `global`, `instance_legacy`)
- All consumers routed through the single resolver: local spawn, deploy,
readiness, spawn hash, card summary, relay-mesh preflight (interactive
start and restore-on-launch)
- `apply_persona_snapshot` no longer preserves stale record
model/provider when definition is blank
- Backend `update_managed_agent` blocks model/provider/prompt writes for
linked records
- Frontend omits model/provider/systemPrompt submission for linked
instances; system prompt override hidden
- `model_source` field added to `ManagedAgentSummary` so card labels
distinguish inherited (`Default model (X)`) from explicit
- Spawn hash now digests resolved model/provider (not raw record fields)
so global default changes trip the restart badge even for runtimes
without `model_env_var`
- Orphan spawn/deploy/mesh-preflight blocked with jargon-free error
("This agent's configuration is missing — it may still be syncing or was
deleted on another device")
- `EffectiveAgentConfig::relay_mesh_model_id()` and
`resolve_effective_relay_mesh_model_id()` added; both mesh preflights
(`start_local_agent_with_preflight`, `restore_managed_agents_on_launch`)
call this instead of the deleted
`relay_mesh_config`/`relay_mesh_model_id` record-byte sniffs
- Legacy relay-mesh records keep their mesh routing. Two shipped
generations predate `provider: "relay-mesh"` and are never rewritten on
load: the typed `relay_mesh` marker (added when `ManagedAgentRecord` had
no `provider` field), and before it the mesh preset written directly
into `env_vars`. `resolve_definition_less` falls back to the marker,
then to the env preset, so these records still resolve to mesh instead
of silently misrouting to an unrelated provider while their stale env
bytes reach the child. The fallback is skipped when the record carries
an explicit `provider` — that states current intent, including a switch
away from mesh — and `resolve_linked` has no legacy fallback at all
- The env discriminator accepts both spellings of the two sentinels
renamed in the Jun-11 window without a record migration: the provider
env key (`BUZZ_AGENT_PROVIDER`, previously `SPROUT_AGENT_PROVIDER`) and
the api-key value (`buzz-mesh-local`, previously `sprout-mesh-local`).
Each is independent, since a record can straddle the window; the current
provider-key spelling wins when both are present
- Dead `persona_field_with_record_fallback` and wrapper
`persona_snapshot_with_agent_config_fallback` deleted; callers use
`persona_snapshot` directly
- New resolver/deploy/hash/write-guard/mesh-preflight tests, including
switch-away and global-inheritance regressions for both mesh preflight
call sites, per-class legacy-mesh resolution (typed marker and env
preset, in every rename-window spelling combination), and the paired
assertions that a linked instance's legacy mesh bytes stay inert
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
## Summary
- Deletes 6 orphaned files in `desktop/src/features/agents/ui/` (556
lines) that formed a closed cluster with zero imports from the reachable
module graph — orphaned by the 1B dialog consolidation
(`PersonaCatalogSurface`, `PersonaCatalogSection`,
`PersonaCatalogDetailsSheet`, `PersonaCatalogSelectionBadge`,
`PersonaIdentity`, `PersonaLibraryEntryPoints`).
- Removes a stale `check-file-sizes.mjs` override entry for the
no-longer-existent `PersonaDialog.tsx`.
Verified dead two ways: import-graph reachability walk from all entry
points puts all six outside the reachable set, and `tsc --noEmit` passes
clean after deletion. Their `data-testid`s have zero references outside
the cluster. `PersonaCatalogDialog.tsx` is alive (`AgentsView` imports
it) and stays.
Independent of #1968 — pure dead code removal, no behavioral change.
Ubuntu Doctor reports `Install failed at verify: The installer finished,
but Buzz still could not use claude-code (observed: CLI missing)` while
the `cli` step shows success. The `cli` step is lying.
## The masking
Every CLI install command is a pipe — `curl -fsSL
https://claude.ai/install.sh | bash`
(`managed_agents/discovery.rs:109`), `… | sh` for Codex (`:141`), `… |
CONFIGURE=false bash` for Goose (`:75`). `install_shell_command` ran
them through `bash -l -c` with no `pipefail`, so the pipeline's exit
status was the **right-hand** side's. A `curl` that fails — or that
isn't on the child's PATH at all — feeds `bash` an empty stdin, and
`bash` with nothing to run exits 0:
```
$ /bin/bash -l -c 'curl -fsSL https://nonexistent.invalid/x.sh | bash'; echo $?
curl: (6) Could not resolve host: nonexistent.invalid
0
$ PATH=/tmp/empty /bin/bash -l -c 'curl -fsSL https://claude.ai/install.sh | bash'; echo $?
bash: line 1: curl: command not found
0
```
`run_install_command` records exit 0 as `success: true`, the adapter
step then installs fine (it uses Buzz's own bundled Node, no system PATH
needed), and `post_install_verification` correctly reports the CLI is
absent. The user is handed a `verify` riddle instead of curl's error,
which is why diagnosing this required three rounds of guessing.
Install commands now run under `set -o pipefail`, so the left-hand
side's failure is the step's failure and `InstallStepResult.stderr`
carries the vendor's own message. `SHELLOPTS` is not exported by either
shell, so the piped-to vendor script still runs with its default
options. The Windows PowerShell install path
(`install_powershell_command`) bypasses this shell and is untouched.
## The PATH collapse it was hiding
`install_shell_command` composes the child's PATH and calls
`cmd.env("PATH", …)`, which **replaces** rather than extends.
`should_use_inherited` was `is_windows && !had_shell_path &&
has_local_context`, so on Unix the inherited process PATH was never
appended. When `login_shell_path()` returns `None` — a login shell that
exits non-zero or prints nothing, which a GUI-launched process can
easily hit via `~/.profile` — the child's entire PATH becomes Buzz's two
managed Node dirs. There is no `curl`, `sh`, `sha256sum`, or `tar` in
either, so every curl-pipe install fails, and before this PR it failed
invisibly.
The `is_windows` requirement is dropped: the inherited PATH is the floor
whenever no login-shell PATH was obtained, on every OS. Both existing
suppressions are kept — a login-shell PATH present still suppresses it
(no doubling), and no home/exe context still suppresses it (never
manufacture a PATH from ambient state alone). Inherited entries stay
**last**, so managed dirs keep precedence.
The other caller, `build_augmented_path` (`runtime/path.rs:148`, feeding
agent spawns and CLI probes), reads correctly under the new rule for the
same reason: it only gains the inherited PATH in the case where it would
otherwise hand a child a PATH with no native entries. When a login-shell
PATH exists — the normal case on macOS and Linux — its output is
unchanged, which `unix_shell_path_suppresses_inherited_fallback` pins.
## Scope
This fixes the reporting defect and the PATH floor. The specific
environment failure on the affected Ubuntu box is still being diagnosed
and is deliberately not addressed here; the point of this change is that
the next attempt produces the real error instead of a `verify` riddle.
One interaction worth noting: `install_failure_is_retryable` retries any
failure that carries an exit code, so a pipefail-surfaced curl failure
now gets 3 attempts with backoff — correct for transient network blips,
and harmless for hard failures.
`desktop/scripts/check-file-sizes.mjs` ratchets the `agent_discovery.rs`
ceiling 1836 → 1895 for the added tests.
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
## Summary
- split the managed-agent runtime warehouse into cohesive modules for
process ownership/termination, orphan sweeping, dead-instance reaping,
lifecycle synchronization, and runtime metadata
- preserve the existing `runtime` API through narrow re-exports; helper
bodies and platform `cfg` branches are unchanged apart from
module-qualified visibility
- reduce `runtime.rs` from 2,220 lines on `main` to 908 lines and remove
its temporary file-size override, restoring the standard 1,000-line
ceiling
## Why
`main` failed after stale successful PR checks allowed independent
growth to combine above `runtime.rs`'s 2,216-line override. The earlier
fix in #2974 extracted only 55 lines and left the monolith on a special
ratchet. This replacement includes that extraction but establishes
responsibility boundaries and removes the exception entirely.
## Module boundaries
- `process.rs` — process identity, ownership markers, receipt
validation, and termination primitives
- `orphan_sweep.rs` — same-instance orphan discovery and cleanup
- `instance_reaper.rs` — foreign/dead desktop instance detection and
agent reaping
- `lifecycle.rs` — tracked runtime synchronization and stale record
cleanup
- `metadata.rs` — model/provider metadata resolution
- `runtime.rs` — summary/config/spawn orchestration and composition
## Validation
At `a824fda31eff6ecc0d39ca1b8ea5602a108897e6`:
- pre-push `desktop-check`
- pre-push `desktop-test`
- pre-push full `desktop-tauri-test`: 1,637 passed, 0 failed, 14
ignored; integration + doc tests passed
- `cargo check --manifest-path desktop/src-tauri/Cargo.toml --lib`
- `cargo fmt --manifest-path desktop/src-tauri/Cargo.toml --all --
--check`
- `node desktop/scripts/check-file-sizes.mjs`
Supersedes #2974 and #2930.
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Princess Donut <68157ebd23b3897c1991015c3038658ea916200c67d3a54620b0754d1b92f6e0@buzz.block.builderlab.xyz>
Refs #2062
This carries forward the relay-mesh recovery work from #2304 by @Bartok9
(cherry-picked with original authorship/sign-offs) and adds the
startup/readiness supervision and packaging fixes found while validating
it against a real two-machine Buzz setup.
## From #2304
- Watch the local OpenAI ingress (`:9337`) after launch and re-arm a
stale relay-mesh runtime.
- Require consecutive failed probes before eviction so a transient
inference stall does not cause a cold restart.
- Bound stale-runtime shutdown, preserve runtime identity across the
asynchronous probe, and never evict a concurrent replacement.
- Re-arm only for agents that are actually running; deliberately stopped
agents stay stopped.
- Persist an actionable sentinel error under the managed-agent store
lock and clear only that error after recovery.
- Treat serve-to-client fallback as an intentional fail-safe; configured
serve restoration remains on its existing path.
## Added here
- Use the inference ingress (`:9337`), rather than management port
`:3131`, as Buzz's client-readiness boundary. A usable client no longer
fails or holds agent-save open merely because management startup is
still pending.
- Supervise the embedded SDK startup asynchronously, publish a pending
status while management is unavailable, and keep its mesh identity
alive.
- Avoid racing a replacement while SDK startup still owns the embedded
runtime. If that pending startup later loses ingress while a running
agent still needs it, request a controlled Buzz restart to reclaim the
otherwise-unreachable SDK thread.
- Defer roster-driven replacement while client management startup is
pending.
- Keep post-launch recovery in a dedicated module so the mesh entry
point remains within the desktop file-size gate.
- Explicitly mark generated Unix sidecars executable. On macOS, copying
over an existing non-executable destination preserved its old mode,
causing packaged `buzz-acp`, `buzz-agent`, and tool sidecars to be
reported as missing.
## Validation
Automated:
- `just ci` — passed, including formatting, Clippy with warnings denied,
desktop/web/mobile checks and tests, and builds.
- Full Tauri mesh-feature suite — 1,702 passed, 0 failed, 15 ignored.
- Mesh-feature Clippy with `-D warnings` — passed.
- Release macOS app bundle with `mesh-llm` — built successfully; every
bundled sidecar passed executable-mode and deep code-signature
verification.
Live two-machine E2E:
- M5: released Buzz serving `unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_M`.
- Mac mini: this branch's packaged Buzz running a saved
`buzz-agent`/relay-mesh agent.
- Confirmed `:9337` accepted inference and the saved ACP harness started
with no error while `:3131` was still unavailable.
- Exact inference succeeded before restart (`CORRECTED-MINI-E2E-OK`).
- Bespoke Buzz shut down cleanly in 2.3s, then restored ingress and the
saved harness in 18.8s while `:3131` was still unavailable.
- Exact inference succeeded after restart (`AFTER-RESTART-E2E-OK`).
- A real Buzz `@C55` message traversed desktop → `buzz-acp` →
`buzz-agent` → mini `:9337` → M5 compute and published the requested
reply successfully.
---------
Signed-off-by: Bartok9 <danielrpike9@gmail.com>
Signed-off-by: Michael Neale <michael.neale@gmail.com>
Co-authored-by: Bartok9 <danielrpike9@gmail.com>
Co-authored-by: Michael Neale <michael.neale@gmail.com>
## Why
The Codex adapter install-plan test depended on the process-global
login-shell PATH cache, making it flaky under concurrent or loaded CI
runs.
## What
- Thread an explicit probe PATH through adapter install planning
- Use a controlled PATH in Codex install-plan tests
- Update the existing desktop file-size allowance for the focused seam
## Risk Assessment
Low — production behavior keeps using the same augmented PATH; only
dependency injection and deterministic tests change.
## References
- Failure:
https://github.com/block/buzz/actions/runs/30110680608/job/89539202266
- Validation: `just desktop-tauri-test`; `cd desktop && pnpm check`;
full pre-push hooks
Generated with Codex
---------
Signed-off-by: npub1x4hk035p3p9q39a3fcrd2fe30lpkrhr5dwe0cqzzjphxyyh8m0gsq4vqap <356f67c681884a0897b14e06d527317fc361dc746bb2fc0042906e6212e7dbd1@buzz.block.builderlab.xyz>
Co-authored-by: npub1x4hk035p3p9q39a3fcrd2fe30lpkrhr5dwe0cqzzjphxyyh8m0gsq4vqap <356f67c681884a0897b14e06d527317fc361dc746bb2fc0042906e6212e7dbd1@buzz.block.builderlab.xyz>
Co-authored-by: Codex <noreply@openai.com>
## Why
Installing the Codex, Claude, or Goose desktop app does not install the
command-line harness Buzz needs. The current UI makes that distinction
unclear, links some missing-CLI states to adapter documentation, and can
report a successful install from the installer exit code even when
runtime discovery still fails. On Windows, Buzz also invokes Goose's
Bash installer, which writes the executable somewhere Buzz does not
discover.
## What
- distinguish missing vendor CLIs from missing or outdated ACP adapters
in runtime metadata and UI guidance
- link Codex, Claude Code, and Goose missing-CLI states to their
official CLI installation documentation
- explain in Settings, onboarding, and agent configuration that the
desktop app alone is not sufficient
- use Goose's official PowerShell installer on Windows
- refresh PATH and rediscover the requested runtime after installation,
keeping the control retryable if the runtime is still unavailable
- add Rust and Playwright regression coverage for Windows installer
selection, CLI/adapter guidance, false-success prevention, verified
installs, and onboarding copy
## Risk Assessment
Medium. This changes desktop onboarding and runtime installation
behavior. Successful installs now require the runtime catalog to verify
availability; previously hidden discovery failures will surface as
actionable errors instead of a false success state.
## References
- [Codex CLI installation](https://developers.openai.com/codex/cli/)
- [Claude Code
installation](https://code.claude.com/docs/en/getting-started)
- [Goose
installation](https://goose-docs.ai/docs/getting-started/installation/)
- Follow-up to #2563 and #2587
## Validation
- `just desktop-typecheck`
- `just desktop-test` — 3,455 passed
- focused Rust post-install verification tests
- focused Playwright Doctor/onboarding coverage (in progress; CI and
local sequential rerun will provide final results)
Generated with Codex
---------
Signed-off-by: Atish Patel <atish@squareup.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Goose <opensource@block.xyz>
## Problem
On Windows, `install_shell_command` wraps every install command in Git
Bash `-l -c`, including the Windows-specific `powershell.exe … irm
https://chatgpt.com/codex/install.ps1 | iex` command. A Git Bash login
shell prepends its POSIX dirs (`C:\Program Files\Git\usr\bin`) to PATH,
so when Codex's `install.ps1` shells out to bare `tar -xzf C:\…`, it
resolves Git's GNU tar (`/usr/bin/tar`) instead of Windows bundled
bsdtar. GNU tar parses `C:` as a remote host:
```
tar (child): Cannot connect to C: resolve failed
gzip: stdin: unexpected end of file
/usr/bin/tar: Child returned status 128
/usr/bin/tar: Error is not recoverable: exiting now
Downloaded Codex package archive did not contain the expected package layout.
```
Claude's installer doesn't hit the same failure because it doesn't shell
out to `tar`.
## Solution
On Windows, detect `powershell.exe` install commands and spawn them
natively (`Command::new("powershell.exe")`) instead of routing them
through Git Bash. The discriminator is a case-insensitive prefix check
on the first whitespace-delimited token — minimal and precise.
The native spawn preserves everything `install_shell_command` provides
that applies:
- `NPM_CONFIG_*` / `COREPACK` env strip + managed npm prefix env
- PATH composed from managed Buzz dirs + inherited process PATH (no
POSIX login-shell dirs)
- `CREATE_NO_WINDOW` so no console flash
- stdin null, piped-drain in `run_install_command`
- The retry/backoff/annotate logic is fully shared
The `-Command` body is split correctly at the boundary
(case-insensitive) and passed as a single argument to preserve pipes and
spaces inside the installer script call.
Non-PowerShell commands (e.g. `npm install -g …` adapter steps) continue
through the existing Git Bash path unchanged.
## Tests
6 unit tests:
1. `is_powershell_command` detection (positive + negative)
2. Routing: PowerShell → native spawn on Windows, non-PowerShell → Git
Bash
3. Unix: non-Windows path returns the shell command unchanged
(compile-time cfg)
4. `-Command` body preservation (no bash args in native spawn; body is
single arg)
Full `just desktop-tauri-test` suite: 1627/1627 passing. Windows CI will
validate end-to-end.
---------
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
