dsh-phoenix

DeepSeek Harness organizes everything as plugins, and the dsh Web runtime is a single long-running process managed by systemd. That architecture creates a painful reality: every plugin update forces a hard restart, severing whatever agent task is in progress, freezing the browser page, and evaporating in-memory goal state. dsh-phoenix transforms this disruptive update-then-break cycle into a graceful, resumable, and continuously evolving loop.

Three core capabilities make this possible. First, graceful restart: upon detecting a plugin re-activation through the dsh plugin tools, the plugin does not reboot immediately. It polls every live agent, including sub-agents, and defers the restart until all are idle, with a five-minute safety deadline as a backstop. The reboot itself runs via systemd-run --user as an independent transient unit, so the process being killed never drags the restart sequence down with it. Second, client auto-reconnect: a zero-dependency heartbeat script is injected into the served index page. It polls a per-boot health endpoint every few seconds; when the backend returns with a new boot token, the page reloads itself instantly, making the restart invisible to the user. Third, cross-restart goal re-arm: a restart disarms any active goal, halting autonomous continuation. dsh-phoenix reads a persistent JSON checkpoint written atomically via tmp-plus-rename, and when pendingResume is true, locates the matching active disarmed goal and calls goals.resume() to re-arm it, allowing a long-running objective to keep iterating across multiple restarts.

This plugin is for developers who run dsh Web as a systemd --user service and maintain long-horizon autonomous objectives spanning hours or days. If your workflow involves frequent plugin updates alongside in-flight tasks, dsh-phoenix is the safety net that turns an update from a destructive event into a seamless, non-disruptive operation. It carries zero external dependencies, relying solely on the native dsh runtime services.