Orphaned processes silently burn usage quota; dropped sessions continue running; unauthorized debit card charges

Claude Code Support Report — Excessive Usage Burn & Session Instability

Date: April 11, 2026
User: Julie Bush (Max plan subscriber)
Platform: macOS 15.7.5, MacBook Pro (Intel), 16 GB RAM
Claude Code version: Current stable (update available per status bar)

---

Issue 1: Excessive Usage Consumption While Idle

Summary

Between Friday April 10 at ~1:00 PM PT (when my weekly rate limit ended) and Saturday April 11 at ~2:00 PM PT — a period during which I was asleep for 14 of those 25 hours and did not interact with Claude Code at all after midnight — my account consumed 31% of my weekly usage limit and 12% of the current 5-hour rate limit session before I even opened a new terminal.

Root Cause (Self-Diagnosed)

Upon investigation at 2:13 PM on April 11, I discovered the following orphaned/stale processes still running on my machine:

1. 2 "ralph" automation loops (tmux sessions ralph-stella and ralph-declared) — these spawn Claude CLI sessions that make API calls. I had explicitly turned these off days earlier to conserve usage, but the kill did not propagate to the actual tmux sessions. These were burning API quota continuously.

1. 1 stuck --resume session (PID 79309, session ID 4ef5f461-31c0-4b01-83e9-f2ad2bf2a657) — had been running since Thursday 10 PM, accumulating 23+ minutes of CPU time over 40+ hours. This session was one I got dropped from (see Issue 2 below), and it continued running in the background consuming API quota after I was disconnected.

1. 53 orphaned headless Chromium browser processes (chrome-headless-shell) — spawned by the context-mode MCP plugin's Playwright integration. The oldest were 194 hours old (8+ days). While these don't directly consume API quota, on a 16 GB RAM machine they created severe memory pressure — likely contributing to the session instability described in Issue 2.

1. A com.ralph.watchdog launchd agent still loaded and running.

Key Concern

There is no built-in mechanism in Claude Code to detect or alert users about orphaned processes that are silently consuming their usage quota. When a session drops (see Issue 2), the underlying Claude process can continue running in the background, making API calls with no user interaction and no visibility. The user has no dashboard, no alerts, and no way to know this is happening until they hit their rate limit unexpectedly.

For context: I was rate-limited for nearly an entire week prior to this incident (see Issue 3 below), specifically tried to reduce usage by turning off automations, and then had my quota silently burned by orphaned processes. This is extremely frustrating.

---

Issue 2: Repeated Involuntary Session Drops (April 10-11)

Summary

After my weekly rate limit ended on Friday April 10, I experienced repeated involuntary session terminations where Claude Code would:

1. Complete a task (or in some cases, be mid-task, or even before I'd typed my first prompt)
2. Display "Crunched for Xs" (context compaction)
3. Immediately drop me back to the shell prompt
4. Display: Resume this session with: claude --resume <session-id>

This happened many times on April 10-11. Example transcript:

⏺ Update(~/.zshrc)
  ⎿  Added 1 line, removed 1 line
      ...

⏺ Done. Now rename the directory — run this yourself since my sandbox can't access the parent:

  mv ~/nook ~/shelf && source ~/.zshrc

✻ Crunched for 54s

Resume this session with:
claude --resume 4ef5f461-31c0-4b01-83e9-f2ad2bf2a657

The session completed its task, compacted, and then terminated without warning.

Likely Contributing Factors

• Memory pressure: 53 orphaned headless Chromium processes on a 16 GB Intel MacBook, plus 2 active ralph loops each running their own Claude sessions, plus the watchdog agent. The machine's fans were running constantly (which I didn't understand at the time — now I do).
• Possible rate limiting edge case: These drops started immediately after coming off a week-long rate limit. It's possible the rate limiter was being hit at a session level due to the orphaned processes consuming quota in the background, causing the active session to be terminated.

Critical Problem

The session ID 4ef5f461-31c0-4b01-83e9-f2ad2bf2a657 shown in the resume message is the same stuck process we found still running 40+ hours later. This means:

• I was dropped from the session
• The session continued running in the background
• It kept consuming API quota with no user interaction
• There was no indication this was happening

A dropped session should not continue consuming API quota in the background.

---

Issue 3: Week-Long Rate Limit (Context)

Rate limited from: Monday April 6, 2026 (morning)
Rate limit ended: Friday April 10, 2026 (~1:00 PM PT)

I was effectively locked out of Claude Code — my primary work tool — for nearly 5 full days. This was severely disruptive. The excessive usage that triggered this rate limit was likely also partially caused by orphaned processes, though I didn't have the diagnostic tooling to confirm at the time.

---

What I've Done on My End

1. Killed all orphaned processes — 2 ralph loops, the stuck --resume session, 53 headless browsers, 2 stale openclaude processes
2. Built a session-start audit hook (process-audit.sh) that now runs on every new Claude Code session and alerts me about stale Claude processes (>2h), tmux sessions, ralph loops, orphaned browsers (>6h), launchd agents, and stuck --resume sessions (>4h)
3. Unloaded the watchdog launchd agent

---

Requests for Anthropic

1. Usage attribution/dashboard: I need to be able to see which sessions and processes are consuming my quota. A simple "31% used" with no breakdown is not sufficient. If a stuck background process is burning my quota, I need to be able to see that.

1. Orphaned process cleanup: When a CLI session is dropped or disconnected, the process should not continue making API calls in the background indefinitely. There should be a timeout, a heartbeat check, or at minimum a cleanup mechanism.

1. Session drop investigation: The repeated involuntary session terminations on April 10-11 need investigation. Dropping users mid-task with no warning and no explanation is a poor experience, especially when the dropped session then becomes an orphaned process that continues consuming quota.

1. Rate limit transparency: When a user is rate-limited, they should be able to see what consumed their quota. "You used too much" with no breakdown is not actionable.

1. Headless browser lifecycle management: The context-mode plugin (or any MCP plugin that spawns browser processes) should clean up after itself when sessions end. 53 orphaned browsers accumulating over 8 days is a resource management failure.

---

Issue 4: Unauthorized Debit Card Charges (Stripe/Billing)

Summary

When subscribing to the Max plan, I authorized payment via my credit card through Stripe. However, Stripe drew payment multiple times from my debit card, which had been previously saved to my Stripe account but was not the card I authorized for this transaction.

Regulatory Concern

This is a potential violation of Regulation E (the Electronic Fund Transfer Act, 15 U.S.C. § 1693 et seq.), which governs electronic fund transfers including debit card transactions in the United States. Under Reg E:

• A consumer must authorize electronic fund transfers from their account
• Charging a debit card that was not explicitly authorized for a given transaction constitutes an unauthorized electronic fund transfer
• The distinction between credit and debit cards is legally significant — debit transactions draw directly from a consumer's bank account and carry different consumer protection frameworks (Reg E for debit vs. Reg Z for credit)

I am located in California and this regulation applies to my transactions. I authorized a specific credit card for payment. Drawing funds from a different payment method (my debit card) without my explicit authorization for that transaction is not permissible under federal law.

Request

Please investigate and correct the billing to charge the credit card I actually authorized, and refund any unauthorized debit card charges.

---

System State at Time of Discovery

Machine: MacBook Pro (Intel), 16 GB RAM, macOS 15.7.5
Stale Claude processes: 3 (2 ralph loops + 1 stuck resume)
Orphaned headless browsers: 53 (ages: 23h to 194h)  
Launchd agents: com.ralph.watchdog (loaded), com.claude.chrome-debug (loaded)
Weekly usage at discovery: 31% consumed in ~25 hours
5-hour session usage at discovery: 12% consumed with zero user interaction