claude-code - 💡(How to fix) Fix [CCR Beta] Routine sessions stuck in infinite loop after API error — Esc key does not stop execution

Summary

CCR (Claude Code Routines) sessions enter an infinite restart loop when an API error occurs mid-execution. The session infrastructure automatically resumes ("Sessão retomada") after each error, preventing the session from ever terminating. Pressing Esc has no effect.

Environment

• Platform: Claude Code Web (claude.ai/code)
• Feature: Routines (CCR) — Beta
• Trigger ID: trig_01J8RVqbMUbqcAe5e75uJXEw
• Routine name: sre-skill-telemetry-update
• Schedule: Daily at 8:30 AM GMT-3

Affected sessions

Steps to reproduce

1. Create a CCR routine that uses ScheduleWakeup internally (e.g. a /loop-based skill)
2. Trigger an execution (manual or scheduled)
3. When an API error occurs mid-session, the CCR infrastructure automatically resumes the session
4. The resumed session hits another API error → resumes again → infinite loop
5. Pressing Esc inside the stuck session has no effect
6. The session remains in "Em execução" (In Execution) status indefinitely

Observed behavior

• Session UI shows repeated "Sessão retomada" (Session resumed) entries
• Each resumption triggers a new API error: An error occurred while executing Claude Code. You can try again by sending a new message or starting a new session.
• A "Limite de uso se aproximando" (Usage limit approaching) warning appears — stuck sessions are consuming usage quota
• No UI mechanism stops the loop (Esc, page refresh, "Tentar novamente" all ineffective)
• Latest iteration is now spinning up a new cloud container from scratch on each loop, amplifying resource consumption

Expected behavior

• Sessions should NOT auto-resume after an API error without explicit user confirmation
• Esc should reliably interrupt an in-progress CCR session
• There should be an explicit "Stop/Cancel execution" button per session in the Routines UI
• Usage quota consumed by stuck/looping sessions should not count against the user's limit

Impact

• 3 sessions stuck simultaneously for the same trigger (oldest: 3+ days)
• Usage quota being actively drained by non-productive loops
• No user-accessible way to terminate stuck sessions
• Container provisioning on each iteration suggests significant infrastructure waste

Workaround (partial)

Pausing the trigger (enabled: false via API) prevents new executions from being scheduled, but does not terminate already-running sessions.