The MCP server (coord mcp) keeps a connected member's presence fresh via a 5-min status-mtime refresh, and on shutdown writes offline. But on connect it does not assert available itself — that relies on the agent following the server's on-connect instruction (coord status <id> --set available), which the instructions scope to a fresh context (cold start / /clear).
The gap: a session that reconnects/resumes (not a cold start) never re-asserts available, and the refresh timer only preserves the stored value. So if the prior session wrote offline on shutdown, a resumed-and-reconnected member reads offline to peers indefinitely despite being alive with a healthy, ticking MCP.
Repro (single throwaway root):
$ mkdir -p $COORD_ROOT/me/{inbox,archive}
$ COORD_IDENTITY=me coord status me --set available # alive
$ COORD_IDENTITY=me coord status me --set offline # simulate a prior clean shutdown
$ # now connect an MCP session (initialize + initialized), leave it running:
$ COORD_IDENTITY=me coord mcp --channel < <handshake> # healthy, timer ticks
$ coord status me
offline # stays offline despite a live MCP
This bites long-lived / supervised standing sessions hardest: a Nix-supervised session that crash-respawns and resumes comes back alive but invisible (offline) to peers until something explicitly re-sets it.
Suggested direction: on the initialize handshake, if the member's stored status is offline (or the file is missing), have the server write available — a connect means the member is alive. Preserve an explicit busy/dnd (don't clobber deliberate intent); only the stale offline / missing case needs the assert. That makes presence correct on every connect, cold or resumed, without depending on the agent to re-run the instruction.
(Filed from a downstream multi-host deployment running supervised standing sessions that respawn-and-resume.)
The MCP server (
coord mcp) keeps a connected member's presence fresh via a 5-min status-mtime refresh, and on shutdown writesoffline. But on connect it does not assertavailableitself — that relies on the agent following the server's on-connect instruction (coord status <id> --set available), which the instructions scope to a fresh context (cold start //clear).The gap: a session that reconnects/resumes (not a cold start) never re-asserts
available, and the refresh timer only preserves the stored value. So if the prior session wroteofflineon shutdown, a resumed-and-reconnected member readsofflineto peers indefinitely despite being alive with a healthy, ticking MCP.Repro (single throwaway root):
This bites long-lived / supervised standing sessions hardest: a Nix-supervised session that crash-respawns and resumes comes back alive but invisible (
offline) to peers until something explicitly re-sets it.Suggested direction: on the
initializehandshake, if the member's stored status isoffline(or the file is missing), have the server writeavailable— a connect means the member is alive. Preserve an explicitbusy/dnd(don't clobber deliberate intent); only the staleoffline/ missing case needs the assert. That makes presence correct on every connect, cold or resumed, without depending on the agent to re-run the instruction.(Filed from a downstream multi-host deployment running supervised standing sessions that respawn-and-resume.)