Fleet blocked: the no-mistakes gate agent hangs alive-and-idle on silent API reads, so no task can pass its test step

[HelloWorldSungin]

Full evidence, gathered on the host rather than inferred: data/fm-ci-red-trap-and-timing/agent-hang-evidence.md in the primary home.

Symptom

The test step agent starts, emits one line, then sits alive and idle until the tool gives up at its 30-minute cap with claude parse events: context deadline exceeded. It is blocked in epoll_wait on open, silent HTTPS connections to the Anthropic API, consuming about 0.9% CPU. It never runs a suite.

Every test step on this host succeeded through 00:48 UTC and every one since 01:24 UTC has stalled, on more than one branch.

Why this blocks the whole fleet, not one task

The pipeline is configured agent: [claude, codex]. Codex is at zero quota until 2026-09-07, and the tool refuses pi and opencode as gate agents by design ('gate agent %q does not neutralize...'). So claude is the only usable gate agent this week, and while it hangs, no no-mistakes task in the fleet can pass its test step.

Ruled out, each by a check rather than by reasoning

• Not the provider, not our quota. A direct claude -p invocation on this host with the same pinned model (claude-opus-5) returns promptly, exit 0. Claude quota was at 60% remaining, through_reset.
• Not the CLI version. The claude binary was repointed to 2.1.259 at 22:58 UTC, which is before the last successful test step at 00:48. The same version both worked and stalled.
• Not firstmate hooks leaking into pipeline worktrees. ~/.no-mistakes/worktrees/*/ carry no .claude/settings.json, so guard changes landing at 01:19 cannot reach an agent there. Checked specifically because that merge sat suspiciously close to the 01:24 boundary.
• Not host load. Load average 5.01 on 24 cores.

That leaves the tool's own invocation path: it waits for events on a stream that is open and silent, while the same model answers a plain invocation immediately.

Candidate remedy, and why it is not ours to apply unilaterally

Installed no-mistakes is v1.57.0; v1.60.2 is available. A three-version gap, and the failure is in agent event parsing - exactly the area that gets fixed between releases. Upgrading a shared tool serving every project is a captain decision, so it is with him.

Do not

• Do not raise test_agent_timeout. It is a real config key and unset, so the 30-minute default applies - but the agent is hung, not slow. A larger cap buys a longer hang, and widening a bound to accommodate a defect is how an intermittent true signal becomes a permanent false pass.
• Do not hand-push and hand-open PRs around the gate. One worker proposed this and was overridden: it produces a change that looks validated while the artifact that ships never went through the steps making that claim true.

State of the blocked work

fm-ci-red-trap-and-timing completed review with zero findings after three fix rounds. Every commit is preserved at refs/no-mistakes/recover/01M1JE4XKVNS7HG46D0J4JP7E8, head d1e2c1eb. Custody return refused twice as blocked_recover_diverged with no supported adopt flag, and no refs were changed. Nothing is lost; the work is stuck, not gone.

[HelloWorldSungin]

Independently reproduced on a second branch, fm-test-suite-robustness, minutes after the first write-up and with no shared state between the two runs.

Identical signature: the test-step agent hung in epoll_wait on open-but-silent API connections for the full 30 minutes, then died on SIGTERM at exit 143 without ever running a suite.

That removes the last reading in which this is specific to one change or one branch. Two unrelated tasks, two independent runs, same failure.

Both workers are parked and neither is re-running. Neither raised test_agent_timeout, and neither pushed or opened a PR by hand.