[BUG] Cloud session keeps rescheduling hourly PR check-ins with no limit, silently draining cloud credits
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
After Claude Code on the web opened a draft PR in a cloud session, it started monitoring that PR on its own, without asking me. It scheduled a one-shot reminder ("Re-check PR #111") to wake the session about an hour later, and every wake-up scheduled the next one.
The PR never changed, so this chain ran for about 3 days (65+ wake-ups), and every wake-up consumed my cloud session credits. None of the runs did anything useful: each one re-read the PR, found it unchanged (draft, no conflicts, no reviews, the only check passing), and scheduled the next check.
- The only stop condition was "PR merged or closed". A draft PR waiting on its owner's decision never gets there on its own, so in practice the loop had no end.
- I was never asked for consent and never told that monitoring would cost credits.
- There was no notification, email, or budget alert. The only trace was a one-line status message per wake-up inside the session transcript, which I had no reason to open.
- The MCP servers disconnected and reconnected around almost every wake-up, so each run also reloaded tool schemas, adding overhead to every run.
- It stopped only when I noticed my credit balance ($58 of $250 left) and told the agent to stop.
What Should Happen?
- Once the task I asked for is done (here: write a document and open a PR), the session should go idle and stop consuming credits.
- If Claude wants to monitor a PR, it should ask first and say clearly that monitoring uses credits.
- Any monitoring should have a hard limit, e.g. stop after 3 consecutive no-change checks or 24 hours, then notify me and ask whether to continue.
- Scheduled wake-ups should be visible and easy to cancel, and credit usage from background runs should be shown per session.
Error Messages/Logs
No error was shown. Pattern from the session transcript (all times UTC). Each wake-up came from a self-scheduled one-shot reminder named "Re-check PR #111".
2026-09-23 06:20 draft PR #111 opened; the requested task was complete at this point
2026-09-24 07:58 hourly check-ins already running (the loop may have started earlier)
...
2026-09-26 03:04 wake-up -> PR unchanged (open, draft, mergeable: clean, 0 review threads, 1 check: success) -> next check scheduled +60 min
2026-09-26 04:07 same result -> rescheduled +60 min
2026-09-26 05:08 same result -> rescheduled +60 min
... repeats about every 61 minutes ...
2026-09-27 01:36 same result -> rescheduled +60 min
2026-09-27 02:37 same result -> rescheduled for 03:38
~2026-09-27 03:20 I noticed the credit drop and told the agent to stop; pending reminder deleted, PR activity unsubscribed
Total: 65+ wake-ups, 0 changes to the PR, 0 useful actions.
Status line posted to the transcript after each wake-up:
"PR #111 hasn't changed: still an open draft with no merge conflicts, its one check passing, and no reviews. It's waiting on your decision. Next check-in is around HH:MM UTC."Steps to Reproduce
- Open Claude Code on the web (claude.ai/code) and start a cloud session on any GitHub repo.
- Give it a task that ends with Claude opening a pull request, e.g. "Write a planning document in docs/ and open a PR." (In my case Claude opened it as a draft; the repo has no CI workflows.)
- Don't merge, close, or review the PR, and don't send any more messages to the session.
- Come back 1–3 days later and look at the session transcript and your cloud session credits.
Result: the session has woken itself up about every hour, re-checked the unchanged PR, and scheduled the next check each time, consuming credits on every run.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
N/A – Claude Code on the web (cloud session at claude.ai/code), version managed by Anthropic
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Environment
- Claude Code on the web (cloud session), followed from the Claude app
- Session ID: session_01PPARc8HVRSavTPo2nKNZFw
- PR: draft, docs-only; the repo has no CI workflows
- Timeline: PR opened 2026-09-23 06:20 UTC; the loop ran until I stopped it around 2026-09-27 03:20 UTC
Why this was hard to notice
- No consent prompt or cost notice when monitoring started.
- It's a chain of one-shot reminders, not a recurring job. At any moment there's only one pending reminder, and fired ones are hidden, so it never looks like a long-running task.
- The credits page only shows a total balance, with no per-session breakdown, so the usage looked like normal work.
Suggested fixes
- Make post-PR monitoring opt-in, with an explicit note that it consumes credits.
- Hard stop after N consecutive no-change checks or 24 hours, then notify the user.
- Exponential backoff when nothing changes, instead of fixed hourly polling.
- Rely on PR webhook events (the session was already subscribed) instead of polling, especially when the repo has no CI.
- Don't auto-monitor draft PRs, docs-only PRs, or PRs blocked only on the owner's decision.
- Show scheduled wake-ups in the session UI ("Next wake-up at HH:MM · Stop"), and show a self-rescheduling chain as one recurring Routine.
- Show credit usage per session, including background runs, and alert when background usage passes a threshold.
- Model side: after several identical check-in results, stop and ask instead of scheduling another check.
Workaround
Tell the session to stop monitoring the PR (it deletes the pending reminder and unsubscribes from PR activity), or delete the pending "Re-check PR #…" reminder from your Routines list.
<img width="1642" height="400" alt="Image" src="https://github.com/user-attachments/assets/f707af18-6da7-4061-ae29-9ddae48dde18" />
<img width="1538" height="1432" alt="Image" src="https://github.com/user-attachments/assets/97aab39e-b9e3-473e-898c-964bb8148eef" />
3 Comments
Same issue here (Pro plan, Claude Code on the web, Windows desktop app).
After I asked Claude to open a draft PR and check CI once, the session scheduled a follow-up check on its own and kept re-arming one-shot "Re-check PR #N state" reminders while the PR was open. I never asked for ongoing monitoring.
31 wake-ups over ~31 hours (2026-09-27 05:00 to 2026-09-28 11:55 UTC). After the first few, every one reported no change, using ~7 tool calls each.
When I asked it to cancel, every scheduler/GitHub/shell call failed 9 times in a row with a "no verdict" permission error, so the last reminder still fired.
No notification or usage alert. My cloud session credits and weekly usage were consumed while I wasn't using Claude.
Support (Fin) couldn't show a per-wake-up usage breakdown or escalate to a human.
+1 to the suggested fixes, especially a hard stop after N no-change checks and making post-PR monitoring opt-in.
Did you get any notice before those hourly re-checks started burning credits, or was the first signal just the balance dropping?
Same issue here, and it's not the first time it has happened to me.
The core problem: hidden instructions the user never sees
This isn't the model randomly deciding to babysit a PR. When asked, the session said it was following its default instructions: after creating a PR, subscribe to PR activity without asking, schedule a check-in about an hour out, and if nothing changed, re-arm silently without telling the user, until the PR is merged or closed.
I never saw these instructions, never enabled anything like this, and was never asked. They are injected into the session behind the user's back, and the "re-arm silently" part specifically ensures the user doesn't notice while their usage is being drained. Whatever the intent, the effect is predatory: an invisible, uncapped loop that burns the user's paid usage on work nobody asked for.
The interval makes it worse: ~61 minutes against a 1-hour cache
The session's own instructions state that its prompt cache lives for 1 hour. The same hidden instructions then schedule each check-in "roughly an hour out". In practice, they fired every ~61 minutes.
That's the worst possible interval. Each wake-up lands just after the cache expires, so the whole conversation (hundreds of thousands of tokens, growing every time) gets re-cached at the highest price instead of read from cache at a small fraction of that cost. Waking even a few minutes earlier would have kept the cache warm. By my estimate, the 61-minute timing alone made each wake-up several times more expensive than necessary.
So the loop was running on the most expensive model, ran without the user knowing, and was also timed to miss the cache every single time. The system knows the cache lifetime and schedules just past it anyway.
Environment
What happened
Usage impact
Expected behavior