-
-
Notifications
You must be signed in to change notification settings - Fork 80.7k
Feature request: Escalating stall recovery for sub-agents (nudge → kill) #39305
Copy link
Copy link
Open
Labels
P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.Emergency: data loss, security bypass, crash loop, or unusable core runtime.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.Channel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.Session, memory, transcript, context, or agent state can drift or corrupt.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.A non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Description
Metadata
Metadata
Assignees
Labels
P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.Emergency: data loss, security bypass, crash loop, or unusable core runtime.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.Channel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.Session, memory, transcript, context, or agent state can drift or corrupt.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.A non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Type
Fields
Priority
None yet
Problem
Sub-agents can stall indefinitely while remaining in "running" status. Today the only automated protection is
runTimeoutSeconds(wall-clock cap), which can't distinguish active work from a stalled agent. Manual detection requires checkingsessions_historytimestamps — unreliable since LLMs have no internal timers and can't self-trigger checks.Proposed solution
A two-stage stall recovery system that monitors time since last tool call per sub-agent:
Stage 1 — Nudge (
stallNudgeSeconds): After N seconds of no tool calls, inject a system message ("You appear stalled — resume your task or report what's blocking you"). Cheap, might recover agents that are confused or lost.Stage 2 — Kill (
stallTimeoutSeconds): If no tool call within M seconds after the nudge, auto-kill the agent and notify the parent session. Backstop for cases where nudging can't help (dead-on-arrival, context exhaustion, hung tool calls).Config:
{ "agents": { "defaults": { "subagents": { "stallNudgeSeconds": 90, "stallTimeoutSeconds": 180 } } } }Also available as per-spawn overrides on
sessions_spawn.Why both stages?
Related issues
stallTimeoutSecondsfor streaming chunk gaps (model-level, not sub-agent tool calls)lastRunActivityAt) — potential infrastructure for this