Measured 2026-08-27 5:40-5:42 PM CDT. no-slop axi sync --recover fails for multiple worktrees with exactly one line:
classify gate execution context: read response: read unix ->/Users/blakeolson/.no-mistakes/socket: i/o timeout
Key discrimination: the same daemon answers no-slop axi status for the same worktree immediately and completely. So the daemon is alive and responsive on the status path; only the classify call used by custody recovery times out. Reproduced three times on competitor-sweep-2-land-wt at Mac load 24 (not just under the earlier load-66 saturation), so this is not simple overload.
Impact: any run that ends in pipeline_owned with next_action.code = recover_custody cannot be recovered and therefore cannot relaunch. Currently affecting at least 7 worktrees (competitor-sweep-2, inspiration-capture, tmo120, tmo163, tmo242, tmo247, tmo285). Those gates are permanently stuck without operator intervention.
Suspected shape: the classify path does work proportional to the number of registered runs/repos (this daemon has 100+ registered) or blocks on a lock the status path does not take, and its client-side read deadline is too short for that work.
Asks: (1) give the classify call a deadline proportional to its real cost, or make it incremental; (2) surface a distinct exit condition for 'daemon reachable but classify timed out' so callers can back off rather than reporting generic custody failure; (3) provide a recovery path that does not require classify when the branch state is already unambiguous.
Measured 2026-08-27 5:40-5:42 PM CDT.
no-slop axi sync --recoverfails for multiple worktrees with exactly one line:Key discrimination: the same daemon answers
no-slop axi statusfor the same worktree immediately and completely. So the daemon is alive and responsive on the status path; only the classify call used by custody recovery times out. Reproduced three times on competitor-sweep-2-land-wt at Mac load 24 (not just under the earlier load-66 saturation), so this is not simple overload.Impact: any run that ends in
pipeline_ownedwithnext_action.code = recover_custodycannot be recovered and therefore cannot relaunch. Currently affecting at least 7 worktrees (competitor-sweep-2, inspiration-capture, tmo120, tmo163, tmo242, tmo247, tmo285). Those gates are permanently stuck without operator intervention.Suspected shape: the classify path does work proportional to the number of registered runs/repos (this daemon has 100+ registered) or blocks on a lock the status path does not take, and its client-side read deadline is too short for that work.
Asks: (1) give the classify call a deadline proportional to its real cost, or make it incremental; (2) surface a distinct exit condition for 'daemon reachable but classify timed out' so callers can back off rather than reporting generic custody failure; (3) provide a recovery path that does not require classify when the branch state is already unambiguous.