Found while reviewing checkpoint coverage against Claude Code's current hooks reference.
Problem
The Claude Code onboarding wires the StopFailure hook with matcher rate_limit only (src/cli/mcp-config-claude-code.ts, StopFailure:rate_limit in the continuation config enum). But Claude Code's StopFailure event distinguishes many failure types: rate_limit, overloaded, server_error, max_output_tokens, authentication_failed, billing_error, unknown, and others.
Result: when the model itself dies — API overloaded, server error, output-token cap — no fallback checkpoint is written. Those are exactly the deaths a continuation checkpoint exists for, and they are indistinguishable from a rate limit from the user's chair.
Failure scenario
Session is mid-task with accumulated task state. The API returns overloaded. The turn ends, the StopFailure hook fires with matcher overloaded, nothing matches, no packet is written. The next session starts with no checkpoint offer, even though the deterministic fallback (task scratchpad + git state) needed no model call and could have completed.
Suggested fix
Widen the default matcher to the failure types that mean 'the session is over through no fault of the work': rate_limit|overloaded|server_error|max_output_tokens|unknown — or make the matcher list configurable alongside the existing continuation.claudeCode.events. The deterministic script fallback already works for all of these; only the trigger is missing.
Found while reviewing checkpoint coverage against Claude Code's current hooks reference.
Problem
The Claude Code onboarding wires the StopFailure hook with matcher
rate_limitonly (src/cli/mcp-config-claude-code.ts,StopFailure:rate_limitin the continuation config enum). But Claude Code's StopFailure event distinguishes many failure types:rate_limit,overloaded,server_error,max_output_tokens,authentication_failed,billing_error,unknown, and others.Result: when the model itself dies — API overloaded, server error, output-token cap — no fallback checkpoint is written. Those are exactly the deaths a continuation checkpoint exists for, and they are indistinguishable from a rate limit from the user's chair.
Failure scenario
Session is mid-task with accumulated task state. The API returns
overloaded. The turn ends, the StopFailure hook fires with matcheroverloaded, nothing matches, no packet is written. The next session starts with no checkpoint offer, even though the deterministic fallback (task scratchpad + git state) needed no model call and could have completed.Suggested fix
Widen the default matcher to the failure types that mean 'the session is over through no fault of the work':
rate_limit|overloaded|server_error|max_output_tokens|unknown— or make the matcher list configurable alongside the existingcontinuation.claudeCode.events. The deterministic script fallback already works for all of these; only the trigger is missing.