You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Keep the service's supervisor current after an update from the app #444
The background service's config (a systemd unit on Linux, a launchd file on macOS) names one version's program as the supervisor, the process that starts the server. An update from the app swaps the server and leaves that supervisor running, by upstream's design, so agents' work survives the switch. The supervisor is replaced only when someone runs j5 update or j5 service install on the machine.
So a server that updates only from the app keeps its original supervisor indefinitely. On the dogfood box on 2026-10-02 the supervisor was 0.0.44 while the server was 0.0.47. Costs:
The supervisor never gets fixes to itself.
Any change the old supervisor can't handle needs a launcher protocol bump and a manual step on every server. The t3 to j5 rename (feat(cli): the release executable is named j5 #414) is the first J5 change to pay this.
Once j5 follows the server (fix(cli): j5 follows the server after an in-app update #415), j5 service status reports the service as needing j5 service install after every update from the app, because the unit still names the older supervisor. An agent that follows that suggestion restarts its own server.
Direction
After an update from the app commits, the server rewrites the service's config to name its own version, without restarting anything. The new supervisor then takes over at the next service restart or reboot.
Not built or tested. Known points to settle:
On macOS, launchd keeps using the loaded definition until the service is reloaded, so rewriting the file alone doesn't take effect on a plain restart of the job.
The running supervisor owns the service's state file during an update; the rewrite must not race it.
j5 service status should then stop reporting a repair as needed, or say plainly that a restart is pending.
Upstream
This is upstream's design, not a bug of theirs, and the same staleness exists in T3 Code. Jackson wants this contributed back upstream (2026-10-04); it's listed in the give-back backlog (#276).
Problem
The background service's config (a systemd unit on Linux, a launchd file on macOS) names one version's program as the supervisor, the process that starts the server. An update from the app swaps the server and leaves that supervisor running, by upstream's design, so agents' work survives the switch. The supervisor is replaced only when someone runs
j5 updateorj5 service installon the machine.So a server that updates only from the app keeps its original supervisor indefinitely. On the dogfood box on 2026-10-02 the supervisor was 0.0.44 while the server was 0.0.47. Costs:
t3toj5rename (feat(cli): the release executable is named j5 #414) is the first J5 change to pay this.j5follows the server (fix(cli): j5 follows the server after an in-app update #415),j5 service statusreports the service as needingj5 service installafter every update from the app, because the unit still names the older supervisor. An agent that follows that suggestion restarts its own server.Direction
After an update from the app commits, the server rewrites the service's config to name its own version, without restarting anything. The new supervisor then takes over at the next service restart or reboot.
Not built or tested. Known points to settle:
j5 service statusshould then stop reporting a repair as needed, or say plainly that a restart is pending.Upstream
This is upstream's design, not a bug of theirs, and the same staleness exists in T3 Code. Jackson wants this contributed back upstream (2026-10-04); it's listed in the give-back backlog (#276).
Related: #398, #414, #415.