Incident review · August 22, 2026

Vehicle Thread Did Not Crash

The first run overran its context budget, compressed twice, then answered a mid-run diagnostic instead of closing the vehicle task.

46m 50sFirst run

228Tool calls

2×Compressions

HighConfidence

Root cause: unbounded execution, not a Slack or gateway outage. The turn accumulated large searches, file reads, diffs, builds, and browser checks. Two context splits followed. Devin’s settings question was steered into the active run; ForgeBot then returned that diagnostic as the final answer, leaving the original task without closure.

Evidence

The lineage grew from 176 messages / 110 tool calls to 408 / 221 before the second split. Several tool results were 55–89K characters. Slack shows the compression warning and diagnostic answer, but no vehicle completion in the original thread.

What rules out a crash

The gateway logged one healthy inbound run, both session splits, a ready response, and a Slack send. No exception or timeout appeared. The replacement thread later completed the implementation and production verification.

Contributing factor

The installed Hermes build is materially behind current upstream. Current Hermes documentation now describes native/in-place compaction options and stronger context controls, reducing session-split risk.

Corrective action

Bound tool output, checkpoint before a second scope, and preserve the original task after steering. Update Hermes, enable in-place/native compaction where supported, and add a regression check that every admitted task receives a terminal answer.

Sources: original thread · successful continuation · Hermes compression documentation · local session database and gateway logs.