Make `StopFailure` hook output actionable so failed turns can auto-recover
Problem
When a turn dies mid-stream with API Error: Stream idle timeout - partial response received, the model has typically already done meaningful work (reasoning, partial output, partial tool calls). Today there's no way to auto-recover — the user has to notice the red error, manually re-issue a continuation, and hope they remember exactly what was in flight.
I'd like to wire this into a StopFailure hook so recovery is automatic. From what I can tell in the docs, that's not currently possible: the hook fires when the failure happens (good), but its output is ignored — so it can observe the failure but can't trigger a retry or continuation. None of the other hook events fire after a stream error in a way that lets them act.
What I'd want
Something like one of these, in rough preference order:
StopFailurereturns a structured retry directive. Hook output JSON like{"action": "retry"}re-issues the failed turn from scratch. Optional{"action": "retry_with_prefill", "prefill": "<partial_assistant_output>"}lets the harness prefill the assistant message and continue from where streaming died — the model treats it as continuation, not restart.
- A new
OnRecoverable(or similar) hook event that fires afterStopFailurespecifically for recoverable error classes (stream timeout, transient API errors), where the output IS actionable. KeepsStopFailureas the informational layer; adds a separate event for action.
- An explicit slash-command-injection primitive that any hook could use —
{"hookSpecificOutput": {"runSlashCommand": "/c"}}or similar. Useful beyond just this case (e.g., auto-running a custom continuation skill after errors, auto-running a checkpoint after large changes). Slash commands are user-initiated by design today, but a hook saying "act as if the user typed this" would unlock a lot of workflow automation.
Use case
I run a multi-hour autonomous trading research workflow where Claude Code is doing real implementation work. When the stream times out mid-implementation:
- The partial output isn't lost (it's still in the transcript)
- But the turn is dead — Claude is waiting for me to do something
- I have a custom
/c(continue) skill that reads transcript + uncommitted state + git status and resumes, but it's a manual keystroke - For overnight or AFK sessions, those manual keystrokes mean the session stalls until I notice
A hook-driven auto-recovery would turn this from "session dies until human checks back" to "session retries itself, human notices later that it kept going."
Workarounds considered
- Stop hook with alert / additionalContext. Doesn't solve it —
additionalContextis added to the next turn's context, but doesn't trigger a turn. The session still stalls until the user types something. - External wrapper daemon polling transcript files and using session-resume APIs. Possible but heavyweight, and depends on implementation details that aren't part of the public surface.
/cmanually. What I do today. One keystroke when I see the red error. Works, but doesn't compose with AFK / overnight workflows.
Note on hook output handling
If StopFailure output is not actually ignored and I'm misreading the docs, please correct me — happy to be wrong here. The summary I'm working from is "informational only, no actionable output" but I haven't tested every payload shape.
Thanks for considering. Even a documentation clarification on what StopFailure output can do today would be useful.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗