Unbounded hourly PR-watch self-check-in has no cost cap — drained a session's usage over 4 days

Summary

Claude Code sessions that create a GitHub PR are instructed (per the harness's GitHub-integration system prompt) to subscribe to the PR's webhook AND separately self-schedule an hourly send_later "check-in" that keeps re-arming itself every time it fires — with no cycle limit, no cost ceiling, and no time-based backoff or escalation. The only exit conditions are: the PR merges, the PR closes, or the user explicitly says "stop."

In practice this means a session can sit there firing a full agent turn every hour, indefinitely, for a PR that simply isn't getting attention — burning usage the whole time.

What happened

A session opened a PR, marked it ready for review, and (per the standard instructions) began an hourly watch loop. The owner didn't merge or comment on the PR for several days. The loop kept re-arming successfully every hour and ran for roughly 4 days / ~50 cycles before the owner noticed and asked for it to stop.

Each of those ~50 cycles was a full agent turn that:

• Reloaded the entire project CLAUDE.md (thousands of tokens) as system context
• Repeatedly reconnected/reloaded MCP tool schemas (the GitHub MCP connector dropped and reconnected almost every cycle, forcing a ToolSearch reload each time)
• Ran one cheap PR-status check
• Concluded "nothing changed" and silently re-armed for another hour

So the overhead surrounding the check dwarfed the actual check — this wasn't ~50 cheap API calls, it was ~50 full-context agent turns.

Why this session specifically ran so long

I checked several other sessions with the same PR-watch behavior; their check-in chains all died out after 1-2 cycles (likely due to context compaction or the session not being resumed). This session's chain simply kept succeeding turn after turn because nothing broke it, and the PR was never merged/closed/stopped — so it ran to the (non-)natural conclusion of "forever" instead.

Evidence

| Fact | Value |
|---|---|
| Session ID | session_01VgqMhSKnYVKxmW4k5DthHa |
| PR being watched | https://github.com/atomicapps-ai/convasist/pull/1 |
| First self-scheduled check-in | 2026-07-09 ~21:11 UTC |
| Last one before intervention | 2026-07-13 |
| Approx. cycle count | ~50 hourly firings over ~4 days |
| Root cost driver | full CLAUDE.md + MCP reconnect overhead reloaded every cycle just to report "no change" |

Suggested fix

• Cap the number of self-re-armed check-in cycles (or elapsed time) before the loop must stop and instead just notify the user once, rather than polling forever.
• Prefer resuming only on real webhook events (free) over timer-based polling that reloads full session context every time.
• If polling must continue, avoid re-injecting the full project instructions/system prompt on every wake-up when nothing has changed since the last check.

Ask

Requesting a usage-credit adjustment for the session above, given the check-in loop ran exactly as designed/instructed with no available user-facing control to cap or disable it in advance.