[bug] `pags up` does not self-heal after a wake: registration never rides the reconnect path, and the machine is locked out of its own relay slot by the socket it left behind

[serge-ivo]

What the owner saw

  ✓ Browser      running on your computer
  ✓ Secure link  connected to ProAgentStore
  ✗ ProAgentStorenot registered (retries automatically)

  Setting things up… this takes a few seconds. Keep this window open.
  Status: Relay connected

pags up (v0.4.45) on RLs-MacBook-Air.local, after the laptop had been asleep. Their question
was "is it supposed to come back by itself when I wake the laptop?" — and the answer the code
gives is yes, that is the design (the relay reconnects with 1s→30s backoff, relay.ts:288-293;
the heartbeat retries every 30s and even has a recovery message, relay.ts:126). It does not
fully work, for two independent reasons, and the pane cannot tell the user which one they have.

Separate ticket for "start pags up with no terminal open" (a LaunchAgent — a product decision,
not this bug): #___.

---

Part 1 — the mechanism

1a. Registration does not ride the reconnect path

registerRuntime is called from exactly two places (grep -n registerRuntime packages/cli/src/commands/runner/relay.ts → 37, 55, 162):

• relay.ts:55 — for (const id of instanceIds) await registerRuntime(id);, once, at startup.
• relay.ts:162 — inside the 20s discovery poll, and only for instances in
  diffMembership(...).attach, i.e. ones not already attached.

openRelaySocket (relay.ts:184-311) has no reference to it. So when a socket drops and
reconnects — the wake case — POST /v1/instances/:id/runtime is not re-issued. And when the
startup call fails, it is caught and logged and never tried again:

// relay.ts:50-53
} catch (e) {
    const msg = e instanceof Error ? e.message : String(e);
    writeError(`register ${id.slice(0, 8)}… failed: ${msg}`);
}

Two consequences, both verified in the route:

1. A registration lost at startup is lost forever. Start pags up while the network is still
   coming up (exactly what happens if you run it right after a wake or a boot): fetch failed,
   no instance_runtime_nodes row for this machine, and nothing ever retries. The relay socket,
   which does retry, comes up seconds later — producing precisely the screenshot's asymmetry:
   secure link connected, ProAgentStore not registered.
2. resumeSessionsForNode never runs on a wake. It lives inside the register route
   (workers/api/src/routes/instances.ts:365), so this machine's suspended coding sessions are
   reactivated only by a fresh pags up, not by a socket reconnect.

Note the heartbeat is not a substitute. POST …/runtime/heartbeat only UPDATEs
(instances-runtime.ts:868-891); with no node row for this machine the node-scoped UPDATE matches
0 rows, while the second UPDATE on instance_runtimes is not node-scoped — so the failed
machine's heartbeat still refreshes whichever machine owns the shared default row, and returns
200. Silent by construction.

Fix (cheapest, CLI-only): give openRelaySocket an onOpen(instanceId) callback and call
registerRuntime(id) from it. The upsert is idempotent, so re-registering on every (re)connect is
safe, it inherits the socket's existing backoff for free, and it makes resumeSessionsForNode run
on wake — which is what the multi-machine doc already promises ("the machine's own suspended
sessions reactivate on reconnect", platform-docs/coder-multi-machine.md:116).

1b. On wake the machine is locked out of its own relay slot — measured, in production

This is the part that makes recovery impossible rather than merely incomplete.

RelayDO.handleConnect decides whether an incumbent socket is alive by whether a send throws:

// workers/api/src/relay-do.ts:76-91
if (existing.length > 0 && !force) {
    let alive = false;
    for (const ws of existing) {
        try { ws.send("ping"); alive = true; break; } catch { /* dead */ }
    }
    if (alive) {
        return closeWithReason(4409, "Another runner is already connected. Use --force to take over.");
    }
}

Nothing anywhere requires the pong to come back — webSocketMessage drops "pong" on the floor
(relay-do.ts:111) and no timer, alarm or last-seen is kept. A peer that has stopped existing at
the application layer — a slept laptop — therefore still counts as alive.

Measured against production, api.proagentstore.online, on an instance I own, using a
throwaway node name (pags-probe-…, never registered, so no DB row and no routing effect):

step	result
holder connected, node pags-probe-xeg1dj	/status → {"connected":true}
holder SIGKILLed, reconnect same node immediately	accepted — a hard-killed runner does NOT conflict
holder SIGSTOPped (frozen = the shape of a slept laptop), reconnect same node	4409 "Another runner is already connected. Use --force to take over."
same, 47s later	4409 again; /status still {"connected":true}
same, still frozen, polled once a minute	still 4409 at t+3m (probe still running at time of writing)
same, with &force=1	accepted

So: the machine's own pre-sleep socket holds its slot; /status reports it connected the whole
time; and the only thing that gets in is --force. Note the SIGKILL row — this is specifically a
frozen peer, not a dead process, which is why restarting pags up normally works and waking a
laptop does not.

On the client side, a 4409 is terminal for the life of the process:

// relay.ts:274-279
if (ev.code === 4409 && !force) {
    writeLine(`Relay conflict: ${instanceId.slice(0, 8)}… is connected on another machine — run \`pags up --force\` here to take it over.`);
    closed = true;
    onConflict?.(instanceId);
    return;
}

onConflict adds the id to blocked (relay.ts:73), and diffMembership excludes blocked ids
from attach (membership.ts:63). Nothing ever removes an id from blocked — grep -n blocked packages/cli/src/commands/runner/relay.ts gives 61 (declare), 73 (add), 155 (pass);
there is no delete. That directly contradicts the comment that documents the intent:

membership.ts:46-48 — "They are NOT dropped from the eligible set, so clearing the block (the
other machine disconnects, or the user runs --force) lets the next pass attach."

The block cannot clear, so even after the zombie expires and the slot is free, that agent stays
detached until the user restarts the CLI.

Live evidence this is happening on the owner's account (GET /v1/terminals/nodes, read
2026-08-11):

machine	relay sockets live	rows reading status: online
RLs-MacBook-Air.local (v0.4.45)	6 of 19	19
Sergeys-Mac-mini.local (v0.4.45)	18 of 18	18

Six of the Air's thirteen detached agents are pinned to the Air (bound: true), including
iTerm2 Operator, kitty Operator, Terminal Operator, tmux Operator, FWS platform,
Chess coder. Its pags up is running and will never reattach them.

Fix (server, and the one that actually restores automatic recovery): make the incumbent
liveness test evidence-based — send the ping and require a pong within a short deadline before
rejecting. handleConnect becomes async; resolve a promise keyed to that socket from
webSocketMessage when "pong" arrives; no pong in ~1.5-2s → treat the incumbent as dead, close
it, accept the newcomer. This keeps #237/#229's promise intact: a genuinely live second runner
answers instantly and still gets its 4409, so the "endless noisy reconnect against a real
conflict" that #237 was filed about does not come back. The runner answers a ping before it parses
anything else (relay.ts:238), and a command in flight does not queue behind it, so a busy runner
still pongs promptly.

Fix (client, complementary and cheap): make blocked clearable, as its own comment already
says it is. On each 20s discovery pass, for blocked ids only, GET /v1/relay/:id/status
(one cheap request, no socket) and unblock when it reports connected: false. Log the unblock
once. This is not a return to the 30s reconnect spam — it is one status GET per poll, and it is
the difference between "recovers by itself when the conflict ends" and "recovers when you notice
and restart".

Rejected alternative: carry machineId (#379) in the relay handshake and let a matching
machine always displace itself. It is a real option and it would fix the wake case, but it needs a
CLI change (version skew — the owner is on 0.4.45 and would not get it), it leaves /status still
reporting a zombie as connected, and it does nothing for the frozen-socket case on a machine whose
id file was reset. The pong check fixes all of those server-side, with no CLI release.

Also worth fixing with the same handle: handleStatus (relay-do.ts:140-156) uses the same
send-doesn't-throw test, which is why /status said connected: true for a peer that was gone.
diagnoseAttachment returns attached / "Connected." on relayConnected alone
(lib/runtime-attachment.ts:55-57), so during the zombie window the console tells the user the
agent is connected while every runner call goes to a socket that will never answer and dies on the
120s relay timeout (relay-do.ts:32). Same family as #380, different cause.

---

Part 2 — the pane, which cannot report any of this

2a. The registration light is a latch that can never clear

state.registration is derived entirely from string-matching the child's stdout
(up.ts:147-203); there is no timer and no polling. Only two lines set it to "failed":

• up.ts:184 — trimmed.includes("Another machine"). Nothing in the codebase ever prints that
  string — grep -rn "Another machine" across the repo returns only up.ts:184 itself. Dead
  branch.
• up.ts:190 — trimmed.includes("fetch failed"), which sets
  state.lastEvent = "PAGS registration failed".

And only three lines set it back to "registered" — up.ts:163 ("WebSocket relay") and
up.ts:178 ("Runtime registered" / "CONNECTED") — all three of which are matched by
relay.ts:90 and relay.ts:93, printed exactly once, at startup. After startup, no line the
runner ever emits can turn the ✗ back into a ✓.

So the pane's ✗ survives the recovery. In particular, the most likely producer of the owner's
screenshot is the heartbeat, not registration:

// relay.ts:121-127
if (failure && !heartbeatFailing) {
    heartbeatFailing = true;
    writeError(`Heartbeat failed: ${failure} — the console will show this machine as OFFLINE until it recovers. ...`);
} else if (!failure && heartbeatFailing) {
    heartbeatFailing = false;
    writeLine("Heartbeat recovered — this machine reads as online again.");
}

On wake, the first heartbeat fails with undici's fetch failed → up.ts:190 fires → the pane
says "not registered" for a heartbeat failure, with the remedy text "(retries
automatically)". Thirty seconds later the heartbeat recovers and prints so — and
"Heartbeat recovered — this machine reads as online again." matches no branch in up.ts, not
even the catch-all error regex at up.ts:198 (no "error", no "failed"). The pane stays ✗ forever
while the thing it names is fine.

I could not determine from the screenshot alone which of the two the owner hit — a startup
register failure (1a, permanent) or a heartbeat blip (2a, self-healed). Both render identically.
That indistinguishability is itself the defect; the only way to tell is to press l and read the
scrollback for register … failed: vs Heartbeat failed: / Heartbeat recovered.

Fix, cheapest first:

1. up.ts:184 — delete the dead branch, or point it at the message that actually exists
   ("Relay conflict:", relay.ts:275). Today a 4409 matches nothing in handleOutput: not
   the conflict branch (case differs — the message says "another machine", lowercase) and not the
   error regex (contains neither "error" nor "failed"), so the user is never told the one thing
   the CLI knows and the one command that fixes it.
2. relay.ts:90 — stop printing "Runtime registered with PAGS ✓" unconditionally. It is emitted
   after the register loop whether or not a single register succeeded, so the pane can show
   ✓ ProAgentStore for a machine that registered nothing. Print the truth:
   Runtime registered: N/M agents.
3. Give the heartbeat its own state instead of borrowing registration's, and clear it on
   "Heartbeat recovered".
4. Better than all of the above: have the runner emit one explicit machine-readable status line
   (e.g. PAGS-STATUS registration=ok|fail relay=ok|fail reason=…) and have the TUI render that,
   instead of inferring product state from prose that a later commit will reword.

2b. "this takes a few seconds" is unbounded

tui.ts:89 prints "Setting things up… this takes a few seconds. Keep this window open." on
every render where connected is false (tui.ts:65). There is no elapsed-time input to
printStatus and no timer — so a state that is permanent (1a) is described as taking a few
seconds, indefinitely. Show elapsed time and change the wording past ~30s:
Still connecting — 4m elapsed. Press l for logs.

2c. ProAgentStorenot registered — the label column is one char too narrow

// tui.ts:72
console.log(pad + icon + " " + w(label.padEnd(13)) + d(note));

"ProAgentStore".length === 13, so padEnd(13) adds nothing and the label runs into the note.
"Browser" (7) and "Secure link" (11) both pad fine, which is why only this row is affected.
Fix: padEnd(15), or derive it — Math.max(...labels.map(l => l.length)) + 2.

---

Not the cause — checked

• Version. The runner is 0.4.45; main is 0.4.46. The only commit that bumped it is d14e1bb
  (packages/cli/{package.json,src/commands/machines.ts,src/machine-claim.ts,src/machine.ts} +
  tests, [bug] A wrong machine claim cannot be undone — nothing un-stamps machine_id, and a server-only un-claim would be re-stamped by the next pags up #467). Nothing in 0.4.46 touches registration or reconnect — upgrading does not fix
  any of this.
• --instance scoping / discovery being off. up.ts:138 passes --watch-instances for an
  unscoped run, and discovery is running (the Air has 19 rows, more than the mini's 18).
• A hard-killed predecessor racing its own sockets. Measured and not reproduced: SIGKILL
  then an immediate same-node reconnect was accepted. Recorded here so nobody re-derives it.

What I could not reproduce

I cannot sleep the owner's laptop, so the wake path end-to-end is inferred, not observed. What is
measured is the piece it turns on: a frozen peer holds the relay slot and forces 4409 (table
above), and the CLI's handling of 4409 is terminal (code, cited). The fetch failed → "not
registered" latch is read from code, not observed live.

Acceptance criteria

• Sleep a laptop with pags up running for ≥5 minutes, wake it: within one backoff cycle
  every agent is attached again and /v1/terminals/nodes shows sockets live for all of them,
  with no keypress and no --force.
• RelayDO.handleConnect rejects with 4409 only after the incumbent has answered a ping;
  a non-answering incumbent is closed and replaced. Unit test both directions.
• A blocked instance is re-attached automatically once the conflict clears, without
  restarting the CLI.
• Kill the network for 2 minutes with pags up running, restore it: the pane returns to
  ✓ ProAgentStore by itself.
• Start pags up with the network down, bring it up: registration completes without a
  restart.
• pags up started against an unreachable API shows ✗, not ✓, on the ProAgentStore row.
• A 4409 renders in the pane with its remedy, not only in l logs.
• Labels align: no ProAgentStorenot.

Regression risk

• The pong deadline is the risky one. Too short and a real, live runner loses its slot to a
  second pags up; too long and every conflicting connect pays it. 1.5-2s is far above the
  runner's ping handling (relay.ts:236-238, answered before any parsing). The test that catches
  a regression is a relay-do case where a responsive incumbent still produces 4409 — that is
  [bug] A rejected relay socket retries forever and the console shows only an unexplained amber dot #237's shipped promise and it must keep passing.
• relay-do.test.ts cannot catch this class today. Its MockWebSocket.send throws when
  closed (relay-do.test.ts:30-33), which encodes the very assumption production contradicts —
  a mirror of the implementation cannot falsify the implementation's premise. Any fix here needs
  a test whose fake socket can be silent as well as closed. Same blind spot as Both testing blind spots are closed — what remains is a fetch-deadline floor in safeFetch, then two ratchets (deadline + responsive-label) #438.
• Re-registering on every reconnect increases POST /runtime volume by roughly one call per
  instance per reconnect. The route is an upsert, but it also runs resumeSessionsForNode and
  (only under force) suspendSessionsFromOtherNodes — confirm the non-force path stays
  side-effect-free for sessions that are already active.

Related

• [bug] A rejected relay socket retries forever and the console shows only an unexplained amber dot #237 — built the 4409 stop-retrying behaviour and the server-side diagnoseAttachment. Both
  survive the fix proposed here; the change is when a 4409 is issued, not what happens after one.
• pags up should attach newly configured runner agents without restart #229 — made 4409 terminal for auto-discovered instances.
• [bug] /runtime/status answers "attached · Connected." for an instance whose pin points at a dead machine — the pin-blind fallback overrides the pin-aware resolution (#238) #380 / [bug] A pinned-to-an-offline-machine agent is told to run pags up --force — describeFacts drops the two fields the pinned-machine diagnosis needs, so the branch is dead on every surface but one #461 / [bug] #461's fix did not reach the second adapter — classifySubordinateConnectivity drops the pin, so subordinate_status, start_work and the chat tool still prescribe pags up --force for a pinned agent #468 — "attached · Connected." for an agent nothing can reach, other causes.
• [bug] A repo has been marked broken for five days by a dropped WebSocket — a transport failure is stored as the repo's state, and no verdict is ever re-taken #440 — a transport failure stored as durable state; same family.
• Both testing blind spots are closed — what remains is a fetch-deadline floor in safeFetch, then two ratchets (deadline + responsive-label) #438 — no test executes SQL / verifies a parameter crossing client→route→DO; this is the
  WebSocket-liveness instance of it.

[serge-ivo]

Correction + a completed measurement, and it changes which fix matters most

The long-running probe finished. The server-side lockout is transient, ~5 minutes, not
indefinite as the issue body implies ("still 4409 at t+3m, probe still running"). Full series —
holder frozen with SIGSTOP at t=0, then once a minute: GET /v1/relay/:id/status and a same-node
reconnect attempt:

t+0.0m status={"connected":true}  connect=4409
t+1.0m status={"connected":true}  connect=4409
t+2.0m status={"connected":true}  connect=4409
t+3.0m status={"connected":true}  connect=4409
t+4.0m status={"connected":true}  connect=4409
t+5.0m status={"connected":false} connect=ACCEPTED
t+6.1m status={"connected":false} connect=ACCEPTED

Cloudflare evicts the abandoned hibernatable socket somewhere between t+4m and t+5m. So:

The permanence is entirely client-side. The slot frees itself in about five minutes, and the
CLI never goes back for it, because blocked has no delete (relay.ts:61/73/155) and 4409 sets
closed = true on the socket handle (relay.ts:276). One badly-timed reconnect inside a
five-minute window costs the agent the entire life of the pags up process — which is exactly the
end state measured on RLs-MacBook-Air.local: 13 agents detached, no conflicting socket left
anywhere, and a runner that will never try again.

Re-ordering the fixes accordingly:

1. Make blocked clearable (CLI). Now the primary fix, not the complement. Re-probe
   GET /v1/relay/:id/status for blocked ids on the 20s discovery pass and unblock on
   connected: false; ~5 minutes after any wake the agent reattaches on its own. Still no
   reconnect spam, so [bug] A rejected relay socket retries forever and the console shows only an unexplained amber dot #237's promise holds. This alone converts "dead until you restart" into
   "back within five minutes".
2. Require a pong before issuing 4409 (server). Now the secondary fix — but not droppable,
   because it closes the five-minute window itself and it fixes /status reporting
   {"connected":true} for a peer that is gone (rows t+0m … t+4m above). During that window
   diagnoseAttachment says "attached · Connected." (lib/runtime-attachment.ts:55-57) while
   every runner call is dispatched into the dead socket and dies on the 120s relay timeout
   (relay-do.ts:32). Five minutes of "connected" plus a two-minute hang per call is its own
   defect.
3. Re-register on reconnect (unchanged, §1a).

Everything else in the issue stands as written.

[serge-ivo]

Implemented in ca78f6a; the CLI half ships in @proagentstore/cli@0.4.47 (3da2b3f, published).
The API worker with the server half is deployed.

Verified in production, both directions

Same method as your probe — a throwaway node name (pags-probe-…), never registered, no DB row,
no routing effect. A "frozen" holder here is a socket that takes the ping and never answers, which
is the same application-layer state as the SIGSTOPped process you measured. Note a 4409 is an
accepted-then-closed upgrade (closeWithReason), so onopen always fires first — the run below
waits 1.2s after open and reports the close if one follows, which my first attempt got wrong.

node=pags-probe-avrjpb
1. holder that never pongs (frozen laptop)     ACCEPTED (still open)  [1986ms]
   /status while it holds the slot: {"connected":true}
2. same node reconnects (THE WAKE CASE)        ACCEPTED (still open)  [2917ms]
3. a holder that DOES pong (live runner)       ACCEPTED (still open)  [2921ms]
4. newcomer vs the live holder (#237)          REFUSED 4409 "Another runner is already connected.
                                                             Use --force to take over."  [1306ms]

wake case recovers without --force: YES
#237 preserved (live runner still wins): YES

Row 2 is the fix: the reconnect that used to be 4409 for ~5 minutes is now accepted after the
1.5s pong deadline. Row 4 is the promise #237 shipped, still kept — and it was not taken on trust,
which is what you asked for.

/status self-corrects too, without adding latency (measured on the same probe):

live (pongs)   : {"connected":true} {"connected":true}
frozen, call 1 : {"connected":true}   <- optimistic by design: no answer yet to judge
frozen, call 2 : {"connected":false}  <- self-corrected

And it does not false-negative real runners: four live instances across both of the owner's
machines answered {"connected":true} on three consecutive polls each.

What was built

§1a — registration rides the reconnect. openRelaySocket gained an onOpen(id, reconnect)
callback. The rule is pure and pinned in both directions (shouldRegisterOnOpen): a RECONNECT
always re-registers (idempotent upsert, and it is what makes resumeSessionsForNode run on wake),
a FIRST open re-registers only when the earlier attempt failed — which is the other half you
identified, a register lost to a boot-time fetch failed and retried by nothing. A reconnect does
not re-send --force: that suspends other machines' sessions and is a one-time claim, not
something a network blip should repeat. resumeSessionsForNode runs either way
(routes/instances.ts:365, outside the force branch), so the wake path still gets it.

§1b — pong required. RelayDO.handleConnect is async and refuses only after the incumbent
answers within 1.5s; webSocketMessage no longer drops "pong" on the floor. The decision lives
in workers/api/src/lib/relay-liveness.ts as a pure class so both directions are unit-tested
without a Cloudflare runtime, including "a late pong cannot retroactively resolve an expired
probe".

§1b (client) — blocked is clearable, as its own comment always claimed. One status GET per
blocked id per 20s discovery pass, not a reconnect; unblocks on connected: false and logs once.

One deliberate deviation, and why. /status does not wait for a pong. relayConnected is
called in a per-node LOOP on every tool-call resolution path (runner-client.ts:86-96,141,167,175)
and in the chat context builder, so a 1.5s wait per offline node would add seconds to every agent
turn. Instead it pings and judges on the PREVIOUS round trip: zero added latency, first call after
a freeze still optimistic, next one honest (measured above). Relatedly, an unanswered ping does
not close the socket — the runner does synchronous local execs (tmux capture-pane via
execFileSync), so a live runner can be briefly slow and closing it would drop commands in
flight. Only a send that throws closes one, as before.

§2 — the pane. The child now emits one machine-readable PAGS-STATUS registration=… heartbeat=… agents=N/M reason=… line and the TUI renders that instead of inferring product state from prose
(your fix 2a.4). Consequently: the dead "Another machine" branch is gone and "Relay conflict:"
now maps to "run pags up --force here to take it over"; "WebSocket relay"/"CONNECTED" no
longer turn the REGISTRATION light green; the heartbeat has its own state and clears on recovery;
"Runtime registered with PAGS ✓" is no longer unconditional (N/M agents); padEnd(13) with a
13-char label became a derived width, so ProAgentStorenot registered is fixed; and "this takes a
few seconds" becomes Still connecting — 4m elapsed. Press l for logs. past 30s.

What is NOT verified, and what would close this

• The wake test itself. I cannot sleep the laptop. Closing this needs: upgrade to 0.4.47
  (npm i -g @proagentstore/cli), pags up, sleep ≥5 minutes, wake — then every agent
  attached again with no keypress and no --force.
• Network-kill-for-2-minutes → pane returns to green — same, needs a human at the machine.
• The blocked-clearing loop is straight-line I/O in relay.ts and has no test of its own; the
  behaviour it depends on (/status reporting false once the holder is gone) is the probe above.

Leaving this open until the wake test is run on 0.4.47. Everything else in the issue is done.

[serge-ivo]

669e0af4 — one more retry gap in §1a, shipped in @proagentstore/cli@0.4.53 (published). Still open: the wake test.

Picked this up to verify ca78f6a before changing anything, per the "verify the current reconnect
path first" instruction. The reconnect path is intact and I did not touch it. What I found is one
layer below it.

The gap: a register the SOCKET outran has no retry at all

ca78f6a made the register ride the RECONNECT, which is right and is what fixes the wake. It left
the case where the socket comes up and POST …/runtime is the thing that fails.

registerRuntime has exactly three callers and none of them can reach that state:

• the startup loop — already run;
• a discovery ATTACH — diffMembership's attach set excludes anything already attached
  (membership.ts:63), so the 20s poll never revisits an instance whose socket is fine;
• onOpen — only fires again if the socket drops, which on a machine that stays awake may
  never happen.

So the machine sits with a live relay and no instance_runtime_nodes row until the CLI is
restarted. That is exactly the asymmetry in your screenshot — secure link connected, ProAgentStore
not registered — and the startup line printed the policy out loud: "retried on each relay
(re)connect." That was the whole of it.

This is not hypothetical on the wake path either. A laptop coming out of sleep reaches the relay's
CDN edge before the API is reliably answering, so the register that rides the reconnect is itself
the call most likely to fail — and until now, failing there cost the agent its registration for
the rest of the process's life.

Fix: pendingRegistrations(attached, registered) (pure), consulted on each 20s discovery pass.
A detached instance drops out of the retry by construction rather than by a second rule that could
disagree with the first. Silent when healthy — an empty list writes nothing, so a working runner
gains no log line every 20s — and the pane's ✗ can now clear without a restart, because
reportRegistration() runs when the set changes. The upsert is idempotent, so the broken case
costs one POST per broken instance per poll.

Watched failing: both wiring assertions read startDiscovery from source and fail with the retry
removed. The defect WAS the absence of a call site, and a pure function nobody calls passes every
test it has.

Verified live — the end state on this account is now healthy

GET /v1/terminals/nodes, 2026-08-15 21:17 UTC:

machine	version	relay sockets live	detached
RLs-MacBook-Air.local	0.4.51	20 of 23	3
Sergeys-Mac-mini.local	0.4.45	8 of 21	13

Against the 6-of-19 in the issue body, that is the recovery working. Every detachment was checked
individually and all of them are correct: 15 of the 16 are pinned to the other machine
(isEligible declines them by design), and the sixteenth — 26f71cd8… "Chess coder", pinned to
Mac, which IS the Air — is not in /v1/instances/my/instances at all. It is a stale
instance_runtime_nodes row for a cancelled instance, last seen 2026-08-08 on runner 0.4.40, and
not attaching it is right. No agent is stranded on either machine.

Also worth recording: machine.names on the Air is
["RLs-MacBook-Air.local","RLs-MacBook-Air","Mac"], so #379's alias half is doing its job — a pin
made under Mac resolves here rather than reading as "pinned to another machine".

Still open, and it still needs you

• The wake test. npm i -g @proagentstore/cli (0.4.53 is on npm now), pags up, sleep the
  laptop ≥5 minutes, wake it — then every agent attached again with no keypress and no
  --force. I cannot sleep the machine.
• Network killed for 2 minutes → the pane returns to green by itself. Same. This one is
  the criterion the new retry most directly serves: kill the network long enough for a register
  to fail while the socket recovers, and before 0.4.53 the ✗ would have stayed until restart.
• Sergeys-Mac-mini.local is still on 0.4.45 — it has none of this. Upgrading it is the other
  half of any wake test that involves that machine.

Everything else in the issue is delivered. Leaving it open on those two boxes, consistent with the
earlier comment.

[serge-ivo]

Audit verdict: delivered — closing, with the production state re-measured today.

Shipped in ca78f6a3 + 669e0af4, published as CLI 0.4.47 (3da2b3fa); npm view @proagentstore/cli version → 0.4.54 today, and both live nodes report runnerVersion: 0.4.54, so the fix is what is actually running.

AC	verdict
2. 4409 only after the incumbent answers a ping	Met. relay-do.ts:51 keeps ping/pong bookkeeping, :116 — "A pong is not noise — it is the ONLY evidence that the peer holding this slot still exists (#497). Dropping it here is what let a frozen runner look alive." Both directions in lib/relay-liveness.test.ts
3. a blocked instance re-attaches once the conflict clears, no CLI restart	Met. relay.ts:203-210 — one cheap status GET per blocked id per discovery pass, then blocked.delete(id). The add-with-no-delete the ticket found is gone
5. registration completes after starting with the network down	Met. membership.ts:104 pendingRegistrations() + relay.ts:253 retries per poll; relay.ts:115 re-registers on every socket open, so registration now rides the reconnect path
6. an unreachable API shows ✗, not ✓	Met. status-line.ts (new) replaces prose-matching with an explicit machine-readable status line — item 4 of the ticket's own "fix, cheapest first", i.e. the better answer rather than the cheap one
7. a 4409 renders in the pane with its remedy	Met. up.ts:206-215 — the dead "Another machine" branch is deleted, with the reason inline, and replaced by "Relay conflict:" / "Relay conflict cleared:"
8. labels align	Met. tui.ts:66 records padEnd(13) against a 13-character label; LABEL_WIDTH at :115. §2b also fixed: connectingNote() at :88 switches to Still connecting — Nm elapsed. Press l for logs. past 30s

ACs 1 and 4 (sleep a laptop; kill the network for two minutes) I could not run — they need physical access. What I could do is re-measure the production state that produced the ticket:

	at filing (2026-08-11)	today
RLs-MacBook-Air.local, relay sockets live	6 of 19	13 of 13 instances pinned to it
CLI on that node	0.4.45	0.4.54

The six agents the ticket named as permanently detached and pinned to the Air (iTerm2 Operator, kitty Operator, Terminal Operator, tmux Operator, Chess coder, …) all read connected: true today.

One row in /v1/terminals/nodes still reads detached on the Air — 26f71cd8…, name "Chess coder", pinnedNode: "Mac". It is not a residual of this bug: that id is absent from /v1/instances/my/instances (42 active instances, and the live "Chess coder" is bfc76603…, which is connected). It is a runtime-node row for an instance that no longer exists — the same family as #649/#67, not this ticket.