📋 Pre-flight Checks
📝 Bug Description
When upgrading engram via brew upgrade engram on macOS, the running engram serve process is killed (presumably because the binary file is replaced). The process is not automatically restarted, leaving the user without an active autosync until they manually relaunch it. The user receives no notification — engram cloud status continues to report configured/ready because that command does not check whether the local autosync daemon is alive.
🔄 Steps to Reproduce
On macOS, install Engram via Homebrew.
Start autosync: nohup engram serve > /tmp/engram-serve.log 2>&1 &
Run brew upgrade engram (or any upgrade).
Check: ps -ef | grep "engram serve" | grep -v grep — process is gone.
engram cloud status still says configured/ready (misleading).
New engram save calls go to local SQLite but no autosync push happens until user relaunches.
✅ Expected Behavior
Either:
The Homebrew formula post-install hook should detect a running engram serve and offer to restart it, OR
engram cloud status should detect that the local HTTP API on 127.0.0.1:7437 is not responding and warn the user, OR
Provide a documented engram serve launchd template (similar to the systemd unit users self-create on Linux) so the OS supervises it.
❌ Actual Behavior
The autosync silently stops working. The user only finds out when they manually inspect ps, or when sync_state shows growing pending mutations that never advance.
Operating System
macOS
Engram Version
1.14.10
Agent / Client
Claude Code
📋 Relevant Logs
💡 Additional Context
macOS Apple Silicon, Engram 1.14.5 → 1.14.10 via Homebrew.
The Linux story is fine because users typically configure systemd to manage engram serve as a service (the docs encourage this). On macOS, the analogous solution would be a launchd plist, but it's not part of the Homebrew install. Documenting or shipping a default launchd template would close the gap.
📋 Pre-flight Checks
status:approvedbefore a PR can be opened📝 Bug Description
When upgrading engram via brew upgrade engram on macOS, the running engram serve process is killed (presumably because the binary file is replaced). The process is not automatically restarted, leaving the user without an active autosync until they manually relaunch it. The user receives no notification — engram cloud status continues to report configured/ready because that command does not check whether the local autosync daemon is alive.
🔄 Steps to Reproduce
On macOS, install Engram via Homebrew.
Start autosync: nohup engram serve > /tmp/engram-serve.log 2>&1 &
Run brew upgrade engram (or any upgrade).
Check: ps -ef | grep "engram serve" | grep -v grep — process is gone.
engram cloud status still says configured/ready (misleading).
New engram save calls go to local SQLite but no autosync push happens until user relaunches.
✅ Expected Behavior
Either:
The Homebrew formula post-install hook should detect a running engram serve and offer to restart it, OR
engram cloud status should detect that the local HTTP API on 127.0.0.1:7437 is not responding and warn the user, OR
Provide a documented engram serve launchd template (similar to the systemd unit users self-create on Linux) so the OS supervises it.
❌ Actual Behavior
The autosync silently stops working. The user only finds out when they manually inspect ps, or when sync_state shows growing pending mutations that never advance.
Operating System
macOS
Engram Version
1.14.10
Agent / Client
Claude Code
📋 Relevant Logs
💡 Additional Context
macOS Apple Silicon, Engram 1.14.5 → 1.14.10 via Homebrew.
The Linux story is fine because users typically configure systemd to manage engram serve as a service (the docs encourage this). On macOS, the analogous solution would be a launchd plist, but it's not part of the Homebrew install. Documenting or shipping a default launchd template would close the gap.