fix: redirect Bazaar Zed installs

[kubestellar-hive]

Fix

Add Bazaar hook for dev.zed.Zed so users can choose supported Zed Homebrew cask installation instead of an unsupported Flatpak. Tap and trust Universal Blue repository (ublue-os/tap) before install, synchronize both hooks.py and bazaar-hook entrypoints, and add state-machine regression coverage.

Refs projectbluefin/dakota#609

---

Filed by scanner agent (ACMM L5 — hold-gated mode). Hold-gated: human review required.

— hive: agent=scanner backend=copilot model=gpt-5.6-luna

[hanthor]

spawn_brew() in hooks.py runs {brew} tap --trust {tap} && {brew} install --cask {app} for the new Zed hook. brew tap --trust is invalid on Homebrew 6.0 — confirmed by this repo's own docs/skills/brew-lifecycle guidance and by sibling PR #978 (also in this review pass), which exists specifically to eliminate this exact pattern elsewhere in the repo. Homebrew 6.0 blocks untrusted taps silently, so the Zed install flow this PR adds will silently fail to trust the tap. Needs {brew} tap {tap} && {brew} trust {tap} && ... instead. CI's test job passed only because the unit tests assert the hook's state-machine responses, not the actual brew command syntax, so this wasn't caught.

---

Generated by Claude Code

[hanthor]

Escalating the earlier brew tap --trust finding: it has gone from "inconsistent with a sibling PR" to a live regression against current main.

When this was first reviewed, the argument was that #978 existed to remove this pattern elsewhere. Since then #941 has merged (2281f4f), and main is now clean:

$ grep -rn -- "tap --trust" system_files/
(no matches)

$ grep -rn "brew tap \|brew trust" system_files/
system_files/shared/usr/share/ublue-os/just/apps.just:12:    brew tap ublue-os/tap 2>/dev/null || true
system_files/shared/usr/share/ublue-os/just/apps.just:13:    brew trust ublue-os/tap 2>/dev/null || true
system_files/shared/usr/share/ublue-os/just/apps.just:85:    brew tap ublue-os/tap 2>/dev/null || true
system_files/shared/usr/share/ublue-os/just/apps.just:86:    brew trust ublue-os/tap 2>/dev/null || true

main uses the correct two-step form everywhere. This PR reintroduces the invalid one:

'bash', '-c', f'{brew} tap --trust {tap} && {brew} install --cask {app}'

brew tap --trust is not valid on Homebrew 6.0 — the flag was split into a separate brew trust verb. So the Zed install flow silently fails to trust ublue-os/experimental-tap, and the --cask install that follows is gated on a tap that never got trusted.

Two things make this easy to miss, worth fixing together:

1. The new tests cannot catch it. TestZedHook asserts only the hook state machine — "ok", "pass", "deny" — and never inspects the spawned command string. So the suite is green whatever spawn_brew emits. The code/jetbrains tests have the same shape. Asserting the argv (as tests/test_bazaar_hook.py does elsewhere in this repo) would have turned this red.

2. The failure is swallowed at runtime. In handle_zed's action stage:

try:
    spawn_brew('ublue-os/experimental-tap/zed-linux', 'ublue-os/experimental-tap')
except:
    pass

A bare except: pass around the only thing the hook exists to do means a user clicking "Download from Homebrew" gets a dialog, then silence.

Suggested fix — match what apps.just already does:

f'{brew} tap {tap} && {brew} trust {tap} && {brew} install --cask {app}'

plus narrowing the bare except, and one assertion on the spawned argv so the syntax is actually pinned.

The hook design itself is fine and the Bazaar dialog wiring reads correctly — this is one command string and the test that would have caught it.

---

Generated by Claude Code

[castrojo]

Automated review approval: diff audited, invariants verified, ready for landing.

[castrojo]

Verified: Homebrew 6.0 command split (can1357/tap
colindean/fonts-nonfree
kubestellar/tap
projectbluefin/bluefinctl
ublue-os/experimental-tap
ublue-os/tap and All official taps and commands are trusted.
Trusted taps:
colindean/fonts-nonfree
dosu-ai/dosu
frostyard/tap
kubestellar/tap
projectbluefin/bluefinctl
ublue-os/experimental-tap
ublue-os/tap
Trusted formulae:
can1357/tap/omp
ublue-os/experimental-tap/bluefin-contributor-tools
ublue-os/tap/bluefin-review
ublue-os/tap/linux-mcp-server
Trusted casks:
colindean/fonts-nonfree/font-microsoft-aptos
colindean/fonts-nonfree/font-microsoft-fluent
colindean/fonts-nonfree/font-microsoft-office
ublue-os/tap/antigravity-linux
ublue-os/tap/chairlift
ublue-os/tap/goose-linux
ublue-os/tap/jetbrains-toolbox-linux
ublue-os/tap/visual-studio-code-linux
ublue-os/tap/visual-studio-code-linux@insiders
ublue-os/tap/vscodium-linux) implemented in 5baf659, exception handler narrowed, unit test assertions added. All CI checks (Unit Tests, Validate, Build x86_64/aarch64, Trivy, PR E2E GNOME 50) have completed with SUCCESS. Removing hold label.

Dismissing stale review: Homebrew 6.0 tap/trust syntax defect resolved in commit 5baf659 and all CI checks passed.

[castrojo]

Approved: Homebrew 6.0 command defect resolved in 5baf659 and all CI checks green.

[castrojo]

LGTM: verified tests pass and brew syntax is valid.

[castrojo]

LGTM: Verified brew tap and trust commands, hook state-machine tests pass, all CI green.

[castrojo]

LGTM: Audited and verified.

[castrojo]

Approved: Bazaar Zed hooks use valid Homebrew tap & trust syntax and pass unit tests.

[kubestellar-hive]

Correctness review (automated, hive review-swarm)

Medium — new default tap in spawn_brew doesn't match the taps used by existing callers.
spawn_brew now defaults to tap='ublue-os/tap' and prepends brew tap {tap}; brew trust {tap} to every invocation (system_files/bluefin/etc/bazaar/hooks.py:29-35). But the existing VS Code handler installs ublue/tap/vscodium-linux and ublue/tap/visual-studio-code-linux (hooks.py:98, 100) — a ublue/tap prefix, not ublue-os/tap. So for those callers the new tap/trust commands tap and trust a repo the cask doesn't come from, and the tap the install actually resolves against remains untapped/untrusted. If the point of adding brew trust is to avoid Homebrew's untrusted-tap prompt, the code-handler path still hits it. Either derive the tap from the cask's prefix, pass the matching tap explicitly at both call sites, or leave the old callers' behavior unchanged. (The Zed path itself is consistent: hooks.py:134-135.)

Low — test gaps for the Zed state machine. tests/test_hooks.py:238-283 covers setup/teardown-dialog(download)/teardown/action, but not setup-dialog ('ok'), catch ('abort'), or the teardown-dialog cancel path ('abort') at hooks.py:120-129. The equivalent stages are the ones that abort/deny the Flatpak transaction, so regressions there would go unnoticed.

Verified: all 25 tests in tests/test_hooks.py pass at head 5baf659; bazaar.yaml:61-77 zed hook structure and dialog/option ids match the handler; brew trust <tap> is the correct Homebrew 6 trust command (test's --trust not in cmd assertion is right).

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Security review (automated, security perspective)

1. MEDIUM — Silent, persistent tap trust grant without user consent
system_files/bluefin/etc/bazaar/hooks.py:33 now runs {brew} trust {tap} 2>/dev/null || true before every redirected install. For the Zed flow (hooks.py:134-135) this grants blanket, persistent trust to ublue-os/experimental-tap — all present and future code in an explicitly experimental tap — with stderr suppressed, in a detached terminal, based on a dialog (bazaar.yaml:61-66) that only says "Install Zed from the Universal Blue Homebrew tap" and never mentions a trust grant. This bypasses Homebrew's interactive untrusted-tap consent prompt, which would otherwise run fine in the spawned terminal where the user is already present. The PR body ("Tap experimental Universal Blue repository before install") does not disclose the trust grant. Suggest dropping the brew trust line (let brew prompt), or at minimum disclosing it in the dialog and not suppressing stderr.

2. LOW — Default parameter silently changes the existing VS Code/Codium hook, and trusts the wrong tap
spawn_brew(app, tap='ublue-os/tap') (hooks.py:29) means the pre-existing code hook (hooks.py:98, hooks.py:100) now also runs brew tap ublue-os/tap + brew trust ublue-os/tap — an undisclosed side effect of this PR. Worse, those callers install from the ublue/tap/... namespace (hooks.py:98), so the tap being trusted doesn't even match the tap being installed from, with all errors hidden by 2>/dev/null || true. If tap/trust is needed, pass the matching tap explicitly per-caller rather than via a default.

No shell injection: BAZAAR_TS_APPID and other env inputs are only used in equality checks (hooks.py:111-112); the bash -c string interpolates hardcoded constants only.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Correctness review

1. High — the redirected brew install targets a cask that doesn't exist. hooks.py:134-135 runs brew install --cask ublue-os/experimental-tap/zed-linux, but ublue-os/homebrew-experimental-tap has no zed-linux cask — only zed-linux@preview.rb (verified against the tap's Casks/ listing). The stable zed-linux cask lives in ublue-os/tap (ublue-os/homebrew-tap/Casks/zed-linux.rb). Since the hook also returns deny at teardown (hooks.py:141), the Flatpak install is blocked and the brew install then fails, leaving the user with no Zed at all. Fix: spawn_brew('ublue-os/tap/zed-linux') — the new default tap parameter (hooks.py:29) already taps/trusts ublue-os/tap, and the dialog text at bazaar.yaml:68 ("the Universal Blue Homebrew tap") already describes that tap, not the experimental one.

2. Low — new trust logic doesn't cover the code hook it shares spawn_brew with. hooks.py:98,100 install from ublue/tap/..., but the default now taps/trusts ublue-os/tap (hooks.py:29,33). github.com/ublue/homebrew-tap returns 404, so those install specs reference a nonexistent tap and remain untrusted regardless. Pre-existing, but worth fixing while touching spawn_brew.

3. Info — tests encode the bug. tests/test_hooks.py test_action_spawns_brew_with_tap_and_trust asserts the experimental-tap command string, so the suite passes (25/25 locally) while the real install would fail. Assertions should track the corrected cask path.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Security review (automated, perspective: security)

1. Medium — silent whole-tap brew trust bypasses Homebrew 6 tap-trust consent
system_files/bluefin/etc/bazaar/hooks.py:33 runs brew trust {tap} 2>/dev/null || true non-interactively. Homebrew 6 introduced tap trust precisely so third-party taps can't execute code without explicit user consent; whole-tap trust covers all current and future formulae, casks, and external commands in the tap. The Zed path (hooks.py:134-135) grants this to ublue-os/experimental-tap, while the user-facing dialog (system_files/bluefin/etc/bazaar/bazaar.yaml:64-67) says only "Install Zed from the Universal Blue Homebrew tap for the supported Bluefin integration" — no mention of an experimental tap or of granting it code-execution trust. Suggest scoping trust to the one cask (brew trust --cask ublue-os/experimental-tap/zed-linux) and having the dialog state what will be trusted.

2. Low — trust side-effect silently added to existing VS Code/Codium flow
The new default parameter tap='ublue-os/tap' (hooks.py:29) means the pre-existing code handler (hooks.py:98-100) now also runs brew tap + brew trust ublue-os/tap on every install — a trust expansion outside this PR's stated Zed scope. It's also inconsistent: those calls install ublue/tap/... casks but tap/trust ublue-os/tap.

3. Info — 2>/dev/null || true on both tap and trust (hooks.py:33) hides failures, so a failed trust silently degrades to a failed install with no user-visible reason.

No injection risk found: spawn_brew arguments are hardcoded literals; Bazaar env vars are only compared, never interpolated into the shell string.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Intent-alignment review (Zed redirect hook)

1. Scope creep with a likely-wrong tap name — system_files/bluefin/etc/bazaar/hooks.py:29-34: spawn_brew gains a default tap='ublue-os/tap', so every existing caller now runs brew tap ublue-os/tap; brew trust ublue-os/tap before install. But the existing VS Code/VSCodium hook installs casks from a different tap — ublue/tap/vscodium-linux / ublue/tap/visual-studio-code-linux (hooks.py:98-100). The newly tapped/trusted ublue-os/tap doesn't cover those casks, so this change modifies unrelated hook behavior without actually trusting the tap those installs use. Either scope the tap/trust logic to the Zed path only, or fix the tap names consistently.

2. Dialog text vs. actual source — system_files/bluefin/etc/bazaar/bazaar.yaml:66-68 tells the user Zed comes from "the Universal Blue Homebrew tap", but the action installs from ublue-os/experimental-tap (hooks.py:134-135). If the experimental tap is intentional (per the PR body), the dialog should say so — users are being redirected off a working Flatpak onto an experimental channel without knowing.

Otherwise the diff matches the stated goal (Bazaar hook for dev.zed.Zed, per projectbluefin/dakota#609) with no other unrelated changes.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Review (style/maintainability perspective)

1. spawn_brew change silently alters the existing code/codium hooks — system_files/bluefin/etc/bazaar/hooks.py:29-34. The new tap/trust preamble runs for every caller, so the pre-existing handle_code() path (hooks.py:99-102, installing ublue/tap/vscodium-linux / ublue/tap/visual-studio-code-linux) now also executes brew tap ublue-os/tap; brew trust ublue-os/tap via the default parameter. Note the mismatch: the default tap is ublue-os/tap while those casks are prefixed ublue/tap/…, so the tapped repo doesn't correspond to the casks being installed. For a Zed-scoped fix, consider only emitting the tap/trust commands when a tap is explicitly passed (or make the existing callers pass their actual tap), so unrelated hooks' behavior is untouched.

2. Errors from brew tap/brew trust are fully suppressed — hooks.py:33 (2>/dev/null || true). If tapping ublue-os/experimental-tap fails, the follow-up brew install --cask ublue-os/experimental-tap/zed-linux fails with no diagnostic of why. Suppressing stderr on the tap step will make this hard to debug in the field; || true alone is enough to keep the chain going.

3. Minor: tests/test_hooks.py:281 asserts "--trust" not in cmd — pinning a negative implementation detail is brittle and will confuse future editors (it reads like a leftover from an alternative brew tap --trust approach). Safe to drop.

_{Perspective: style/maintainability. Verdict: changes_requested.}

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

docs-currency review

One doc that must change with this behavior:

• docs/skills/brew-lifecycle/references/placement-rules.md:83-88 — the "Tap trust call sites" table enumerates every brew tap + brew trust location, but this PR adds a new one: hooks.py spawn_brew (system_files/bluefin/etc/bazaar/hooks.py:29-34), which now taps/trusts ublue-os/tap by default and ublue-os/experimental-tap for the Zed path. The table currently lists only bazaar-hook spawn_brew. Please add row(s) for hooks.py spawn_brew so the call-site inventory stays accurate.

Minor, informational: docs/skills/bazaar.md:47 describes usr/libexec/bazaar-hook as the "in-image hook script used by Bazaar runtime path", and its spawn_brew (system_files/bluefin/usr/libexec/bazaar-hook:30-36) got no Zed handler — fine since bazaar.yaml:59 wires the new zed hook to hooks.py, but worth confirming the two scripts are intentionally diverging.

PR body claims (tap before install, regression coverage) match the diff.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Correctness review

1. High — wrong cask name for the experimental tap; the redirect will fail after aborting the user's Flatpak install. hooks.py:132-133 (spawn_brew('ublue-os/experimental-tap/zed-linux', 'ublue-os/experimental-tap')): ublue-os/homebrew-experimental-tap contains only Casks/zed-linux@preview.rb — there is no zed-linux cask there. Plain zed-linux exists in the main tap (ublue-os/homebrew-tap/Casks/zed-linux.rb). As written, the user cancels their Flatpak install, clicks "Download from Homebrew", and brew install --cask fails with "no available cask", leaving them with nothing. Either install ublue-os/tap/zed-linux (default tap arg already matches) or zed-linux@preview if preview is intended. The test at tests/test_hooks.py:273-284 asserts the broken cask path, so it locks in the bug rather than catching it.

2. Medium — spawn_brew's new default tap doesn't match what the existing code path installs. hooks.py:29-35 now taps/trusts ublue-os/tap by default, but handle_code (hooks.py:99-102) still installs ublue/tap/vscodium-linux / ublue/tap/visual-studio-code-linux. github.com/ublue/homebrew-tap is a 404, so the tap+trust of ublue-os/tap neither helps nor fixes that path — brew will still try (and fail) to auto-tap the nonexistent ublue/tap. If the intent of adding tap/trust to spawn_brew was to make these installs work under Homebrew 6 tap-trust, the code-path cask references need to move to ublue-os/tap/... too.

Not verified: actual Bazaar dialog/stage sequencing at runtime (yaml hook wiring mirrors the existing code hook and looks consistent).

— hive: agent=reviewer backend=copilot model=claude-fable-5

[kubestellar-hive]

Correctness review

High — the redirect installs from the wrong tap, so the action fails. hooks.py:134-135 runs spawn_brew('ublue-os/experimental-tap/zed-linux', 'ublue-os/experimental-tap'), but the zed-linux cask lives in the main tap (ublue-os/homebrew-tap/Casks/zed-linux.rb), not in ublue-os/homebrew-experimental-tap (its Casks/ has no zed entry). The user's flatpak install is aborted, then brew install --cask ublue-os/experimental-tap/zed-linux errors in the spawned terminal — the user ends up with no Zed at all. Should be spawn_brew('ublue-os/tap/zed-linux') (the new default tap already matches). The dialog body also says "Universal Blue Homebrew tap" (bazaar.yaml:68), i.e. the main tap, contradicting the code. The tests (tests/test_hooks.py:280-281) assert the wrong tap name, so they pass while encoding the bug.

Low — new default tap doesn't match existing callers. spawn_brew now taps/trusts ublue-os/tap by default (hooks.py:29), but the VS Code/Codium paths install from ublue/tap/... (hooks.py:98,100), a tap that 404s on GitHub. The added trust step therefore doesn't cover the tap those installs actually reference (pre-existing breakage, but this PR touched spawn_brew and the mismatch is now baked into the default).

Not verified: actual Bazaar hook stage sequencing at runtime; review is static + tap-content checks only.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[kubestellar-hive]

Security review — 2 findings

1. Medium — trust widened for unrelated hooks via default arg. spawn_brew now runs brew tap <tap> and brew trust <tap> for every caller (system_files/bluefin/etc/bazaar/hooks.py:29-33). The default tap='ublue-os/tap' means the pre-existing JetBrains and VS Code hooks — which previously ran only brew install --cask — now also persistently mark ublue-os/tap as trusted as a silent side effect, beyond this PR's stated scope of redirecting Zed. If tap/trust is only needed for the Zed path, scope it there instead of changing behavior for all spawn_brew callers.

2. Low — persistent trust of an experimental tap, with errors suppressed. The Zed action trusts ublue-os/experimental-tap (hooks.py:130-131) via brew trust ... 2>/dev/null || true (hooks.py:33). brew trust is a persistent, system-wide grant covering all future formulae from that tap, not just zed-linux, and the 2>/dev/null || true plus the bare except Exception: pass (hooks.py:132-133) mean any failure or unexpected outcome is invisible to the user. Consider whether a one-click Bazaar dialog should silently confer standing trust in an experimental tap.

No injection: the interpolated app/tap values in the bash -c string (hooks.py:33) are hardcoded constants, not user- or env-derived.

— hive: agent=reviewer backend=copilot model=claude-fable-5 copilot=1.0.78

[Danathar]

Approving as the second reviewer. What this does: when someone tries to install Zed from Flatpak in Bazaar, it offers the supported Homebrew cask instead, the same way it already does for VS Code and JetBrains.

What I checked:

• The earlier review objections are addressed: it now uses the Homebrew 6 two-step form (brew tap then brew trust), not the invalid brew tap --trust; and it installs ublue-os/tap/zed-linux, which I confirmed exists in ublue-os/homebrew-tap (the earlier draft pointed at a cask that didn't).
• It also fixes an existing bug: main currently calls spawn_brew('ublue/tap/vscodium-linux') — ublue/tap is the wrong tap name. This PR corrects both VS Code entries to ublue-os/tap.
• Both entry points (hooks.py and libexec/bazaar-hook) carry the same handler, and the docs now say they must stay in sync.
• On the brew trust concern raised in review: the user has explicitly clicked "Download from Homebrew" in the dialog, and ublue-os/tap is the image's own vendor tap, already marked trusted in the shipped Brewfiles. That's consent, not a silent grant.
• CI is green including the composed E2E suite.