Make `StopFailure` hook output actionable so failed turns can auto-recover

Resolved 💬 1 comment Opened May 11, 2026 by wesleysmyth Closed Jun 11, 2026

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:

  1. StopFailure returns 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.
  1. A new OnRecoverable (or similar) hook event that fires after StopFailure specifically for recoverable error classes (stream timeout, transient API errors), where the output IS actionable. Keeps StopFailure as the informational layer; adds a separate event for action.
  1. 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 — additionalContext is 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.
  • /c manually. 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗