Hitting rate limits on Claude Max plan and task fails (rate_limit_event)

[theomjones]

Checklist

• I searched existing issues and this hasn't been reported

Area

Backend

Operating System

macOS

Version

2.7.5

What happened?

I keep hitting this error when starting my first task in my repo. Not Anthropic related as I can use traditional claude code and plan / work without hitting this error or getting any rate limiting errors.

Unsure if this is specific to my Repo or not

Steps to reproduce

1. Start a task (using Max claude plan)
2. Hit an error Unknown message rate_limit_event (see screenshot)
3. Task fails

Expected behavior

Task successfully completes in plan mode

Logs / Screenshots

08:49:46 PM
Starting spec creation process
Starting phase 1: PROJECT DISCOVERY
Discovered 995 files in project
Starting phase 2: REQUIREMENTS GATHERING
Starting phase 3: COMPLEXITY ASSESSMENT
Analyzing task complexity with AI...
Agent error: Unknown message type: rate_limit_event
Starting phase 4: HISTORICAL CONTEXT
Knowledge graph not configured, skipping
Starting phase 5: CONTEXT DISCOVERY
Starting phase 6: SPEC DOCUMENT CREATION
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Phase 'spec_writing' failed: Attempt 1: Agent did not create spec.md; Attempt 2: Agent did not create spec.md; Attempt 3: Agent did not create spec.md
08:50:01 PM
Phase spec_writing failed
08:50:48 PM
Starting spec creation process
Starting phase 1: PROJECT DISCOVERY
Discovered 995 files in project
Starting phase 2: REQUIREMENTS GATHERING
Starting phase 3: COMPLEXITY ASSESSMENT
Analyzing task complexity with AI...
Agent error: Unknown message type: rate_limit_event
Starting phase 4: HISTORICAL CONTEXT
Historical context already available
Starting phase 5: CONTEXT DISCOVERY
Starting phase 6: SPEC DOCUMENT CREATION
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Phase 'spec_writing' failed: Attempt 1: Agent did not create spec.md; Attempt 2: Agent did not create spec.md; Attempt 3: Agent did not create spec.md
08:50:57 PM
Phase spec_writing failed
08:52:17 PM
Starting spec creation process
Starting phase 1: PROJECT DISCOVERY
Discovered 995 files in project
Starting phase 2: REQUIREMENTS GATHERING
Starting phase 3: COMPLEXITY ASSESSMENT
Analyzing task complexity with AI...
Agent error: Unknown message type: rate_limit_event
Starting phase 4: HISTORICAL CONTEXT
Historical context already available
Starting phase 5: CONTEXT DISCOVERY
Starting phase 6: SPEC DOCUMENT CREATION
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Phase 'spec_writing' failed: Attempt 1: Agent did not create spec.md; Attempt 2: Agent did not create spec.md; Attempt 3: Agent did not create spec.md
08:52:26 PM
Phase spec_writing failed
08:55:08 PM
Starting spec creation process
Starting phase 1: PROJECT DISCOVERY
Discovered 995 files in project
Starting phase 2: REQUIREMENTS GATHERING
Starting phase 3: COMPLEXITY ASSESSMENT
Analyzing task complexity with AI...
Agent error: Unknown message type: rate_limit_event
Starting phase 4: HISTORICAL CONTEXT
Historical context already available
Starting phase 5: CONTEXT DISCOVERY
Starting phase 6: SPEC DOCUMENT CREATION
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Agent error: Unknown message type: rate_limit_event
Phase 'spec_writing' failed: Attempt 1: Agent did not create spec.md; Attempt 2: Agent did not create spec.md; Attempt 3: Agent did not create spec.md
08:55:18 PM
Phase spec_writing failed

[github-actions]

👋 Thanks for opening your first issue!

A maintainer will triage this soon. In the meantime:

• Make sure you've provided all the requested info
• Join our Discord for faster help

[VDT-91]

Auto-Claude Investigation

Severity: high | Confidence: high

Summary

Root cause (high confidence): The Claude Agent SDK (version >= 0.1.33) sends a new message type rate_limit_event when rate limits are encountered, but the Python message handling code in agent_runner.py (and similar files) only recognizes AssistantMessage and UserMessage types. When the rate_limit_event message is received, it's not handled, and the SDK raises an exception with the message "Unknown message type: rate_limit_event", which is then caught and logged as "Agent error: Unknown message type: rate_limit_event".

The root cause is at apps/backend/spec/pipeline/agent_runner.py lines 165-244, where the message processing loop only handles two message types:

• AssistantMessage (line 174)
• UserMessage (line 216)

When a rate_limit_event message is received from the SDK, it doesn't match either condition and is unhandled, causing the SDK to raise an exception.

This affects all code that iterates through client.receive_response() messages, including:

• apps/backend/spec/pipeline/agent_runner.py
• apps/backend/agents/session.py
• apps/backend/task_logger/capture.py
• apps/backend/qa/reviewer.py
• apps/backend/qa/fixer.py
• And 20+ other files with the same pattern Severity: high. Users experience complete task failure instead of graceful rate limit handling:

Immediate Impact:

• Tasks fail with error: "Agent error: Unknown message type: rate_limit_event"
• All work done before the rate limit is lost
• No automatic pause-and-resume as expected
• Must manually restart the task, hoping not to hit rate limits again

Affected User Workflows:

1. Spec Creation (PRIMARY - reported in issue): Creating specs fails during complexity assessment or spec writing phases
2. Task Execution: All coding tasks fail immediately upon hitting rate limits
3. QA Validation: QA review and fixer sessions fail
4. Code Reviews: PR reviews (GitHub) and MR reviews (GitLab) fail
5. GitHub Automation: Issue triage, enrichment, batching all fail
6. AI Features: Insights, ideation, roadmap, analysis all fail

User Experience:

• Confusing error message that doesn't indicate rate limiting
• No indication of when to retry
• Lost progress and productivity
• Particularly impacts Claude Max plan users who are more likely to hit rate limits

Expected vs Actual:

• Expected: Task pauses, shows "Rate limited - resuming in X minutes", waits, then resumes automatically
• Actual: Task crashes immediately with "Unknown message type: rate_limit_event"

Frequency: Affects all users on any plan that encounters rate limits, but is most severe for Claude Max plan users who have higher usage and are more likely to trigger the rate_limit_event message type. Recommended fix (moderate): Add a catch-all else clause to each message processing loop that logs unknown message types using debug_detailed() and continues to the next message. This handles rate_limit_event and any future SDK message types gracefully. The pattern would be: after all if/elif message type handlers, add else: debug_detailed('module_name', 'Ignoring unknown message type', msg_type=msg_type); continue.

Root Cause Analysis

Root Cause: The Claude Agent SDK (version >= 0.1.33) sends a new message type rate_limit_event when rate limits are encountered, but the Python message handling code in agent_runner.py (and similar files) only recognizes AssistantMessage and UserMessage types. When the rate_limit_event message is received, it's not handled, and the SDK raises an exception with the message "Unknown message type: rate_limit_event", which is then caught and logged as "Agent error: Unknown message type: rate_limit_event".

The root cause is at apps/backend/spec/pipeline/agent_runner.py lines 165-244, where the message processing loop only handles two message types:

• AssistantMessage (line 174)
• UserMessage (line 216)

When a rate_limit_event message is received from the SDK, it doesn't match either condition and is unhandled, causing the SDK to raise an exception.

This affects all code that iterates through client.receive_response() messages, including:

• apps/backend/spec/pipeline/agent_runner.py
• apps/backend/agents/session.py
• apps/backend/task_logger/capture.py
• apps/backend/qa/reviewer.py
• apps/backend/qa/fixer.py
• And 20+ other files with the same pattern

Code Paths:

File	Lines	Description
apps/backend/spec/pipeline/agent_runner.py	165-244	Message processing loop that only handles AssistantMessage and UserMessage types. When rate_limit_event is received, it doesn't match either condition and causes the SDK to raise an exception.
apps/backend/spec/pipeline/agent_runner.py	256-264	Exception handler that catches the SDK exception and logs 'Agent error: Unknown message type: rate_limit_event'
apps/backend/requirements.txt	4-4	Specifies claude-agent-sdk>=0.1.33 which introduced the new rate_limit_event message type
apps/backend/agents/session.py	493-650	Another message processing loop with the same issue - only handles AssistantMessage and UserMessage types
apps/backend/task_logger/capture.py	68-145	process_message() method that only handles AssistantMessage and UserMessage, used by multiple agent sessions

Evidence: Code Evidence:

1. Error logging location (agent_runner.py:263):

except Exception as e:
    debug_error(
        "agent_runner",
        f"Agent session error: {e}",
        exception_type=type(e).__name__,
    )
    if self.task_logger:
        self.task_logger.log_error(f"Agent error: {e}", LogPhase.PLANNING)

2. Message handling that misses rate_limit_event (agent_runner.py:165-244):

async for msg in client.receive_response():
    msg_type = type(msg).__name__
    
    if msg_type == "AssistantMessage" and hasattr(msg, "content"):
        # Handle assistant messages...
    elif msg_type == "UserMessage" and hasattr(msg, "content"):
        # Handle user messages...
    # No else clause for rate_limit_event!

3. SDK version (requirements.txt:4):

claude-agent-sdk>=0.1.33

4. User's error logs show:

Agent error: Unknown message type: rate_limit_event

5. Affected phases from logs:

• "Starting phase 3: COMPLEXITY ASSESSMENT"
• "Starting phase 6: SPEC DOCUMENT CREATION"

Both phases use agent_runner.py which has the incomplete message handling.

Impact Assessment

Severity: high
Blast Radius: The issue affects 28 direct code locations across the entire backend codebase, creating a system-wide failure for all Claude SDK-based operations when rate limits are encountered. The blast radius encompasses:

1. All AI agent operations - Spec creation, planning, coding, QA, PR review, issue triage, etc.
2. All GitHub integrations - PR review, issue triage, enrichment, batching, etc.
3. All GitLab integrations - MR review operations
4. All AI-powered features - Insights, ideation, roadmap, analysis, etc.
5. Both CLI and frontend workflows - Every user-facing entry point that triggers AI operations

The defect creates a single point of failure in the message handling pattern that is replicated across the entire codebase. When the SDK sends a rate_limit_event message (which happens for users on Claude Max plan or any plan hitting rate limits), the message is unhandled and causes an immediate exception, bypassing all existing sophisticated rate limit handling logic (pause, wait for reset, resume).

This means that any user who hits a rate limit will experience immediate task failure instead of the expected graceful pause-and-resume behavior.
User Impact: Users experience complete task failure instead of graceful rate limit handling:

Immediate Impact:

• Tasks fail with error: "Agent error: Unknown message type: rate_limit_event"
• All work done before the rate limit is lost
• No automatic pause-and-resume as expected
• Must manually restart the task, hoping not to hit rate limits again

Affected User Workflows:

1. Spec Creation (PRIMARY - reported in issue): Creating specs fails during complexity assessment or spec writing phases
2. Task Execution: All coding tasks fail immediately upon hitting rate limits
3. QA Validation: QA review and fixer sessions fail
4. Code Reviews: PR reviews (GitHub) and MR reviews (GitLab) fail
5. GitHub Automation: Issue triage, enrichment, batching all fail
6. AI Features: Insights, ideation, roadmap, analysis all fail

User Experience:

• Confusing error message that doesn't indicate rate limiting
• No indication of when to retry
• Lost progress and productivity
• Particularly impacts Claude Max plan users who are more likely to hit rate limits

Expected vs Actual:

• Expected: Task pauses, shows "Rate limited - resuming in X minutes", waits, then resumes automatically
• Actual: Task crashes immediately with "Unknown message type: rate_limit_event"

Frequency: Affects all users on any plan that encounters rate limits, but is most severe for Claude Max plan users who have higher usage and are more likely to trigger the rate_limit_event message type.
Regression Risk: HIGH regression risk due to the scope of changes required:

Scope of Fix:

• Must modify 28 files with the same message handling pattern
• Each file needs a new branch to handle rate_limit_event messages
• Risk of inconsistencies across implementations

Potential Regressions:

1. Message Processing Logic Errors: Adding a third message type branch could introduce bugs in:

   • Message type detection
   • State management during rate limits
   • Tool execution flow when resuming

2. Exception Handling Changes: The current code catches all exceptions; changing this to handle rate_limit_event differently could:

   • Break existing error categorization (is_rate_limit_error, is_tool_concurrency_error)
   • Affect error logging and task logger behavior
   • Impact frontend error display

3. State Management Risks: Rate limit events carry state (reset timestamps) that must be:

   • Correctly extracted from the message
   • Passed to existing rate limit handlers
   • Synchronized with frontend pause/resume logic
   • Getting this wrong could cause infinite loops or lost state

4. Tight Coupling: Message processing loops are tightly coupled with:

   • Tool execution (ToolUseBlock handling)
   • Logging (task_logger)
   • Phase tracking (LogPhase)
   • Changes could break these integrations

Mitigating Factors:

• Test Coverage: Rate limit handling tests exist (qa_test_helpers.py, test_error_utils.py, frontend rate-limit-subtask-recovery.test.ts)
• Existing Rate Limit Infrastructure: The codebase already has sophisticated rate limit handling (coder.py lines 1121-1192) that can be leveraged
• Isolated Change: The fix is localized to message type handling, not changing overall architecture

Recommendation: Implement incrementally, starting with the most critical paths (agent_runner.py, session.py), then propagating the pattern to other files. Comprehensive testing of rate limit scenarios is essential.

Affected Components:

Component	File	Type	Description
Spec Creation Pipeline - AgentRunner	apps/backend/spec/pipeline/agent_runner.py	direct	Primary agent runner for spec creation. Message processing loop (lines 165-244) only handles AssistantMessage and UserMessage, causing rate_limit_event to crash spec creation during phases 3 (COMPLEXITY ASSESSMENT) and 6 (SPEC DOCUMENT CREATION). This is the component reported in the user's issue.
Agent Session Manager	apps/backend/agents/session.py	direct	Core session management used by planner, coder, and pr_template_filler agents. Message processing loop (lines 493-650) only handles AssistantMessage and UserMessage. Affects all follow-up planning, coding sessions, and PR template filling.
Task Logger - Message Capture	apps/backend/task_logger/capture.py	direct	process_message() method (lines 68-145) only handles AssistantMessage and UserMessage. Used by multiple agent sessions for logging, causing all agent-based operations to fail during rate limit events.
QA Reviewer Agent	apps/backend/qa/reviewer.py	direct	QA validation agent that reviews implementations against acceptance criteria. Uses receive_response() loop that only handles two message types, causing QA validation to fail during rate limits.
QA Fixer Agent	apps/backend/qa/fixer.py	direct	QA fixer agent that resolves issues identified by the reviewer. Uses receive_response() loop that only handles two message types, causing QA fixes to fail during rate limits.
GitHub PR Review Engine	apps/backend/runners/github/services/pr_review_engine.py	direct	Multi-pass PR review workflow. Uses SDK message iteration for structural, security, quality, and AI triage passes. Affects all GitHub PR review operations.
GitHub Issue Triage Engine	apps/backend/runners/github/services/triage_engine.py	direct	Issue triage logic for detecting duplicates, spam, and feature creep. Uses SDK message iteration, causing triage operations to fail during rate limits.
GitHub Enrichment Engine	apps/backend/runners/github/services/enrichment_engine.py	direct	Enriches GitHub issues with additional context and analysis. Uses SDK message iteration, causing enrichment to fail during rate limits.
GitHub Split Engine	apps/backend/runners/github/services/split_engine.py	direct	Splits complex issues into smaller sub-issues. Uses SDK message iteration, causing issue splitting to fail during rate limits.
GitHub Review Tools	apps/backend/runners/github/services/review_tools.py	direct	Tools for GitHub review operations including test running. Uses SDK message iteration, affecting review tool execution.
GitHub Follow-up Reviewer	apps/backend/runners/github/services/followup_reviewer.py	direct	Performs follow-up reviews on PRs. Uses SDK message iteration, causing follow-up reviews to fail during rate limits.
GitHub Batch Validator	apps/backend/runners/github/batch_validator.py	direct	Validates batches of GitHub issues. Uses SDK message iteration, causing batch validation to fail during rate limits.
GitHub Issue Batching Service	apps/backend/runners/github/batch_issues.py	direct	Groups similar issues for combined auto-fix using Claude. Uses SDK message iteration for analysis, causing issue batching to fail.
GitLab MR Review Engine	apps/backend/runners/gitlab/services/mr_review_engine.py	direct	Multi-pass merge request review for GitLab. Uses SDK message iteration, affecting GitLab MR review operations.
AI Insights Runner	apps/backend/runners/insights_runner.py	direct	AI-powered chat interface for codebase insights. Uses SDK message iteration, causing insights features to fail during rate limits.
AI Ideation Generator	apps/backend/ideation/generator.py	direct	Generates ideas for code improvements, UI/UX, docs, security, performance, and code quality. Uses SDK message iteration, causing ideation to fail during rate limits.
Roadmap Executor	apps/backend/runners/roadmap/executor.py	direct	Executes roadmap operations. Uses SDK message iteration, causing roadmap execution to fail during rate limits.
AI Analyzer Claude Client	apps/backend/runners/ai_analyzer/claude_client.py	direct	AI analyzer for codebase analysis. Uses SDK message iteration, causing AI analysis to fail during rate limits.
Linear Integration Updater	apps/backend/integrations/linear/updater.py	direct	Updates Linear issues from various sources. Uses SDK message iteration, causing Linear integration to fail during rate limits.
Merge AI Resolver	apps/backend/merge/ai_resolver/claude_client.py	direct	AI-powered merge conflict resolution. Uses SDK message iteration, causing merge resolution to fail during rate limits.
Commit Message Generator	apps/backend/commit_message.py	direct	Generates commit messages using AI. Uses SDK message iteration, causing commit message generation to fail during rate limits.
Spec Compaction	apps/backend/spec/compaction.py	direct	Compacts spec outputs. Uses SDK message iteration, causing spec compaction to fail during rate limits.
Core Workspace	apps/backend/core/workspace.py	direct	Core workspace operations. Uses SDK message iteration, affecting workspace-level operations during rate limits.
Insight Extractor	apps/backend/analysis/insight_extractor.py	direct	Extracts insights from codebase analysis. Uses SDK message iteration, causing insight extraction to fail during rate limits.
GitHub SDK Utilities	apps/backend/runners/github/services/sdk_utils.py	direct	Utility functions for GitHub SDK operations. Uses SDK message iteration, affecting GitHub SDK utility functions.
Spec CLI Commands	apps/backend/cli/spec_commands.py	indirect	CLI commands for spec management depend on agent_runner.py. All spec creation and management commands fail during rate limits.
QA CLI Commands	apps/backend/cli/qa_commands.py	indirect	CLI commands for QA validation depend on reviewer.py and fixer.py. All QA operations fail during rate limits.
Frontend Agent Events Handler	apps/frontend/src/main/ipc-handlers/agent-events-handlers.ts	indirect	Frontend IPC handler that processes agent events. When backend agents fail with rate_limit_event errors, the frontend shows failures instead of triggering rate limit recovery UI.
Planner Agent	apps/backend/agents/planner.py	indirect	Follow-up planner for adding new subtasks. Uses session.py which has the message handling bug, causing follow-up planning to fail.
Coder Agent	apps/backend/agents/coder.py	indirect	Main coding agent. Uses session.py which has the message handling bug. Note: coder.py has existing rate limit handling (lines 1121-1192) but it's bypassed because the exception is thrown before reaching that code.
PR Template Filler	apps/backend/agents/pr_template_filler.py	indirect	Fills PR templates automatically. Uses session.py which has the message handling bug, causing PR template filling to fail.
Rate Limit Recovery Tests	apps/frontend/src/__tests__/integration/rate-limit-subtask-recovery.test.ts	dependency	Frontend integration tests expect rate limit errors to be handled gracefully with subtask recovery. The rate_limit_event message type causes immediate failure instead of triggering the recovery flow, breaking these tests' assumptions.

Fix Recommendations

Approach 1: Add explicit handling for the rate_limit_event message type in each of the 25+ message processing loops. Add an elif clause after UserMessage handling that silently continues (or optionally logs with debug_detailed). This is the most targeted fix with minimal code changes.

• Complexity: moderate
• Pros: Targeted fix for the specific issue - only handles rate_limit_event, Minimal code change per file (single elif clause), Low risk of breaking existing functionality, Fast to implement and test
• Cons: Not future-proof - will need updating again when SDK adds new message types, No visibility into what other unknown message types might occur, Need to update 25+ files (significant but straightforward), Treats rate_limit_event as special case rather than general pattern

Approach 2: Add a catch-all else clause to each message processing loop that logs unknown message types using debug_detailed() and continues to the next message. This handles rate_limit_event and any future SDK message types gracefully. The pattern would be: after all if/elif message type handlers, add else: debug_detailed('module_name', 'Ignoring unknown message type', msg_type=msg_type); continue. (recommended)

• Complexity: moderate
• Pros: Future-proof - handles any new SDK message types automatically, Adds debug visibility into unknown messages for troubleshooting, Similar effort to Approach 1 but more robust, Follows existing codebase pattern (debug_detailed is used throughout), Makes debugging easier by logging what's being ignored
• Cons: Need to update 25+ files (same as Approach 1), May log many unknown message types if SDK uses message types not yet understood, Risk that important message types might be silently ignored (mitigated by debug logging)

Approach 3: Update the existing process_sdk_stream() utility in apps/backend/runners/github/services/sdk_utils.py to add proper handling for rate_limit_event and a catch-all else clause with debug logging. Then incrementally migrate files that have compatible message processing patterns to use process_sdk_stream() instead of manual message loops. For files that can't easily migrate due to custom logic, apply Approach 2's else clause pattern.

• Complexity: complex
• Pros: Best long-term architectural solution - single place to update message handling, Leverages existing shared utility pattern in the codebase, Reduces code duplication over time as files migrate, process_sdk_stream already has better error handling (try-except around each message), Easier to add new message type handling in one place, More maintainable for future SDK changes
• Cons: Most complex - requires refactoring message loops to use callbacks, Higher risk - need to ensure migration preserves existing behavior, Significant testing required to verify functional equivalence, Not all files can easily migrate due to custom logic patterns, Longer implementation timeline, May require iterative approach (migrate some files, keep others with manual loops)

Files to Modify: apps/backend/spec/pipeline/agent_runner.py, apps/backend/agents/session.py, apps/backend/task_logger/capture.py, apps/backend/qa/reviewer.py, apps/backend/qa/fixer.py, apps/backend/runners/github/services/enrichment_engine.py, apps/backend/runners/github/services/split_engine.py, apps/backend/runners/github/services/review_tools.py, apps/backend/runners/github/services/pr_review_engine.py, apps/backend/runners/github/services/triage_engine.py, apps/backend/runners/gitlab/services/mr_review_engine.py, apps/backend/ideation/generator.py, apps/backend/core/workspace.py, apps/backend/spec/compaction.py, apps/backend/runners/roadmap/executor.py, apps/backend/runners/github/batch_validator.py, apps/backend/runners/github/batch_issues.py, apps/backend/runners/ai_analyzer/claude_client.py, apps/backend/integrations/linear/updater.py, apps/backend/analysis/insight_extractor.py, apps/backend/merge/ai_resolver/claude_client.py, apps/backend/commit_message.py, apps/backend/runners/insights_runner.py, apps/backend/runners/github/services/followup_reviewer.py, apps/backend/runners/github/services/sdk_utils.py

Gotchas:

• The SDK sends rate_limit_event messages that don't match AssistantMessage or UserMessage types. When unhandled, the SDK raises an exception with message 'Unknown message type: rate_limit_event'. This is NOT a Python exception being raised by the application code - it's coming from the SDK itself when it detects messages weren't properly consumed.
• The fix must NOT raise an exception for unknown message types. Instead, it should gracefully continue to the next message in the stream. Using continue in the else clause is critical - do not use pass without continuing or the loop may process the same message repeatedly.
• Some files use different patterns for message type checking. Most check msg_type == "AssistantMessage" while others check msg_type == "ToolResult" or block_type == "ToolResultBlock". The else clause should come AFTER all existing message type handlers in the loop, not inside the content block iteration.
• The debug module requires DEBUG environment variable to show detailed logs. When adding debug_detailed calls for unknown message types, be aware that these logs may not appear in production unless DEBUG=true. Consider also using logger.warning for better visibility in production.
• Message loops may be nested inside try-except blocks that catch all exceptions (like in agent_runner.py line 256). When adding the else clause, ensure it comes BEFORE the closing of the message loop but AFTER all message type handlers. The else should be inside the async for msg in client.receive_response(): loop.
• Some files like insights_runner.py use simplified message handling that only checks for specific message types without UserMessage handling. The else clause pattern should still work - it will catch anything that doesn't match the existing handlers.
• When adding the else clause, be careful with indentation. The else should be at the same level as the if/elif clauses for message type checking, not nested inside the content block iteration. For example:

if msg_type == "AssistantMessage":
    for block in msg.content:
        ...
elif msg_type == "UserMessage":
    for block in msg.content:
        ...
else:
    # This else is at the if/elif level, not inside the for loops
    debug_detailed(...)
    continue

• Test with rate limiting scenarios to verify the fix works. The rate_limit_event message is only sent when actual rate limits are hit, so normal testing won't trigger it. Consider mocking the SDK response or using a lower rate limit threshold for testing.

Reproduction & Testing

Reproducible: unlikely

Test Coverage: Unable to assess (specialist failed)
Suggested Test Approach: Unable to determine (specialist failed)

---

Generated by Auto-Claude * 2026-02-18 07:19 UTC

[juniormayhe]

I can confirm this also happens in latest beta version connected to Claude Pro. Auto-Claude fails and stops while I can use Claude Code normally

[pablowinck]

same here

[MarcosDelSer]

happening in the last stable version, i couldnt download the beta. No task can execute and the error doesnt go away, any ETA for a fix?

[Tazovsky]

Claude Code Max 5x. any updates on this?

[Rex-Arnab]

#1875
My first contribution to GitHub project, hope i am doing everything correctly.