[Bug] Prime Agent 0.8.0: saved session becomes permanently unopenable after failed worker recovery

[tkellogg]

Affected area

Agent core

What happened?

Title: Prime Agent 0.8.0: saved session becomes permanently unopenable after failed worker recovery

Environment: macOS 26.5.1 arm64, Node v23.4.0, Prime Agent 0.8.0

Session: /Users/tim/.prime/agent/sessions/01a01ca7-bece-7081-8b39-82456dc2d5b4.jsonl

After daemon/supervisor recovery, opening this saved session in Agents View failed repeatedly with:

Session "...01a01ca7-bece-7081-8b39-82456dc2d5b4.jsonl" is registered to a failed worker that could not be safely reclaimed

The failure was recorded at 2026-08-22T15:13:53Z, 15:13:58Z, 15:14:00Z, 15:14:09Z, 15:14:18Z, and 15:14:25Z in ~/.prime/agent/logs/client-errors.log.

The relevant worker descriptor was:

~/.prime/agent/daemon-workers/97b133818186/e560b25669f1.json
lifecycle: failed
consecutiveFailures: 2
lastError: "Waiting for a client with fresh runtime context"

Before that, the supervisor logged repeated failure to adopt the worker:

Timed out waiting for daemon worker response to list
Timed out waiting for daemon worker response to worker_auth

The session JSONL itself is valid: all lines parse, its v3 header is valid, IDs are unique, parent IDs resolve, and
Prime Agent’s own SessionManager can load and list it. A separate new session was created successfully at 15:14:07Z.
Therefore this appears to be a stale/failed worker-registration recovery bug, not transcript corruption.

The original worker process remained alive and continued appending to the session after the supervisor marked it
failed, suggesting a split-brain/orphan-worker state.

Steps to reproduce

1. Start a long-running Prime Agent session.
2. Spawn a large RLM tree in that session. In this occurrence, the tree had about 75 live sessions during one restart
   and 192 saved child sessions overall.
3. Start or keep another top-level Prime Agent session running.
4. Cause the daemon supervisor to restart or become stale while the original session worker remains alive. This occurred
   after an update/restart and later supervisor replacement.
5. The replacement supervisor attempts to adopt the original worker but receives repeated timeouts:
   • Timed out waiting for daemon worker response to list
   • Timed out waiting for daemon worker response to worker_auth
6. Open Agents View and select the original saved session.
7. Opening it fails with:

Session "...jsonl" is registered to a failed worker that could not be safely reclaimed

Repeated attempts continue to fail.

Smaller deterministic reproduction for developers

This uses fault injection but should exercise the exact code path:

1. Start session A and session B under the same daemon.
2. Identify session A’s worker PID and the supervisor PID.
3. Suspend worker A so that it cannot answer daemon requests:

kill -STOP

4. Terminate only the supervisor, leaving the workers alive:

kill

5. Let session B or a new Prime Agent client launch a replacement supervisor.
6. Wait for worker-A adoption to time out and its descriptor to become:

{
"lifecycle": "failed",
"lastError": "Waiting for a client with fresh runtime context"
}

7. Open Agents View and select session A.
8. The resume request should fail with the reported error.

Clean up the suspended test worker afterward with kill -CONT or terminate it.

Important qualifier

The fault-injection reproduction is source-confirmed, but I have not run it against my live daemon because it could
disrupt my other sessions. The precise user-only trigger for the supervisor becoming unresponsive is not proven. The
large RLM tree is the strongest apparent stress factor. The JSONL itself parses correctly and is not the cause.

Expected behavior

after a worker cannot be recovered, the user should be able to safely reopen the saved JSONL in a fresh
worker, or receive an actionable recovery option.

Prime Agent version

0.8.0

Environment

macOS 26.5.1 arm64, Node v23.4.0

Additional context

No response