brew upgrade leaves the old daemon running: no restart, no version-skew detection (macOS)

[madeinoz67]

Context: macOS, gortex installed via Homebrew. The formula replaces /opt/homebrew/bin/gortex, but a daemon that is already running keeps serving from the old binary indefinitely after brew upgrade. Nothing restarts it, and nothing surfaces the skew: the CLI and every MCP client keep connecting to the daemon on the old version.

Observed on my machine (v0.63.x line):

• a daemon started days before an upgrade was still serving afterwards; gortex daemon status showed the old build while the on-disk binary was newer
• the launchd unit exists (~/Library/LaunchAgents/com.zzet.gortex.plist) but reports not loaded, while a manually-started daemon holds the socket — so even a user who ran daemon install-service once can end up with a unit that owns nothing

Why I think this happens:

1. A hand-started daemon (gortex daemon start) has no supervisor and no upgrade hook; swapping the binary does not touch the running process. macOS keeps executing the old inode.
2. brew upgrade does not reload or restart launchd units. If the unit was never loaded (or the daemon was started manually anyway), there is nothing to bounce.
3. The docs say gortex mcp exits "if no compatible daemon can be reached" — but compatibility evidently is not binary-version-level, because a new CLI drives an old daemon silently. I could not find any build-version comparison on the connect path (the protocolVersion strings I found are MCP-protocol constants).

Impact: stale graph behavior and bugfixes; mixed versions between CLI and daemon (daemon status shows one build, the binary is another); store migrations and behavior changes land late or never until someone notices and restarts by hand.

Possible directions (not prescriptions):

1. Version-skew detection on connect: CLI/mcp proxy compares its build version against the daemon's (status already carries a version) and either refuses or prints a loud one-liner: daemon is vX, binary is vY, run gortex daemon restart.
2. Make the restart story explicit after package-manager upgrades: a hint in brew output is formula-side, but gortex could detect its own staleness (e.g. running image vs on-disk binary) and report it in daemon status/mcp logs.
3. Consider making the supervised service the blessed path (KeepAlive restarts after upgrade), and have daemon start warn when a launchd unit is installed but not loaded, or when a hand-started daemon is shadowing a unit.

Happy to work on a fix if any of the directions sound right.

[madeinoz67]

Working on a fix for this. Plan:

1. Version-skew warning — CLI/mcp proxy compares its build identity with the daemon's on connect and prints a one-line stderr warning (warn + continue, no refusal) when they differ.
2. Staleness self-report — the daemon stats its own os.Executable() at startup and re-stats on status requests; on drift daemon status shows a stale row and the daemon logs one warning line. Stat-based (size+mtime), no hashing the binary.
3. Reuse gortex version — the CLI already prints its build identity (gortex version → v0.63.4+5f5fce2); the fix makes the daemon's status version and the CLI's compare derive from the same source rather than adding any new command.
4. Cask-side restart — since gortex ships as a cask (zzet/tap), the cask can pre_install-stop a running daemon and post_install-restart it, guarded so fresh installs and CI never launch a daemon. Will be a separate small PR against the tap, referencing this issue.

PR for 1-3 to follow once the #606 extractor PR lands (same contributor).

[madeinoz67]

Update: the fix is now split across two PRs that together cover detection and the install path —

• #611 — the detection layers: mcp proxy warns on connect when the daemon's build differs from the binary's (direction-aware remedy, warn-and-continue), daemon status gains a cli row on version skew and a binary: stale row when the daemon detects the on-disk image changed under it (stat-based, logged once).
• #612 — the brew leg: the release pipeline's cask template now stops a running daemon before the upgrade and restarts it onto the new binary after, guarded so fresh installs and CI never launch one. (This targets release.yml's generator rather than the tap file, since the cask is regenerated on every release.)

Together: after a brew upgrade, a running daemon is bounced cleanly onto the new binary, and any skew that slips through (non-brew installs, manual starts) is visible instead of silent.