Drive plan_workspace_activation across the cross-community switch
sequence (apply A, switch to B, switch back to A), asserting the
observable spawn plan at each step. The existing restore tests exercise
begin_relay_activation and record_activates_on_relay as isolated
predicates; these close the coverage gap by proving the composition:
a later apply must not re-spawn A, stop A to serve B, or let a
blank-pinned record float from A to B.
Both core invariants are verified load-bearing by mutation: removing the
already_running exclusion double-spawns a live agent; neutering the
relay filter leaks B's agent into A's plan. Test-only; no production
lines touched.
Co-authored-by: npub1jmc9dt2lyvzu3h0kxlwxt5zg4fxp9476awyxw6gwxn72g6cw7exqs64whm <96f056ad5f2305c8ddf637dc65d048aa4c12d7daeb8867690e34fca46b0ef64c@sprout-oss.stage.blox.sqprod.co>
Signed-off-by: npub1jmc9dt2lyvzu3h0kxlwxt5zg4fxp9476awyxw6gwxn72g6cw7exqs64whm <96f056ad5f2305c8ddf637dc65d048aa4c12d7daeb8867690e34fca46b0ef64c@sprout-oss.stage.blox.sqprod.co>
Resolve the review findings on the lazy multi-workspace agent stack
(review of f3baa96) — four hardening fixes, no behavior change on the
happy path:
- Serialize apply_workspace's .repos-dirs.json upsert on
managed_agents_store_lock. A community relay edit fires
rebind_agent_relay (which moves map entries under that lock) nearly
simultaneously with the reinit apply, and both are read-modify-writes
of the same file — unserialized, one side's update could be lost.
- Write .repos-dirs.json via temp file + rename. A crash mid-write left
truncated JSON, which read_repos_dir_map degrades to an empty map —
silently sending spawns back to the shared REPOS fallback, exactly
the cross-workspace hazard the map exists to prevent.
- Pin the Rust/TS relay-URL normalizers together with a shared fixture
(desktop/fixtures/relay-url-normalization.json) consumed by both
relay tests and agentRelayScope.test.mjs, so an edit that lands on
only one side fails the other side's tests instead of shipping a
scoping skew. Both normalizers' doc comments now point at it.
- Sequence updateCommunity's state commit (and the reinit it triggers)
after the rebindAgentRelay IPC settles. Fire-and-forget let
apply_workspace(newUrl) race ahead of the rebind: activation ran
while start-on-launch agents were still pinned to the old URL and
marked the relay activated for the session, silently skipping them
until app relaunch. A rebind failure still commits — pins stay
recoverable by re-editing the community.
The fifth finding (stale "running in other communities" count) was
already resolved by the slow cross-community poll tier added in
0f8fa7e. Split relay.rs's inline test module into relay/tests.rs
(file-size guard, mirroring repos/tests.rs).
Tested: cargo test --manifest-path desktop/src-tauri/Cargo.toml (1435
passed, incl. the new temp-file and fixture-agreement tests), clippy
--all-targets -D warnings, rustfmt, desktop pnpm test (2955 passed,
incl. the new fixture-agreement test), tsc --noEmit, biome check,
pnpm check:file-sizes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
Make agents immune to the shared REPOS symlink re-pointing on workspace
switches (Phase 4 of lazy multi-workspace agents, building on the Phase
1-3 relay pinning, lazy activation, and UI scoping):
- Persist repos_dir per relay URL in a new .repos-dirs.json nest dotfile
(keys normalized like agent relay pins), written by every
apply_workspace alongside the single-value .repos-dir that keeps
driving the boot-time symlink resolve. The REPOS symlink itself keeps
following the active workspace as a human/tooling convention.
- At spawn, resolve the agent's own workspace entry (keyed by its
effective relay) to a canonical real path and hand it to the child as
BUZZ_REPOS_DIR, so a mid-task switch that re-points REPOS can no
longer land a workspace-A agent in workspace B's checkouts. A
configured-but-unresolvable entry fails the spawn closed (same
rationale as resolve_repos_at_boot); no entry falls back to the nest
REPOS path, preserving pre-map behavior.
- Adjust the nest AGENTS.md instructions (template v5) that referenced
REPOS/ relatively: agents are told to address checkouts through
$BUZZ_REPOS_DIR whenever it is set.
- Hash the raw per-relay map value into the spawn-config hash so a
repos-dir edit badges needsRestart while a pure workspace switch (and
filesystem state alone) cannot.
- Migrate the map entry in rebind_agent_relay when a community's relay
URL is edited, so rebound agents keep their repos-dir isolation.
- Split the grown repos.rs test module into repos/tests.rs (file-size
guard), mirroring nest/tests.rs and spawn_hash/tests.rs.
Tested: cargo test --manifest-path desktop/src-tauri/Cargo.toml (1433
passed, incl. 7 new repos-map/resolution tests and 2 new spawn-hash
tests), clippy --all-targets -D warnings, rustfmt --check, cargo check
--features mesh-llm.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
Extract agent activation out of the one-shot boot restore into a
relay-filtered step that runs on every workspace apply (Phase 2 of lazy
multi-workspace agents, building on the Phase 1 relay pinning):
- Rename restore_managed_agents_on_launch to activate_workspace_agents,
taking the applied workspace relay and starting only local
start-on-launch agents pinned to that relay (normalized match; a blank
pin matches the visited workspace, mirroring the
effective_agent_relay_url defense-in-depth fallback).
- Call it from every apply_workspace instead of only the first — boot
restore becomes the session's first activation. The one-shot
managed_agent_restore_pending flag now gates only the mesh-llm Share
Compute restore.
- Track activated relays in AppState (activated_agent_relays) so each
workspace activates at most once per app session: bouncing A→B→A never
resurrects agents the user manually stopped in A. Nothing is stopped
on switch — each workspace's agents keep running against their own
relay.
- Gate the boot-time repos-dir/identity-recovery safety checks behind a
new session-wide managed_agent_activation_enabled flag, and run the
stale-process/orphan sweeps only on the session's first activation so
a later activation cannot reap a concurrent activation's
not-yet-tracked children.
Tested: cargo test --manifest-path desktop/src-tauri/Cargo.toml (1424
passed, incl. 7 new activation unit tests), clippy -D warnings, rustfmt,
cargo check --features mesh-llm.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
Stop agent records from floating to whichever workspace is active — the
relay URL becomes the backend-side ownership key for agents (Phase 1 of
lazy multi-workspace agents):
- Stamp the resolved workspace relay onto records at create, on an
explicit relay edit that clears the field, and on snapshot/team
imports, instead of persisting blank.
- Migrate legacy blank-relay records on the first apply_workspace after
boot. Behavior-preserving: blank resolved to exactly that relay at
boot restore.
- Add a shared relay-URL normalizer (trailing slash, scheme/host case)
and hash the normalized resolved relay in the spawn-config hash so
cosmetic URL differences no longer trip the restart badge.
- Add a rebind_agent_relay command, invoked by updateCommunity when a
community's relay URL is edited, re-pinning records from the old URL
onto the new one so those agents don't orphan.
effective_agent_relay_url keeps its blank-to-workspace fallback as
defense-in-depth for records that escaped stamping. The pure record
mutations live in the new managed_agents::relay_pinning module.
Tested: cargo test --manifest-path desktop/src-tauri/Cargo.toml (1420
passed), clippy -D warnings, rustfmt, desktop pnpm test (2920 passed),
tsc, biome.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
## Why
On macOS, GUI apps launched from Finder/Spotlight/Dock inherit a minimal PATH from launchd (`/usr/bin:/bin:/usr/sbin:/sbin`). The `discover_provider_candidates()` function in `backend.rs` only scanned this process PATH when looking for `buzz-backend-*` executables. As a result, backend providers (like `buzz-backend-blox`) were never found, and the "Run on" dropdown in Agent Settings was hidden — even though the binary existed both in the app bundle (`Contents/MacOS/`) and in `~/.local/bin`.
## What
Augment the search directories in `discover_provider_candidates()` with:
1. **exe parent dir** (`Contents/MacOS/` in a `.app` bundle) — so bundled providers are always found regardless of how the desktop was launched
2. **`~/.local/bin`** — the conventional location for user-installed provider binaries (symlinks created by install scripts)
Both directories are only added if not already present in PATH (deduplication). The exe parent dir is prepended (highest priority for bundled providers); `~/.local/bin` is appended.
## Verification
- `cargo check --lib` passes
- All 17 `managed_agents::backend` unit tests pass
- Pre-push hook `desktop-tauri-test` passes (38s)
## References
Root cause confirmed by inspecting the running `buzz-desktop` process environment:
```
$ ps eww <pid> | grep PATH
PATH=/usr/bin:/bin:/usr/sbin:/sbin
```
---
Generated with Fizz
