Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1The agents relay wedges: HTTP stops answering while its digest timer keeps running, and the tell is a ROSTER JSON.parse of a TRUNCATED payload at power-of-two boundaries (65536, then 524288). Measured 2026-09-16 06:18-06:23Z: relay pid 1928 held 127.0.0.1:8791 in process state U and answered NOTHING on localhost (5 probes, all timed out at 12s), so Cloudflare returned 502 and /agents was down for Gera. The box was NOT overloaded: load 3.33, 387Gi disk free, 53 of 1048576 fds, 78% memory free. launchctl kickstart -k cured it in ~24s (new pid, state S, HTTP 200 in 0.0025s, ROSTER refreshed count=84 alive=4). RULED OUT: execFile maxBuffer (4MB/16MB, far above both truncation points) and runClaudeAgents (roster.ts:621-646 rejects on error BEFORE JSON.parse). NOT FOUND YET: which JSON.parse inside refresh() throws on a partial payload and propagates to roster.ts:846. Candidate shape: a seek-truncated transcript tail whose FIRST line is cut mid-string — contextUsage.ts:125 swallows exactly that with try/continue, so look for a sibling reader that does not. The roster is 84 sessions and growing, the truncation point MOVED UP between two consecutive failures, and when refresh fails the HTTP handlers that await it HANG rather than degrade.
In plain terms. The agents page went down tonight because the program behind it stopped answering while still looking alive from the outside. Restarting it fixed it in under a minute, and the machine was not overloaded — it had plenty of memory, disk and spare capacity. The underlying cause is that this program reads a list of every running session, that list is now big enough to get cut off halfway, and when that happens the whole page hangs instead of showing slightly stale information. Fixing the reading means one bad line no longer takes the page down; adding a watchdog means the page restarts itself next time instead of staying dark until someone notices. Doing neither means it happens again, and more often as we run more sessions.
The session raising this recommends: Make roster reading non-fatal AND add a watchdog that restarts it The two halves fix different failures and neither substitutes for the other. Non-fatal parsing stops one bad line taking the whole roster down, and there is precedent in the file: contextUsage.ts:125 already does try/catch/continue for exactly this shape, so the strict siblings are the outliers. The watchdog is the half that would have saved the outage: health.ts:637 ALREADY knows how to report 'roster (stale — the last refresh failed)', so the relay can detect this state and nothing acts on it. Fixing only the one reader is not enough because the payload keeps growing and the next reader to cross a boundary reintroduces it. Tried first, unsuccessfully: Not consulted: Fable's seat is walled until 2026-09-17 19:00 America/Chicago (weekly limit), and this was raised during a live outage rather than held for the next decider sweep. Tried first and recorded above: ruled out maxBuffer and the agents --json path by reading the code, and proved the box was not resource-starved by measuring disk, fds, memory and load. The relay is already restored, so nothing is blocked on this answer — only the durable fix is open.