86 Releases 86 Tags

RSS Feed

• v1.5.7 49a041b1dc

  Compare

  v1.5.7 Stable

  nntrivi2001 released this 2026-09-11 09:34:14 +00:00 | 225 commits to main since this release

  Fixed

  A plugin self-update took the dashboard down and left it down.

  If you run the dashboard as a systemd --user service (agenthub service install, or any plugin bootstrap on Linux), pressing Update now killed it. The update chain itself ran fine — marketplace update, plugin update, new cache directory, deps, UI build — and then the bootstrap reached the step where it stops the server it is replacing. That server was systemd-managed, and the bootstrap is a descendant of it, so it runs inside the unit's cgroup. Two failures fired at the same instant:

  • the server exits 0, and the unit's Restart=on-failure reads a clean exit as "meant to stop" — systemd did not bring it back;
  • KillMode=control-group (systemd's default) reaped the bootstrap itself, mid-run, before it could repoint the unit at the new plugin root or write runtime/state.json.

  What that looked like on disk: bootstrap.log ending at stopped the server started from the previous plugin version with no line after it, a surviving .bootstrap.lock holding a dead pid, a state.json still naming the previous version, and a unit whose ExecStart still pointed at the old cache directory. The dashboard then stayed down until some later Claude Code session happened to run the bootstrap again — which is why this could go unnoticed for a while: a session started soon enough usually repaired it.

  The fix

  scripts/systemd-service.js splits installation in two:

  • writeUserService repoints the unit at the new plugin root and starts nothing — so the unit can be corrected while the old server is still serving requests;
  • restartUserService restarts with --no-block, because the caller is inside the cgroup being restarted and must not wait to be killed.

  plugin-bootstrap.js now checks whether a unit of ours owns the server. If it does, it never stops it by hand, and defers the restart until after writeState and releaseLock — by then there is nothing left to lose. If there is no unit (or a foreign one), the old stop-then-start path is unchanged: nothing there is inside a cgroup.

  The unit is also written with Restart=always instead of on-failure, so a graceful SIGTERM from anything at all no longer leaves the dashboard down for good. An explicit systemctl stop — what agenthub service uninstall does — still stops it.

  agenthub service install keeps the old one-step behaviour: it runs from your own shell, outside the unit's cgroup.

  If your dashboard is down right now

  This release cannot repair an install that is already stuck, because the stuck install is the thing that would apply it. Run the bootstrap by hand once (it reclaims the stale lock on its own):

  node ~/.claude/plugins/cache/<marketplace>/agenthub/<newest-dir>/scripts/plugin-bootstrap.js --force
  

  Then check with /agenthub-doctor. Updates after that one are self-healing.

  Documentation

  docs/PLUGINS.md gains a Who may stop the server section with the cgroup rule and the two-path table; the rule is also recorded in CLAUDE.md's non-negotiables so it is not undone later. The uninstall snippet said a bare kill is undone by Restart=on-failure — it is now Restart=always, and the systemd unit must be disabled first.

  Downloads

  • Source Code (ZIP)
  • Source Code (TAR.GZ)