HTTP 429 Rate Limiting Causes All Sessions to Crash Simultaneously

Resolved 💬 4 comments Opened Mar 3, 2026 by martiendejong Closed Apr 7, 2026

Claude Code Bug Report: HTTP 429 Rate Limiting Causes All Sessions to Crash Simultaneously (submitted by Claude Code)

Date: 2026-03-03
Reported by: Martien de Jong (info@martiendejong.nl)
Claude Code Version: 2.1.32
Platform: Windows 10/11
Severity: HIGH - Complete loss of all active sessions

---

Executive Summary

Claude Code's event export system hits HTTP 429 (Too Many Requests) rate limits, causing the parent process to become unstable and crash ALL child session processes simultaneously. This results in complete loss of work across multiple active sessions.

---

Problem Description

What Happens

When using Claude Code intensively with multiple parallel sessions, the internal event logging system ("1P event logging") accumulates events in a queue. When attempting to export these events to the backend API, the system encounters HTTP 429 rate limiting errors. These export failures destabilize the parent process, causing ALL active Claude sessions to terminate simultaneously.

Impact

Complete session loss: All active sessions crash at once
Work loss: In-progress work in multiple sessions is lost
Recurring issue: Happens repeatedly during intensive use
No user control: No way to disable telemetry or control event export rate
Poor user experience: Unpredictable crashes interrupt workflow

---

Technical Details

Process Hierarchy

Parent Process (PID 65948) - Master Claude process
├─ Child Process (PID 55564) - Session 1
├─ Child Process (PID 62504) - Session 2
└─ Child Process (PID 66752) - Session 3

Critical Design Flaw: When parent process (65948) crashes or becomes unstable, ALL child session processes terminate simultaneously.

Error Logs

Location: C:\Users\HP\.claude\debug\*.txt

Error Pattern (repeated multiple times):

2026-03-03T13:44:54.168Z [ERROR] Error: Error: 1P event logging: 59 events failed to export
(status=429, code=ERR_BAD_REQUEST, Request failed with status code 429)
    at B6A.queueFailedEvents (file:///C:/Users/HP/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:265:2315)
    at async B6A.doExport (file:///C:/Users/HP/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:265:1197)

2026-03-03T13:44:54.169Z [ERROR] Error: Error: {"stack":"Error: Failed to export 59 events
(status=429, code=ERR_BAD_REQUEST, Request failed with status code 429)\n
at B6A.doExport (file:///C:/Users/HP/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:265:1372)",
"message":"Failed to export 59 events (status=429, code=ERR_BAD_REQUEST, Request failed with status code 429)",
"name":"Error"}

Timeline of Crash (2026-03-03)

13:44:54 - First 429 error (59 events failed)
13:45:47 - Continued 429 errors
13:45:48 - Multiple failures
13:45:59 - Export still failing
13:46:01 - Ongoing failures
13:46:11 - Last logged error
13:46:xx - ALL SESSIONS CRASH SIMULTANEOUSLY

Duration: ~1.5 minutes of failed export attempts before complete crash

Event Queue Data

File: C:\Users\HP\.claude\history.jsonl
Size: 3.52 MB
Event count: 10,718 events
Average per event: 0.34 KB

Reproduction Conditions

Use Claude Code intensively (3+ parallel sessions)
Generate many events (coding, file operations, tool calls)
Event queue grows to 5,000+ events
Event export hits rate limit (HTTP 429)
Export failures accumulate
Parent process becomes unstable
All sessions crash simultaneously

Frequency

Occurs regularly with intensive usage (multiple times per day)
Predictable based on event queue size
No warning to user before crash

---

Root Causes

1. Rate Limiting Without Backoff

Export API has strict rate limits
No exponential backoff on retry
Continues attempting export despite repeated 429 errors
Error handling doesn't gracefully degrade

2. Shared Parent Process Architecture

All sessions share single parent process
Parent process failure = all sessions lost
No session isolation
Single point of failure

3. No User Control

No config option to disable telemetry
No way to control export frequency
No settings for rate limiting behavior
No CLI flags for telemetry control

4. Poor Error Recovery

Export failures should be non-fatal
Should queue events locally and retry later
Should not destabilize parent process
Should not impact active user sessions

---

Expected Behavior

Graceful Degradation: Export failures should NOT crash sessions
Backoff Strategy: Implement exponential backoff on 429 errors
Session Isolation: Export failures in one session shouldn't affect others
User Control: Config option to disable telemetry: "telemetry": false
Rate Limiting: Client-side rate limiting before hitting API limits
Local Queuing: Queue events locally, export in background with backoff
User Notification: Warn user if export is failing, don't just crash

---

Proposed Solutions

Immediate (Hotfix)

// Add exponential backoff to export retry
async function exportWithBackoff(events, maxRetries = 5) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await exportEvents(events);
    } catch (error) {
      if (error.status === 429) {
        const delay = Math.pow(2, i) * 1000; // 1s, 2s, 4s, 8s, 16s
        console.log(`Rate limited, waiting ${delay}ms before retry`);
        await sleep(delay);
      } else {
        throw error; // Don't retry non-429 errors
      }
    }
  }
  // After max retries, queue locally but DON'T CRASH
  console.warn('Failed to export after max retries, queuing locally');
  queueLocally(events);
}

Short-term

Isolate export from parent process: Run export in separate worker thread
Client-side rate limiting: Limit to X events per minute before export
Config option: Add settings.json option for telemetry control
Better error handling: Catch export errors, don't propagate to parent

Long-term

Session architecture refactor: Don't use shared parent process
Batched export with backpressure: Export in larger batches with flow control
Local event store: SQLite database for event queue with retry logic
Health monitoring: Detect export failures, alert user, auto-recovery

---

Workarounds (Current Users)

1. Manual Queue Reset

# Stop all sessions
Get-Process claude -ErrorAction SilentlyContinue | Stop-Process -Force

# Archive event queue
Move-Item C:\Users\HP\.claude\history.jsonl C:\Users\HP\.claude\history.jsonl.bak

# Restart Claude

2. Reduce Parallel Sessions

Limit to 2-3 sessions maximum
Reduces event generation rate
Doesn't solve root cause

3. Monitor Queue Size

Watch history.jsonl file size
If > 5000 lines, reset manually
Preventive measure

---

Additional Context

System Information

OS: Windows 10/11
System Uptime: 5 days, 23 hours
Claude Processes: 4 (1 parent, 3 children)
Node Processes: 5 (various MCP servers)
Memory: Parent process ~80 MB, children 30-60 MB each

Related Logs

Debug logs: C:\Users\HP\.claude\debug\
Event queue: C:\Users\HP\.claude\history.jsonl
Settings: C:\Users\HP\.claude\settings.json

Usage Pattern

Intensity: High (16+ hours/day, multiple sessions)
Typical workflow: Parallel development across multiple projects
Event generation: Code editing, file operations, git, tool calls, MCP servers
Session duration: Hours (long-running sessions)

---

Request

Immediate: Hotfix with exponential backoff on 429 errors
Priority: Isolate export failures from session stability
Feature: Add config option to disable/control telemetry
Architecture: Consider session isolation (don't share parent process)

This bug severely impacts workflow for power users. Multiple hours of work can be lost when all sessions crash simultaneously. Export telemetry is valuable, but should NEVER crash user sessions.

---

Contact

Email: info@martiendejong.nl
GitHub: (if applicable)
Willing to test: Yes, available for testing fixes
Logs available: Yes, full debug logs available on request

---

Attachments

Debug logs with full error traces
Process hierarchy dump
Event queue sample
Crash timeline analysis

End of Report

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗