palios-taey

Claude Code API Watchdog — Development skill for Claude Code

Development community

Auto-recover Claude Code sessions stuck on transient API errors.

How to install Claude Code API Watchdog

This entry records only its repository, not the path inside it, so there is no exact command to give. Open palios-taey/claude-code-api-watchdog and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Claude Code API Watchdog does

Auto-recover Claude Code sessions stuck on transient API errors. Outer-loop watchdog for unattended tmux Claude Code with usage-limit discrimination, exponential backoff, and 10-retry cap. Single file, no third-party deps.

Alternatives in Development

Agentcontrolplane — ACP is the Agent Control Plane - a distributed agent scheduler optimized for simplicity, clarity, and control 463 ★
Stuck 스킬 (/stuck) — 관찰 위치: Claude Code 내부 아키텍처 등록: registerBundledSkill('stuck' 149 ★
Diagnosing Bugs — PHẢI dùng khi: đang stuck với bug khó reproduce, không biết debug từ đâu, đã fix nhiều lần mà bug vẫn quay lại 90 ★

README

claude-code-api-watchdog

Auto-recover Claude Code sessions that get stuck on **transient API errors**.

The problem

If you run Claude Code in automation — overnight loops, agent fleets, unattended tasks — you've hit this: the session dies at 2am because the Anthropic API hiccupped for a few seconds. A `529 overloaded`, a transient `429` that is explicitly *not* your usage limit, a `500`, a connection reset. The TUI stops at the prompt waiting for a human to type "Continue". Your loop is dead until you wake up.

This watchdog watches your Claude Code tmux sessions and types `Continue` for you when it detects a *transient*-error state at the prompt — a heuristic that deliberately requires the error to persist across two consecutive polls before acting, and that can in principle misfire on a pane *displaying* error text (see "How detection works (and its limits)" below). It distinguishes transient errors from real usage limits (which it leaves alone, because hammering a usage limit just wastes attempts) and backs off exponentially.

**Point this at UNATTENDED automation sessions — not the interactive session you're actively working in.** Detection is pane-scrape; the safe scope is "panes where a human isn't typing." Run it with `--dry-run` first to watch what it *would* do before you trust it live.

What it does

Polls each named tmux session every N seconds (tmux capture-pane)
Detects a stuck transient-API-error state at the prompt
Requires the transient-error state on two consecutive polls before acting (debounce against single-frame redraws and momentarily-displayed error text)
Logs every poll in a machine-greppable line: "[] [watchdog] poll session= state= action="
Injects Continue with exponential backoff (2s → 4s → … → 120s cap) and a 10-attempt cap, then escalates and stops