Detect and surface stuck/no-progress agent loops

[perixtar]

Context

Launch feedback asked how AgentRouter handles models that get stuck in long-running edit loops. This is a real production concern for agent workflows that edit repos, run commands, and retry tasks.

Problem

Agents can spend time repeating the same failed command, editing the same file without a meaningful diff, producing lots of output without state changes, or cycling through the same intermediate failure. Product teams need the runtime to surface these conditions clearly.

Proposed direction

Add no-progress detection signals to the runtime. The runtime does not need to fully solve every stuck loop automatically, but it should detect and expose suspicious patterns so product callers can cancel, retry, ask for approval, or resume from current sandbox state.

Acceptance criteria

• Track repeated command execution with similar output/failure.
• Track repeated file edits with no meaningful patch or equivalent patch churn.
• Track long output periods without run-record state transitions.
• Emit no-progress or suspected-loop events when thresholds are crossed.
• Surface loop/no-progress signals in the run record and SDK event stream.
• Add tests for repeated command and repeated edit detection.

Notes

The first version can be heuristic. The value is observability and control, not perfect automatic recovery.

[perixtar]

What changed:

• AgentRouter now emits agent.no_progress when the runtime sees suspicious no-progress patterns like repeated failed commands, repeated edit attempts, or long provider output without state transitions.
• The signal is persisted in the run record, session event archive, and manifest, so dashboards and audit views can replay when it happened.
• The TypeScript SDK exposes it as part.type === "no_progress" in stream.fullStream.
• Added a runnable recipe: pnpm example:recipe:no-progress.
• Added coverage for both Codex and Claude Code, including real Daytona + actual provider CLI E2E tests.

Closing this as implemented. If we find a new stuck-loop pattern that the heuristics miss, we should open a follow-up with the concrete event/output shape and add it to the detector.