[Bug] Sleeping the machine permanently orphans daemon sessions: a live worker is marked failed and never re-checked #1742
mdumitrean
started this conversation in
Bug reports
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Affected area
Agent core
What happened?
▎ After my machine slept and woke, the CLI could not reach its session at all:
▎
▎ Error: Daemon reconnection failed: Unknown active session: 8bf5705ac95b
▎ Error: Cannot list heartbeats while session worker is recovering
▎ Error: Cannot send daemon command "prompt" because the Prime Agent daemon is not connected.
▎
▎ The daemon itself was healthy the whole time — it answered daemon_hello in 2 ms and served CLI commands normally. One session worker was marked:
▎
▎ lifecycle : failed
▎ lastError : "Waiting for a client with fresh runtime context"
▎ consecutiveFailures : 2
▎ lastFailureAt : 2026-08-24T21:31:58Z
▎
▎ That worker's process was still alive, and probing its socket directly got a reply in 2 ms — it was completely healthy. The supervisor had written it off and never looked again.
▎
▎ The failure timestamp lands inside a sleep (pmset -g log):
▎
▎ 17:31:52 Sleep (Maintenance)
▎ 17:31:58 <- lastFailureAt
▎ 17:34:11 Sleep, 801 secs
▎ 17:47:32 Wake, due to lid
▎
▎ A suspended process can't answer a 2 s connect or a 5 s list, so the recovery ladder ran against a worker that was merely frozen and marked it failed. Nothing re-checks that state, so worker.summaries stays empty and every session on that worker is unresolvable until the daemon is restarted. An IPC timeout is circumstantial evidence of death — sleep, a paused VM, or heavy load all produce it on a healthy worker.
Steps to reproduce
▎ 1. Start the daemon and open a session, so a resident worker exists.
▎ 2. Suspend the whole machine long enough to outlast the recovery ladder — closing the lid for a few minutes is enough. (Equivalently: kill -STOP for ~40 s, then kill -CONT.)
▎ 3. Wake the machine and try to reach the session.
▎ 4. The worker answers immediately, but the daemon still reports Unknown active session — and keeps doing so until the daemon is restarted.
Expected behavior
▎ A worker is only written off for good once its process is actually gone. While the process is alive and still carries the recorded start id, the supervisor should keep probing and re-adopt it the moment it answers, so sessions survive a suspend without needing a daemon restart.
Prime Agent version
9e49b73
Environment
macOS 26
Additional context
No response
All reactions