Observation
On a work laptop, clawband self-updated from v3.7.13 to v3.7.15 (~6 days ago as of this report), but brew info/brew list --versions clawband still reports v2.99.0 — badly stale, and also predates the reported self-update entirely (2.99.0 vs 3.7.13, not just vs 3.7.15).
Why this is confusing given existing behavior
clawband already refuses to self-update in place over a Homebrew-managed binary, since v2.30.0 (cmd_install's Homebrew guard: "clawband was installed via Homebrew; run 'brew upgrade clawband' instead", checking for /homebrew/ or /linuxbrew/ in the resolved binary path). Since 3.7.13 → 3.7.15 is well past that guard's introduction, a self-update silently overwriting a brew-managed binary would be a regression in that guard — but the 2.99.0 brew version predating the starting 3.7.13 by a lot suggests a simpler explanation: two coexisting installs (e.g. a ~/.cargo/bin/clawband or install.sh-installed copy earlier on PATH that has been self-updating normally, alongside a separate, genuinely long-untouched Homebrew tap install that PATH doesn't resolve to and that the guard correctly never touches).
Needs info to confirm
which clawband (or which -a clawband to see all copies on PATH)brew list --versions clawband- Whether the Homebrew-installed copy is even the one actually being invoked as the Claude Code hook, or just an unused leftover
If it turns out to be two coexisting installs with the Homebrew one simply unused, this isn't a clawband bug — just user-facing confusion worth a clawband verify/clawband --version note if multiple installs are detected on PATH. If the Homebrew guard actually failed to catch a real Homebrew-managed binary, that would be a genuine regression worth deeper investigation.
Observation
On a work laptop, clawband self-updated from v3.7.13 to v3.7.15 (~6 days ago as of this report), but
brew info/brew list --versions clawbandstill reports v2.99.0 — badly stale, and also predates the reported self-update entirely (2.99.0 vs 3.7.13, not just vs 3.7.15).Why this is confusing given existing behavior
clawband already refuses to self-update in place over a Homebrew-managed binary, since v2.30.0 (
cmd_install's Homebrew guard: "clawband was installed via Homebrew; run 'brew upgrade clawband' instead", checking for/homebrew/or/linuxbrew/in the resolved binary path). Since 3.7.13 → 3.7.15 is well past that guard's introduction, a self-update silently overwriting a brew-managed binary would be a regression in that guard — but the 2.99.0 brew version predating the starting 3.7.13 by a lot suggests a simpler explanation: two coexisting installs (e.g. a~/.cargo/bin/clawbandorinstall.sh-installed copy earlier onPATHthat has been self-updating normally, alongside a separate, genuinely long-untouched Homebrew tap install that PATH doesn't resolve to and that the guard correctly never touches).Needs info to confirm
which clawband(orwhich -a clawbandto see all copies on PATH)brew list --versions clawbandIf it turns out to be two coexisting installs with the Homebrew one simply unused, this isn't a clawband bug — just user-facing confusion worth a
clawband verify/clawband --versionnote if multiple installs are detected on PATH. If the Homebrew guard actually failed to catch a real Homebrew-managed binary, that would be a genuine regression worth deeper investigation.